私はいくつかの容量計画を行っており、サーバーで処理できるTCP接続の数を（メモリの観点から）予測するために使用できる式があるかどうか疑問に思っていました。現時点では、必要なのはメモリ要件だけです。
式に現れると私が思ういくつかの変数は：
net.ipv4.tcp_wmem（最小値またはデフォルト値）net.ipv4.tcp_rmem（最小値またはデフォルト値）tcp_wmemとtcp_rmemのどれが実際に割り当てられているか、いつそのメモリがいつ割り当てられているかわかりません。ソケット作成時？オンデマンド？
回答:
ソースコードを変更できる場合は、rusageデータを使用してRSSを測定し、測定時にTCP接続の数を記録します。
ソースコードを変更できない場合は、topまたはpsから報告されたネットワークアプリのRSSを使用して、測定時のネットワーク接続数をから取得しlsof -iます。
アプリケーションがピーク負荷を通過する間、このデータを1分ごとに収集します。そのデータから、接続数をRAM使用量に関連付ける式を考え出すことができます。
もちろん、tcpデータ構造は事前に予測可能で計算可能である必要がありますが、測定できることは他にもたくさんあります。特にカーネルRAMの使用量を測定したい場合があります。いずれにせよ、TCPチューニングとTCPチューニングの詳細については、次の質問を参照してくださいネットワークスタックで何が起こっているかを明確に把握する方法。
tcp_memは、メモリ使用量に関して、tcpスタックの動作を定義するため、より重要です。IMOの送受信バッファーは、tcp_memの倍数である必要があります。受信バッファーの式へのリンクは次のとおりです：http : //www.acc.umu.se/~maswan/linux-netperf.txt。要するに：
オーバーヘッドは次のとおりです：window / 2 ^ tcp_adv_win_scale（tcp_adv_win_scale default is 2）したがって、受信ウィンドウのLinuxデフォルトパラメータ（tcp_rmem）の場合：87380-（87380/2 ^ 2）=65536。大西洋横断リンク（150 ms RTT）が与えられると、最大パフォーマンスは65536 / 0.150 = 436906バイト/秒または約400 kbyte /秒になり、今日は非常に低速です。デフォルトのサイズが大きくなった場合：（873800-873800/2 ^ 2）/0.150 = 4369000バイト/秒、つまり約4Mバイト/秒で、これは最新のネットワークに適しています。これがデフォルトであることに注意してください。送信者がより大きいウィンドウサイズで構成されている場合、これは幸いにもこれの10倍（8738000 * 0.75 / 0.150 =〜40Mbytes / s）にスケーリングされ、最新のネットワークにかなり適しています。
これがtcp_memに関する記事の内容です。
削除するのは、tcpパフォーマンスに対する人為的な制限であり、その制限がないと、使用可能なエンドツーエンドの帯域幅と損失によって制限されます。したがって、より効果的にアップリンクを飽和させる可能性がありますが、tcpはこれを処理するのに適しています。
IMOの中間のtcp_mem値が大きいほど、セキュリティが低下して接続が高速化され、メモリ使用量がわずかに増加します。
ネットワークスタックは次の方法で監視できます。
grep skbuff /proc/slabinfo
Davidは質問に対して非常に良い回答を提供してくれましたが、LFNだけを使用しているのでない限り、イベントベースのサーバー上でも、TCPバッファーは接続ごとのフットプリントのほんの一部にすぎない可能性があります。
キャパシティプランニングでは、サーバーのテストと負荷によるメモリ使用量の回帰の計算に代わるものはありません。