чтоб не захлебнуться

[netch80]

Никакие способности софта держанию нагрузки не работают, если поток поступает быстрее, чем приёмный процесс вообще способен его принять. Если регулировки потока нет и должны всё принимать, система будет неустойчива и будет выходить в турбулентный режим при переполнении некоторого уровня нагрузки. И неважно, Erlang это или что-то другое: или есть механизм ограничения приёма, потока, или система идёт вразнос.

Жизнерадостное игнорирование этого фактора - основная причина неадекватного поведения наших ранних версий.

А один общий mailbox процесса на все случаи приводит к тому, что управление потоком надо или делать через порты (в частности, выводя толстые потоки в TCP/SCTP/etc., даже если взаимодействуют ноды в кластере), или уметь явно говорить отправителю остановиться. Если бы было несколько очередей, с возможностью настройки каждой из них - можно было бы делать умнее; но сейчас - любое решение получается некорректным.

А существующие костыли закономерно повторяют старые добрые методы работы с очередями, реализованные в маршрутизаторах, начиная с Cisco. Только вот и они не помогают, когда процесс задумался непонятно о чём, а во входной очереди у него 730 тысяч сообщений. Здесь не кран надо менять, а всю систему.

Хочу много очередей с политиками. Размер очереди, простой дроп при заполнении, RED, GRED и так далее. Интересно, NIF'ами это можно сделать? Так, чтобы работало между нодами?

Comments

[lionet.livejournal.com]

У нас есть такие методы:

1. некоторые процессы перед обработкой сообщения смотрят на process_info(self(), messages), и если там их много — игнорируют или временно выходят в режим "ответить всем отлупом"

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 даёт неплохую аппроксимацию его.

[dottedmag.livejournal.com]

А в #5 флаги где лежат?

[lionet.livejournal.com]

Готовые флаги на нодах лежат в ETS и проверяются чем ближе к edge, тем лучше (где-то на входе у внешнего API — сразу за тем местом, где мы начинаем знать, как именно можно грамотно ответить "fail" в рамках того или иного API-вызова).

Центральная нода раздаёт дельты состояния флагов через TCP, а метрики для принятия решений получает от нод через UDP. Примерный синтаксис описания того, как из метрик получить флаги:

flag fast_recreate_views/view/$a/$b "Too many recreates for a view"
    using view/$a/$b/Recreate as Recreate,
          view/$a/$b/GetSearch as GetSearch,
          view/$a/$b/GetCounter as GetCounter
    raise when
        rate(Recreate, Hits, 60) > 10
        and rate(GetSearch, Hits, 60) < 5
        and rate(GetCounter, Hits, 60) < 5
    lower when
        rate(Recreate, Hits, 60) < 2

[netch80.livejournal.com]

> 1. некоторые процессы перед обработкой сообщения смотрят на process_info(self(), messages), и если там их много — игнорируют или временно выходят в режим "ответить всем отлупом"

Это применяем (сбрасывая всю очередь), но
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 даёт неплохую аппроксимацию его.

На входе мы и так проблем не имеет - ну дропнется, и ладно - а вот уже внутри надо что-то делать поумнее.

[lionet.livejournal.com]

1. process_info(_, messages) можно каждый раз звать, а не раз в N. jfyi.

4. Кролику prefetch выставляйте в 10—100, тогда не убьёт.

6. На входе надо ещё суметь дропнуть — наш опыт показывает, что как раз принять — легче всего; а в середине где-то начинаются узкие места. Поэтому FBI помогает, транслируя эффекты от узких мест в decision-making для edge.

[netch80.livejournal.com]

А где про этот FBI почитать? Или это что-то закрытое?
Сейчас поиск по нему ведёт обратно на текущий постинг:)

[lionet.livejournal.com]

Вот скоро подготовим докладик для ULCAMP::Dev, тогда и внешне-доступный материал появится.