чтоб не захлебнуться
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 04:53 am (UTC)Это применяем (сбрасывая всю очередь), но
1) это всё же очень аварийный метод
2) для этого надо посмотреть на свою очередь хотя бы каждые K обработанных сообщений, но если процесс заклинился на чём-то - то эта регулировка не сработает. Такое получается, например, при регулярном gen_call ко вспомогательным сущностям.
> 2. другие процессы перед gen_server:call() делают process_info(whereis(target), messages), и если там плохо — возвращают проблему.
В нашем случае не сработает - отправитель на другой ноде.
> 3. есть процессы, которые все входящие сообщения суют в собственную очередь (queue: или ets:), но если она уже достаточно сильно заполнена — отвечают отказом клиенту. Пример: https://github.com/echoteam/mcd
И такое есть, но опыт той же циски показывает, что в случае, если это не запросы, а просто поток данных, то отказ в приёме новых - худшая стратегия. Лучше сбросить уже принятые и начать принимать заново.
> 4. если мы сидим и сосём у кролика, то каждое сообщение маркируется таймстемпом. если пришедший таймстемп выходит за рамки разумного (секунды) — сообщение дропается; иначе работаем с ним.
См. выше - не помогает - "кролик" на другой ноде способен убить ноду обработчика переполнением её очереди. Убить жёстко - она падает по невозможности выделения памяти.
Если бы не это, то да, метод таймстампа работал бы
> 5. есть надсистемный распределённый фреймворк FBI (federated backplane infrastructure), который при превышении метрик и их комбинаций взводит флаги, а весь процессинг идёт в соответствии с флагами (если флаг выставлен — даём отлуп).
Хм, надо глянуть...
> RED в принципе где-то бы помог, но скорее на edge (когда трафик входит в кластер: Yaws, например); а там #5 даёт неплохую аппроксимацию его.
На входе мы и так проблем не имеет - ну дропнется, и ладно - а вот уже внутри надо что-то делать поумнее.
no subject
Date: 2012-05-02 05:14 am (UTC)4. Кролику prefetch выставляйте в 10—100, тогда не убьёт.
6. На входе надо ещё суметь дропнуть — наш опыт показывает, что как раз принять — легче всего; а в середине где-то начинаются узкие места. Поэтому FBI помогает, транслируя эффекты от узких мест в decision-making для edge.