26

I am running a fairly large-scale Node.js 0.8.8 app using Cluster with 16 worker processes on a 16-processor box with hyperthreading (so 32 logical cores). We are finding that since moving to the Linux 3.2.0 kernel (from 2.6.32), the balancing of incoming requests between worker child processes seems be heavily weighted to 5 or so processes, with the other 11 not doing much work at all. This may be more efficient for throughput, but seems to increase request latency and is not optimal for us because many of these are long-lived websocket connections that can start doing work at the same time.

The child processes are all accepting on a socket (using epoll), and while this problem has a fix in Node 0.9 (https://github.com/bnoordhuis/libuv/commit/be2a2176ce25d6a4190b10acd1de9fd53f7a6275), that fix does not seem to help in our tests. Is anyone aware of kernel tuning parameters or build options that could help, or are we best-off moving back to the 2.6 kernel or load balancing across worker processes using a different approach?

We boiled it down to a simple HTTP Siege test, though note that this is running with 12 procs on a 12-core box with hyperthreading (so 24 logical cores), and with 12 worker processes accepting on the socket, as opposed to our 16 procs in production.

HTTP Siege with Node 0.9.3 on Debian Squeeze with 2.6.32 kernel on bare metal:

reqs pid
146  2818
139  2820
211  2821
306  2823
129  2825
166  2827
138  2829
134  2831
227  2833
134  2835
129  2837
138  2838

Same everything except with the 3.2.0 kernel:

reqs pid
99   3207
186  3209
42   3210
131  3212
34   3214
53   3216
39   3218
54   3220
33   3222
931  3224
345  3226
312  3228
4

1 に答える 1

7

Webサーバープロセス間で負荷を分散するために、OSのソケットの複数の受け入れに依存しないでください。

Linuxカーネルの動作はバージョンごとに異なり、3.2カーネルでは特に不均衡な動作が見られました。これは、後のバージョンでは多少バランスが取れているように見えます。例：3.6。

Linuxにこれを使ってラウンドロビンのようなことをさせる方法があるはずだという仮定の下で運用していましたが、これには次のようなさまざまな問題がありました。

  • Linuxカーネル2.6は、ベアメタルでのラウンドロビン動作のようなものを示し（不均衡は約3対1）、Linuxカーネル3.2はそうではなく（10対1の不均衡）、カーネル3.6.10は再び問題ないように見えました。私たちは実際の変化に二分しようとはしませんでした。
  • 使用されているカーネルのバージョンやビルドオプションに関係なく、Amazon Webサービスの32ロジックコアHVMインスタンスで見られた動作は、単一のプロセスに大きく重点を置いていました。Xenソケットの受け入れに問題がある可能性があります：https ：//serverfault.com/questions/272483/why-is-tcp-accept-performance-so-bad-under-xen

https://github.com/joyent/node/issues/3241#issuecomment-11145233から始めて、優れたNode.jsチームに対応するために使用していたgithubの問題に関するテストを詳細に確認できます。

その会話は、Node.jsチームがクラスターに明示的なラウンドロビンを実装することを真剣に検討していることを示し、その問題を開始することで終了します：https ://github.com/joyent/node/issues/4435 、およびTrelloチーム（私たち）はフォールバックプランに進みます。フォールバックプランでは、ローカルHAProxyプロセスを使用して、各サーバーマシンの16ポート間でプロキシし、各ポートで2ワーカープロセスのクラスターインスタンスを実行します（受け入れレベルでの高速フェイルオーバーのため）。プロセスがクラッシュまたはハングした場合）。このプランは見事に機能しており、リクエストレイテンシの変動が大幅に減少し、平均レイテンシも低くなっています。

ここで言うべきことはまだたくさんありますが、これが本当にXenなのかLinuxカーネルの問題なのか、それとも複数の受け入れに対する誤った期待なのかが不明だったため、Linuxカーネルメーリングリストにメールを送信する手順は実行しませんでした。私たちの行動。

複数の受け入れに関する専門家からの回答を期待していますが、よりよく理解しているコンポーネントを使用して構築できるものに戻ります。誰かがより良い答えを投稿した場合、私は私の代わりにそれを受け入れることを嬉しく思います。

于 2012-12-19T14:40:55.097 に答える