私のサーバーが新しい着信TCP接続を受け入れる速度は、Xenでは本当に悪いです。ベアメタルハードウェアでの同じテストでは、3〜5倍の速度向上が示されています。

1. なぜXenの下でこれがそんなに悪いのですか？
2. Xenを調整して、新しいTCP接続のパフォーマンスを改善できますか？
3. この種のユースケースにより適した他の仮想化プラットフォームはありますか？

バックグラウンド

最近、私は、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コア？

1. これは本当にXenの予想される動作ですか？
2. Xenを調整して、新しいTCP接続のパフォーマンスを改善できますか？
3. この種のユースケースにより適した他の仮想化プラットフォームはありますか？

この動作を再現する

これをさらに調査して問題を特定すると、netperfパフォーマンステストツールが、私が経験している同様のシナリオをシミュレートできることがわかりました。netperfのTCP_CRRテストを使用して、さまざまなサーバー（仮想化および非仮想化の両方）からさまざまなレポートを収集しました。調査結果に貢献したい、または現在のレポートを調べたい場合は、https：//gist.github.com/985475をご覧ください。

この問題が不十分に書かれたソフトウェアによるものではないことをどのように確認できますか？

1. サーバーはベアメタルハードウェアでテストされており、使用可能なすべてのコアをほぼ飽和させます。
2. キープアライブ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でレポートに記入するプロセスを進めています。支援が必要な場合は、数字をお寄せください。それは簡単です！

（アクションプランは別の統合された回答に移動されました）

現在：Xenの下では小さなパケットのパフォーマンスが悪い

（代わりに質問自体から別の回答に移動しました）

HNのユーザー（KVM開発者？）によると、これはXenおよびKVMでの小さなパケットパフォーマンスによるものです。それは仮想化に関する既知の問題であり、彼によると、VMWareのESXはこれをより良く処理します。彼はまた、KVMがこれを軽減するために設計されたいくつかの新機能をもたらしていることにも言及しました（元の投稿）。

正しい場合、この情報は少しがっかりさせます。いずれにしても、Xenの第一人者が決定的な答えを出すまで、以下の手順を試してみます:)

xen-usersメーリングリストのIain Kayがこのグラフを編集しまし た。TCP_CRRバーに注目してください。「2.6.18-239.9.1.el5」と「2.6.39（Xen 4.1.0を使用）」を比較してください。

ここおよびHNからの回答/回答に基づく現在のアクションプラン：

1. syneticon-DJによって示唆されているようにXenの固有のメーリングリストやXenSource社のBugzillaにこの問題を提出するメッセージがXenのユーザーのリストに掲載された回答を待っています、。

2. 単純な病理学的なアプリケーションレベルのテストケースを作成し、公開します。
   指示付きのテストサーバーが作成され、GitHubに公開されました。これにより、netperfと比較して、より現実的なユースケースを見ることができるはずです。

3. 64ビットがXenのオーバーヘッドを増加させる可能性があるため、32ビットPV Xenゲストインスタンスを試してください。誰かがこれをHNで言及しました。違いはありませんでした。

4. HNのabofhで提案されているように、sysctl.confでnet.ipv4.tcp_syncookiesを有効にしてみてください。これにより、カーネルでハンドシェイクが発生するため、明らかにパフォーマンスが向上する可能性があります。これには運がなかった。

5. バックログを1024からもっと高い値に増やします。これは、HNのabofhでも提案されています。これは、ゲストがdom0（ホスト）によって指定された実行スライスの間に、より多くの接続を潜在的に受け入れる可能性があるため、これも役立ちます。

6. conntrackが受け入れ率を半分にする可能性があるため、すべてのマシンで無効になっていることを再確認してください（deubeulyouが推奨）。はい、すべてのテストで無効にされました。

7. 「netstat -sでリッスンキューオーバーフローとsyncacheバケットオーバーフロー」を確認します（HNのmike_esspeで推奨）。

8. 割り込み処理を複数のコアに分割します（以前に有効にしてみたRPS / RFSがこれを行うことになっていますが、再試行する価値があります）。HNのadamtによって提案されました。

9. Matt Baileyが提案したように、TCPセグメンテーションオフロードと分散/収集アクセラレーションをオフにします。（EC2または同様のVPSホストでは不可能）

逸話的に、NICハードウェアアクセラレーションをオフにすると、Xenコントローラーのネットワークパフォーマンスが大幅に向上することがわかりました（LXCにも当てはまります）。

スキャッターギャザーアクセル：

/usr/sbin/ethtool -K br0 sg off

TCPセグメンテーションオフロード：

/usr/sbin/ethtool -K br0 tso off

br0は、ハイパーバイザーホスト上のブリッジまたはネットワークデバイスです。起動するたびにオフにするには、これを設定する必要があります。YMMV。

たぶん、あなたは少し明確にすることができます-あなた自身のサーバー上で、またはEC2インスタンスのみでXenの下でテストを実行しましたか？

Acceptは単なる別のsyscallであり、新しい接続は、最初のいくつかのパケットにいくつかの特定のフラグがあるという点でのみ異なります。Xenなどのハイパーバイザーは、間違いなく違いを見ないはずです。セットアップの他の部分は次のようになります。たとえば、EC2では、セキュリティグループがそれと何か関係があったとしても驚かないでしょう。conntrackは、新しい接続受け入れ率（PDF）を半分にすることも報告されています。

最後に、最近Libratoがブログに書いたように、EC2（そしておそらく一般的にはXen）で奇妙なCPU使用/ハングアップを引き起こすCPU /カーネルの組み合わせがあるようです。

dom0のブリッジコードでiptablesおよびその他のフックを無効にしてください。明らかに、これはブリッジネットワーキングXenセットアップにのみ適用されます。

echo 0 > /proc/sys/net/bridge/bridge-nf-call-ip6tables
echo 0 > /proc/sys/net/bridge/bridge-nf-call-iptables
echo 0 > /proc/sys/net/bridge.bridge-nf-call-arptables

サーバーのサイズに依存しますが、小さなもの（4コアプロセッサー）に依存して、1つのCPUコアをXen dom0専用にし、固定します。ハイパーバイザーブートオプション：

dom0_max_vcpus=1 dom0_vcpus_pin dom0_mem=<at least 512M>

物理イーサネットPCIデバイスをdomUに渡そうとしましたか？素晴らしいパフォーマンスの向上があるはずです。