Плохо сбалансированный сокет принимает с ядром Linux 3.2 kernel vs 2.6

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

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

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

HTTP Siege с Node 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

Ответы

Ответ 1

Не зависеть от множества сокетов ОС, которые позволяют балансировать нагрузку через процессы веб-сервера.

Поведение ядер Linux отличается от версии к версии, и мы видели особенно неуравновешенное поведение с ядром 3.2, которое, как представляется, несколько более сбалансировано в более поздних версиях. например 3.6.

Мы работали в соответствии с предположением, что должен быть способ заставить Linux сделать что-то вроде round-robin с этим, но с этим было много проблем, в том числе:

  • Ядро Linux 2.6 показало что-то вроде циклического поведения на голом металле (дисбаланс был примерно от 3 до 1), ядро ​​Linux 3.2 не (дисбаланс 10-к-1), а ядро ​​3.6.10 выглядело хорошо. Мы не пытались деактивировать фактическое изменение.
  • Независимо от используемой версии ядра или сборки, поведение, которое мы наблюдали на примере 32-логического ядра HVM на веб-сервисах Amazon, сильно привязано к одному процессу; могут возникнуть проблемы с приемкой Xen: https://serverfault.com/info/272483/why-is-tcp-accept-performance-so-bad-under-xen

Вы можете подробно ознакомиться с нашими тестами на проблеме github, которую мы использовали, чтобы соответствовать отличной команде Node.js, начиная с здесь: https://github.com/joyent/node/issues/3241#issuecomment-11145233

Этот разговор заканчивается командой Node.js, указывающей на то, что они серьезно рассматривают возможность применения явного round-robin в Cluster и запускают для этого проблему: https://github.com/joyent/node/issues/4435, а команда Trello (что мы) перешла к нашему резервному плану, который должен был использовать локальный процесс HAProxy для прокси-сервера через 16 портов на каждой серверной машине с кластером 2-рабочих процессов экземпляр, запущенный на каждом порту (для быстрого перехода на другой ресурс на уровне принятия в случае сбоя процесса или зависания). Этот план работает красиво, со значительно уменьшенным изменением задержки запроса и более низкой средней задержкой.

Здесь еще многое нужно сказать, и я НЕ принял шаг по рассылке списка рассылки ядра Linux, так как неясно, действительно ли это проблема Xen или Linux, или действительно просто неправильное ожидание множественного поведения принятия с нашей стороны.

Мне бы хотелось увидеть ответ от эксперта по множественному согласию, но мы вернемся к тому, что мы можем построить, используя компоненты, которые мы понимаем лучше. Если кто-нибудь отправит лучший ответ, я был бы рад принять его вместо моего.