чтоб не захлебнуться
May. 1st, 2012 09:14 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
netch80Никакие способности софта держанию нагрузки не работают, если поток поступает быстрее, чем приёмный процесс вообще способен его принять. Если регулировки потока нет и должны всё принимать, система будет неустойчива и будет выходить в турбулентный режим при переполнении некоторого уровня нагрузки. И неважно, Erlang это или что-то другое: или есть механизм ограничения приёма, потока, или система идёт вразнос.
Жизнерадостное игнорирование этого фактора - основная причина неадекватного поведения наших ранних версий.
А один общий mailbox процесса на все случаи приводит к тому, что управление потоком надо или делать через порты (в частности, выводя толстые потоки в TCP/SCTP/etc., даже если взаимодействуют ноды в кластере), или уметь явно говорить отправителю остановиться. Если бы было несколько очередей, с возможностью настройки каждой из них - можно было бы делать умнее; но сейчас - любое решение получается некорректным.
А существующие костыли закономерно повторяют старые добрые методы работы с очередями, реализованные в маршрутизаторах, начиная с Cisco. Только вот и они не помогают, когда процесс задумался непонятно о чём, а во входной очереди у него 730 тысяч сообщений. Здесь не кран надо менять, а всю систему.
Хочу много очередей с политиками. Размер очереди, простой дроп при заполнении, RED, GRED и так далее. Интересно, NIF'ами это можно сделать? Так, чтобы работало между нодами?
Жизнерадостное игнорирование этого фактора - основная причина неадекватного поведения наших ранних версий.
А один общий mailbox процесса на все случаи приводит к тому, что управление потоком надо или делать через порты (в частности, выводя толстые потоки в TCP/SCTP/etc., даже если взаимодействуют ноды в кластере), или уметь явно говорить отправителю остановиться. Если бы было несколько очередей, с возможностью настройки каждой из них - можно было бы делать умнее; но сейчас - любое решение получается некорректным.
А существующие костыли закономерно повторяют старые добрые методы работы с очередями, реализованные в маршрутизаторах, начиная с Cisco. Только вот и они не помогают, когда процесс задумался непонятно о чём, а во входной очереди у него 730 тысяч сообщений. Здесь не кран надо менять, а всю систему.
Хочу много очередей с политиками. Размер очереди, простой дроп при заполнении, RED, GRED и так далее. Интересно, NIF'ами это можно сделать? Так, чтобы работало между нодами?
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2012-05-02 05:14 am (UTC)4. Кролику prefetch выставляйте в 10—100, тогда не убьёт.
6. На входе надо ещё суметь дропнуть — наш опыт показывает, что как раз принять — легче всего; а в середине где-то начинаются узкие места. Поэтому FBI помогает, транслируя эффекты от узких мест в decision-making для edge.