Плохо сбалансированный сокет принимает ядро ​​Linux 3.2 по сравнению с ядром 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 процессами на 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

linux http node.js kernel epoll
person Brett    schedule 07.12.2012    source источник
comment
Вы пробовали создать 16 серверов (как отдельные процессы) и поставить (например) haproxy впереди? Это одна из хороших программ для проксирования. И к тому же вам понадобится прокси для дальнейшего масштабирования.   -  person freakish    schedule 11.12.2012
comment
Ага! Локальный HAProxy идеально выполняет циклический перебор между процессами, и, вероятно, мы будем использовать его, если не сможем решить эту проблему. Однако представляется предпочтительным избегать добавления дополнительной службы (не говоря уже о дополнительной переадресации туда и обратно, если процесс должен дать сбой или перестать отвечать на запросы), поэтому мы изучаем этот путь.   -  person Brett    schedule 11.12.2012
comment
Это похоже на то, что его стоит разместить в списке рассылки ядра Linux. Алгоритмы работы в сети/балансировки подвержены частым изменениям, поэтому было бы лучше найти оригинальных людей, которые облажались в первую очередь...   -  person s-m-e    schedule 12.12.2012
comment
Я согласен; мы видим результаты, похожие на ядро ​​2.6 с ядром 3.7, которое мы собрали, поэтому мы, вероятно, обратимся к списку рассылки ядра, когда немного проясним версии ядра и/или конфигурации сборки, которые вызывают проблему.   -  person Brett    schedule 13.12.2012
comment
Ядро 3.6.10 отлично справляется с этой задачей на «голом железе», но на HVM AMI в Amazon Web Services все по-прежнему ужасно несбалансировано, поэтому сейчас мы думаем, что есть проблема в ядре 3.2 в целом, и еще одна проблема. в Xen, вероятно, проблема здесь: serverfault.com/questions/272483/   -  person Brett    schedule 15.12.2012
comment
Просто из любопытства, как новые ядра работают в этой области? Есть улучшения?   -  person Venemo    schedule 08.05.2017

Ответы (1)


arrow_upward
7
arrow_downward

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

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

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

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

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

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

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

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

person Brett    schedule 19.12.2012