ソケットバッファの低/オーバーランが原因で、大量のパケットがプルーニングされ、パケットがコラプスされた
jsonの大きなチャンクを返すapiとやり取りするテストマシン（linode 2048マシンでdebian squeeze 2.6.32）をセットアップしました。非同期でAPI 3000 /分を呼び出し、APIは約450kbのペイロードを返します。ボックスには、呼び出し結果を表示するhttpサーバーもあります。
Netstat -sの実行中（稼働時間は20日）：
254329 packets pruned from receive queue because of socket buffer overrun
50678438 packets collapsed in receive queue due to low socket buffer
これは私にはよく聞こえなかったので、これらのチュートリアルに従ってTCPパラメータを微調整しました：
http://fasterdata.es.net/fasterdata/Host-tuning/linux/test-measurement-Host-tuning/
そして
http://www.acc.umu.se/~maswan/linux-netperf.txt
しかし、それは役に立たないようです。
問題の理解と修正に役立つ可能性のあるソケットバッファーに関するアドバイス/チュートリアル/説明はありますか？
ありがとう
VPSが処理できる最大ネットワークトラフィックに達しているようです。微調整TCPパラメータは魔法ではありません-少しは役立つかもしれませんが、おそらく十分ではありません。仮想マシンで実行することにより、微調整によっては無効になる可能性もあります-トラフィックはハイパーバイザーの実際のインターフェイスを通過しますネットワークカードとその設定の影響を受けます。
受信ペイロードはリクエストごとに450kbであると言います。それはキロビットまたはキロバイトですか？ほとんどのツールはサイズをバイト単位で測定しますが、両方の計算を行います。
キロビットを想定：
- 3000リクエスト/分= 50リクエスト/秒
- 50 * 450kbit = 22,500kbit/s =約22Mbit/s
キロバイトとすると、約176Mbit/sです。
キロバイトの場合、ほとんどのVPSサーバーで一貫してそれを行うことができなくなります。各サーバーには、少なくとも10〜20 VPSが割り当てられます。 Linodeは、各サーバーへの2つのギガビット結合接続を使用します。つまり、サーバー全体での "フェアシェア"はせいぜい100Mbit/s程度です。
キロビットであっても、22MbitはほとんどのVPSにとって適切なビットです。
非常に多くの要求を非常に高速に実行することにより、おそらく独自のサーバーをDOSで実行することと同等のことを実行していることになります。実際の着信ネットワークトラフィックを確認すると、実際に使用している量がわかります。実際の100メガビットまたはギガビットの速度が必要な場合は、専用サーバーを調べる必要があるかもしれません。それ以外の場合は、サーバーが処理できるほど遅くなるまで、リクエストを遅くする必要があります。
また、メモリとCPUの使用状況も確認する必要があります。これらのいずれかが限界に達した場合、サーバーはパケットを処理するためのリソースがないため、パケットのドロップを開始します。まずtopとntopを見て、しばらくの間、CPU、メモリ、ネットワークの使用状況を確認します。
ソケットバッファオーバーランは、データが各接続に割り当てられた特別なメモリバッファに収まらないことを意味します。ネットワークインターフェースからのすべてのデータはそのようなバッファーに入れられ、アプリケーションはそこから読み取ります。アプリケーションがデータを読み取ると、このバッファーからフラッシュされます。基本的に、アプリケーションが利用可能になり、アプリケーションがデータを自由に処理できるようになるとすぐに、アプリケーションがデータを読み取ることを期待する必要があります。しかし、十分なパフォーマンスがない場合（CPUが飽和している場合やアプリケーションがロックされている場合（これはnodejsでよく見られます））、データは増え続けますが、バッファーサイズはそれをすべて処理するには十分ではありません。
膨大なバッファがある場合でも、アプリケーションが時間内にすべてを処理できない場合は、それは依然として整理され、データは破棄されます。したがって、最初にアプリケーションのパフォーマンスを調整することをお勧めします。