XenでTCP accept()のパフォーマンスがそれほど悪いのはなぜですか?
私のサーバーが新しい着信TCP接続を受け入れる速度は、Xenでは本当に悪いです。ベアメタルハードウェアでの同じテストでは、3〜5倍の速度向上が示されています。 なぜXenの下でこれがそんなに悪いのですか? Xenを調整して、新しいTCP接続のパフォーマンスを改善できますか? この種のユースケースにより適した他の仮想化プラットフォームはありますか? バックグラウンド 最近、私は、Xenの下で実行されている社内開発のJavaサーバーのパフォーマンスのボトルネックを調査しています。サーバーはHTTPを話し、単純なTCP接続/要求/応答/切断呼び出しに応答します。 ただし、サーバーに大量のトラフィックを送信している場合でも、1秒あたり最大7000を超えるTCP接続を受け入れることはできません(8コアEC2インスタンス、Xenを実行するc1.xlargeで)。テスト中、サーバーは1つのコア(必ずしもCPU 0ではない)が80%を超えて非常に負荷がかかり、他のコアはほとんどアイドル状態になるという奇妙な動作も示します。これは、問題がカーネル/基礎となる仮想化に関連していると思うようになります。 ベアメタルの非仮想化プラットフォームで同じシナリオをテストすると、TCP accept()レートが35 000 /秒を超えるというテスト結果が得られます。これは、すべてのコアがほぼ完全に飽和しているUbuntuを実行しているCore i5 4コアマシン上で実行されます。私には、そのような数字は正しいと思われます。 再びXenインスタンスで、sysctl.confにあるほとんどすべての設定を有効化/調整してみました。受信パケットステアリングと受信フローステアリングを有効にし、スレッド/プロセスをCPUに固定しますが、明らかなゲインはありません。 仮想化を実行すると、パフォーマンスの低下が予想されます。しかし、この程度に?低速のベアメタルサーバーは、virtよりも優れています。5倍の8コア? これは本当にXenの予想される動作ですか? Xenを調整して、新しいTCP接続のパフォーマンスを改善できますか? この種のユースケースにより適した他の仮想化プラットフォームはありますか? この動作を再現する これをさらに調査して問題を特定すると、netperfパフォーマンステストツールが、私が経験している同様のシナリオをシミュレートできることがわかりました。netperfのTCP_CRRテストを使用して、さまざまなサーバー(仮想化および非仮想化の両方)からさまざまなレポートを収集しました。調査結果に貢献したい、または現在のレポートを調べたい場合は、https://gist.github.com/985475をご覧ください。 この問題が不十分に書かれたソフトウェアによるものではないことをどのように確認できますか? サーバーはベアメタルハードウェアでテストされており、使用可能なすべてのコアをほぼ飽和させます。 キープアライブTCP接続を使用すると、問題はなくなります。 何でこれが大切ですか? で、ESN(私の雇用者)私はのプロジェクトリードしていますBeaconpush、Javaで書かれた彗星/ウェブソケットサーバー。非常にパフォーマンスが高く、最適な条件下で与えられたほぼすべての帯域幅を飽和させることができますが、それでも新しいTCP接続をどれだけ高速にできるかに制限されています。つまり、ユーザーが頻繁に出入りする大きなユーザーチャーンがある場合、多くのTCP接続をセットアップ/ティアダウンする必要があります。接続を可能な限り長く維持するために、この問題を軽減しようとします。しかし、最終的に、accept()のパフォーマンスがコアの回転を妨げているため、それが気に入らないのです。 アップデート1 誰かがこの質問をHacker Newsに投稿しました。そこにはいくつかの質問/回答もあります。しかし、私はこの質問を、私が見つけたときに見つけた情報で最新の状態に保とうとします。 これをテストしたハードウェア/プラットフォーム: インスタンスタイプがc1.xlarge(8コア、7 GB RAM)およびcc1.4xlarge(2x Intel Xeon X5570、23 GB RAM)のEC2。使用されたAMIは、それぞれami-08f40561とami-1cad5275でした。また、誰かが「セキュリティグループ」(すなわち、EC2ファイアウォール)も影響を与える可能性があると指摘しました。しかし、このテストシナリオでは、このような外部要因を排除するためにlocalhostでのみ試しました。私が聞いたもう一つのうわさは、EC2インスタンスが100k PPS以上をプッシュできないことです。 Xenを実行する2つのプライベート仮想化サーバー。1つはテスト前に負荷がゼロでしたが、違いはありませんでした。 Rackspaceのプライベート専用Xenサーバー。ほぼ同じ結果があります。 これらのテストを再実行し、https://gist.github.com/985475でレポートに記入するプロセスを進めています。支援が必要な場合は、数字をお寄せください。それは簡単です! (アクションプランは別の統合された回答に移動されました)