Global
MTA следит, сколько физической памяти занял его собственный процесс. Как только доля переваливает за заданную, приём новой почты прекращается — прямо на стадии MAIL FROM, ответом 452 4.3.2 Server resources temporarily exhausted. Когда память освобождается, приём возобновляется сам: ни перезапуска, ни команды для этого не нужно.
Отказ временный, и в этом весь смысл. 452 — не отказ письму, а просьба повторить: подающая система обязана попробовать ещё раз, а не выбросить письмо. Клапан поэтому ничего не теряет — он только придерживает вход.
Перекрывается вход, а не выход. Всё, что уже стоит в очереди, продолжает уходить: доставку директива не трогает. Так и задумано — очередь разгружается, память освобождается, приём открывается обратно. Отсюда же способ узнать этот 452 в лицо: он приходит вашей платформе рассылки в момент подачи, а не от ящика получателя, и искать его надо в журнале подачи, а не среди отказов доставки.
Что происходит без клапана. Узел с растущей очередью упирается в память операционной системы, и дальше решает уже она: на Linux ядро убивает самый прожорливый процесс, а это и есть сам MTA, pmtad. Сторож pmtawatch поднимет его обратно, но принятое и не записанное потеряно, а после старта узел ещё и перечитывает спул целиком, загружая очередь в память заново, — минуты, в течение которых он не отправляет.
Считайте не процент, а остаток. Порог — это запас, который вы оставляете всему остальному: ядру, журналам, дисковому кэшу, а на общем сервере ещё и соседям. Один и тот же процент на разных узлах оставляет разный запас, поэтому чем меньше памяти, тем ниже должен быть порог.
Ориентир — оставить системе от полугигабайта до полутора: при 2 ГБ это 70, при 4 ГБ — 80, при 8 ГБ — 85, при 16 ГБ и больше — 90, то самое умолчание пятой версии.
Ниже 60 не опускайтесь. Порог, который срабатывает на нормальной нагрузке, превращает аварийный отказ в постоянный: платформа получает 452 весь день и рано или поздно считает узел мёртвым. Клапан должен срабатывать редко — это последняя черта, а не способ управлять темпом. Темпом управляют max-msg-rate и total-max-smtp-out, объёмом очереди — spool-max-recipients, и разбираться надо сначала с ними.
Сотня осмысленна только там, где память ограничена снаружи — лимитом контейнера или cgroup, — и вы сознательно отдаёте решение туда. В остальных случаях это не «без ограничений», а «без страховки».
# директивы уровня узла пишутся в корне файла, без обрамляющего блока total-max-smtp-in 1000 total-max-smtp-out 5000 # аварийный клапан: на узле с 4 ГБ системе остаётся около 800 МБ max-memory-usage-percent 80
что делают не так и чем это кончается3 ошибки▶
§ 3.3.1.50
наш опыт
наш опыт
2 связи
grep -rn max-memory-usage-percent /etc/pmta/ ps -o pid,rss,%mem,comm -C pmtad
3 статьи
◇Чем опасна виртуальная машинаРаботать на виртуальной машине можно, но руководство не рекомендует это без достаточного железа и выверенных настроек гипервизора: под нагрузкой узел может перестать отвечать.◇Ключ активации — условие установки, а не шаг после неёБез ключа активации от поддержки SparkPost MTA не ставится и не работает, а уровень лицензии задаёт потолок исходящих соединений: на стандартной всё сверх 200 игнорируется.◇Что узел рассказывает о себе и по каким каналамСемь поверхностей наблюдения: веб-монитор, консоль в четырёх форматах, журнал, учёт, поиск по учёту, метрики и выгрузка во внешнюю аналитику.