私は容量計画を立てていますが、サーバーが処理できる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
答え2
ソースコードを変更できる場合は、rusageデータを使用してRSSを測定し、測定時に使用されているTCP接続の数を記録してください。
ソースコードを変更できない場合は、topまたはpsによって報告されたWebアプリケーションのRSSを使用して、測定時のネットワーク接続数を取得しますlsof -i。
このデータはアプリケーションに最大負荷がかかると毎分収集され、このデータに基づいて接続数とRAM使用量を接続する式を考え出すことができます。
もちろん、測定できるものがはるかに多いです。特に、tcpデータ構造は事前に予測可能で計算する必要がありますが、カーネルRAMの使用量を測定したい場合があります。とにかくこの質問を見てくださいhttps://serverfault.com/questions/10852/what-limits-the-maximum-number-of-connections-on-a-linux-serverTCPチューニングの詳細情報とネットワークスタックで何が起こっているのかを明確に理解する方法。
答え3
Davidは質問に非常に良い答えを提供しましたが、特に使用しない限りLFN、イベントベースのサーバーでも、TCPバッファは各接続が占めるスペースの小さな部分にすることができます。
容量計画では、テストサーバーとコンピューティングロードメモリ使用量の回帰を置き換える方法はありません。