Я запускаю довольно крупномасштабное приложение Node.js 0.8.8, использующее кластер с 16 рабочими процессами на 16-процессорной коробке с гиперпоточностью (так 32 логических ядра). Мы обнаруживаем, что после перехода на ядро Linux 3.2.0 (с 2.6.32) балансировка входящих запросов между рабочими дочерними процессами кажется сильно взвешенной до 5 или около того процессов, а остальные 11 вообще не выполняют большой работы. Это может быть более эффективным для пропускной способности, но, по-видимому, увеличивает задержку запросов и не является оптимальным для нас, потому что многие из них являются долгоживущими соединениями веб-сокетов, которые могут начать работать одновременно.

Все дочерние процессы принимают на сокете (используя epoll), и хотя эта проблема исправлена в узле 0.9 (https://github.com/bnoordhuis/libuv/commit/be2a2176ce25d6a4190b10acd1de9fd53f7a6275), это исправление, похоже, не помогает наши тесты. Кто-нибудь знает о параметрах настройки ядра или опциях сборки, которые могут помочь, или нам лучше вернуться к ядру 2.6 или распределить нагрузку между рабочими процессами, используя другой подход?

Мы свели его к простому тесту HTTP Siege, хотя учтите, что он работает с 12 процессорами на 12-ядерном блоке с гиперпоточностью (24 логических ядра) и с 12 рабочими процессами, принимающими на сокете, в отличие от наших 16 ПРОЦЫ в производстве.

HTTP Siege с узлом 0.9.3 на Debian Squeeze с ядром 2.6.32 на голом железе:

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

То же самое, кроме ядра 3.2.0:

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