私は、10,000 個のクライアントがすべて一度に、3 分ごとにデータを送信しようとする正確なタイミングがとられている、少し変わったアプリケーションに取り組んでいます。この「ab」コマンドは、現実世界の 1 つの弾幕をかなり正確にシミュレートします。
ab -c 10000 -n 10000 -r "http://example.com/submit?data=foo"
これらの送信を収集するために、rackspacecloud VPS インスタンスの Ubuntu 12.4 で Node.js を使用していますが、すべてのビジネス ロジックを削除して http リクエストを no- op。
テストが約 90% 完了すると、長時間ハングします。不思議なことに、これは一貫して 90% で発生します - c=n=10k の場合、9000 で c=n=5k の場合、4500 で。c=n=2k の場合、1800 です。テストは実際には最終的に完了し、多くの場合、エラーは発生しません。ただし、ab ログとノード ログの両方で、テスト実行の約 80 ～ 90% まで継続的な処理が示され、その後、完了する前に長い一時停止が発生します。
ノードがリクエストを正常に処理している場合、CPU 使用率は通常約 50 ～ 70% です。ハング期間中、CPU は 100% まで上昇します。ときどき 0 近くに留まります。不規則な CPU 応答と、実際の接続数 (% 完了のみ) とは無関係に見えるという事実の間で、私はガベージ コレクターを疑いません。
ローカルホストとリモートサーバーで「ab」を実行してみました-同じ効果です。
おそらく接続を閉じることを含む、TCPスタックに関連する何かが疑われますが、構成の変更はどれも役に立ちませんでした。私の変更：
- ulimit -n 999999
- listen() すると、バックログを 10000 に設定します
sysctl の変更は次のとおりです。
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
net.ipv4.tcp_max_orphans = 20000
net.ipv4.tcp_max_syn_backlog = 10000
net.core.somaxconn = 10000
net.core.netdev_max_backlog = 10000
また、カーネルログに次のメッセージが表示される傾向があることにも気付きました。
TCP: Possible SYN flooding on port 80. Sending cookies. Check SNMP counters.
TCP バックログ キューは決してオーバーフローしないように十分に深くする必要があるため、このメッセージには困惑しています。syn Cookie を無効にすると、「Cookie の送信」が「接続の削除」になります。
これはある種の Linux TCP スタック チューニングの問題であると推測し、ネットで見つけたほぼすべてのものを読みました。私が試したことは何も問題ではないようです。何かアドバイス？
更新: tcp_max_syn_backlog、somaxconn、netdev_max_backlog、および listen() バックログ パラメータを 50k に設定して試しましたが、動作は変わりません。それでも SYN フラッド警告が生成されます。