私は容量計画を立てていますが、サーバーが処理できるTCP接続の数をメモリの観点から予測するために使用できる式があるかどうかを知りたいです。現在、メモリ要件にのみ興味があります。
数式に現れると思われるいくつかの変数は次のとおりです。
- sysctl
net.ipv4.tcp_wmem(最小またはデフォルト) - sysctl
net.ipv4.tcp_rmem(最小またはデフォルト) - sock、sock_common、proto、およびその他のソケット固有のデータ構造のサイズ。
tcp_wmemとtcp_rmemが実際にどのくらい割り当てられたのか、そのメモリがいつ割り当てられたのかわかりません。ソケット作成時？リクエストに応じて？
ベストアンサー1
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 デフォルトは 2) です。したがって、Linux受信ウィンドウ（tcp_rmem）のデフォルトパラメータは87380 - (87380 / 2^2）= 65536です。大西洋横断リンク（150ms RTT）が与えられると、最大性能は65536/0.150 = 436906バイト/秒または約400kbyte/sになります。これは今日非常に遅いです。デフォルトサイズが増加した場合：（873800 - 873800/2^2）/0.150 = 4369000バイト/秒または約4MB/秒で、これは最新のネットワークに適しています。これがデフォルトであり、送信者がより大きなウィンドウサイズで構成されている場合は、10倍（8738000 * 0.75 / 0.150 = ~ 40Mbytes / s）に拡張され、最新のネットワークに適しています。
以下は記事に出てきたtcp_memの内容です。
除去はTCPパフォーマンスに対する人為的な制限であり、この制限がないと、使用可能なエンドツーエンドの帯域幅と損失によって制限されます。したがって、アップリンクをより効率的に飽和させることができますが、tcpはそれを処理するのに優れています。
私の考えでは、中間のtcp_mem値が大きいほど接続が速くなりますが、セキュリティが低下し、メモリ使用量がわずかに増加します。
以下を使用してネットワークスタックを監視できます。
grep skbuff /proc/slabinfo