Как перевести план отправки в железо

EC2 instance sizing
Память считает получателей, диск считает байты

Руководство даёт таблицу типов машин у одного облачного провайдера и честно называет её прикидкой: результат сдвигают конфигурация, железо, набор программ, сеть и репутация адресов. Ценность не в таблице, а в двух правилах под ней — они ни к какому провайдеру не привязаны.

Память растёт от числа получателей — примерно 2 КБ на каждого, кто ждёт в очереди, независимо от размера письма. Сто тысяч получателей — около двухсот мегабайт, сколько бы ни весило само письмо.

Место растёт от объёма — от суммарного размера писем. Пример из руководства: сто тысяч получателей по 50 КБ требуют не меньше шести гигабайт спула, причём фактическая потребность оказывается чуть выше суммы размеров. Учёт и журналы считаются отдельно.

Отсюда главное следствие. Это два независимых ресурса с независимыми причинами роста. Узел бывает упёршимся в память при пустом диске — много получателей на лёгких письмах — или упёршимся в диск при свободной памяти — тяжёлые письма на небольшом списке. Прикидка, считающая их одной величиной, обязательно ошибётся в одной из двух.

Опорные точки по пропускной способности, если они нужны: от четырёх ядер и 8 ГБ на двух миллионах писем по 50 КБ в час до шестнадцати ядер и 32 ГБ на восьми миллионах.

Главная ловушка — считать по среднему, забывая про очередь. Память нужна не на письма, отправленные за сутки, а на получателей, которые ждут одновременно. Приёмник начал отказывать, письма копятся, срок отказа четыре дня — и очередь вырастает до объёма, который в расчёт не закладывали. Сто тысяч в сутки при спокойной отправке умещаются в память легко; те же сто тысяч, застрявшие на четыре дня, — уже четыреста тысяч получателей одновременно.
Что делает Хаб. Проверяет узел перед вводом в работу и ругается на заведомо малое: меньше гигабайта памяти или меньше десяти гигабайт диска — отказ, меньше двух гигабайт памяти или сорока гигабайт диска — предупреждение. Это пороги на «вообще пригоден», а не расчёт под план.

Считать под план Хаб мог бы, и данных ему хватает: ресурсы узла он знает, планируемый объём и размер письма — тоже. Не хватает профиля отправки — всплесками или ровно, насколько глубоко копится очередь при отказах, — а без него расчёт под план даст число, верное только для спокойного дня.

Рекомендуемые значения

Считать так:

Ресурс От чего Как прикинуть
память получатели одновременно в очереди 2 КБ на получателя плюс запас на само приложение
диск под спул суммарный размер писем в очереди размер письма на число получателей, и чуть больше
диск под учёт и журналы объём отправки считается отдельно, в спул не входит

Ключевое слово — «одновременно». Число получателей в очереди задаётся не суточным объёмом, а тем, насколько долго письма в ней живут: срок отказа, расписание повторов и поведение приёмников. Разумная прикидка — суточный объём, умноженный на срок отказа в сутках, для худшего дня.

Запас брать не процентами, а разами. Оба ресурса растут скачками при неприятностях у приёмника, и как раз тогда узел меньше всего должен упираться в память.

Прикидка «объём на срок отказа» и совет про запас — наши. Из руководства здесь обе постоянные, пример со ста тысячами получателей по 50 КБ, оговорка про учёт и журналы и опорные точки по пропускной способности.
Пример в конфигурации
# прикидка под план: 100 000 получателей в сутки, письмо 50 КБ
# память:  100 000 × 2 КБ            ≈ 200 МБ  — при спокойной отправке
#          × 4 (срок отказа 4 суток) ≈ 800 МБ  — при затыке у приёмника# спул:    100 000 × 50 КБ           ≈ 5 ГБ    — и чуть больше на деле
# учёт и журналы                      считаются отдельно
Выделенная строка и есть та, о которой забывают. Первая строка верна для дня, когда всё уходит сразу; вторая — для дня, когда крупный приёмник придержал почту, а именно в такой день память и кончается.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

Типичные ошибки и проблемы

что делают не так и чем это кончается3 ошибки▶

Считают память по суточному объёму

§ 1.7.1.2

Чем чреватоПамять нужна на получателей, ждущих одновременно, а не отправленных за сутки. При затыке у крупного приёмника очередь живёт столько, сколько задан срок отказа, и число одновременных получателей вырастает кратно.
Как заметитьУзел работает месяцами и упирается в память именно в тот день, когда у приёмника неполадки.
Как правильноСчитать от худшего дня: суточный объём, умноженный на срок отказа в сутках. Запас брать разами, а не процентами.

Считают память и диск одной величиной

§ 1.7.1.2

Чем чреватоУ них разные причины роста: память следует за числом получателей, диск — за байтами. Прикидка «взять машину побольше» ошибётся в одном из двух: лёгкие письма на большом списке съедят память при пустом диске, тяжёлые на маленьком — наоборот.
Как заметитьОдин ресурс на пределе, второй занят на несколько процентов.
Как правильноСчитать раздельно, двумя правилами. Так же и наблюдать: смотреть число получателей в очереди и размер спула, а не «загрузку узла».

Закладывают спул без учёта и журналов

§ 1.7.1.2

Чем чреватоРуководство говорит считать их отдельно. Учёт растёт от объёма отправки и на активном узле догоняет спул по размеру; когда они на одном разделе, кончившееся место останавливает приём писем.
Как заметитьМесто на разделе кончилось, спул при этом занимает малую его часть.
Как правильноРазносить спул и учёт по разным разделам либо закладывать место на оба. Ротацию учёта настраивать сразу, а не когда место кончится.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
Наследование
Наследования у прикидки не бывает — это расчёт, а не настройка. Но на обе величины влияют директивы: срок отказа и расписание повторов решают, сколько получателей ждёт одновременно, а max-message-size ограничивает верхнюю границу того, что один получатель займёт в спуле. Порог свободного места (min-free-space) останавливает приём, когда диск всё-таки подошёл к концу.
⇄

Связанные записи

2 связи

Как проверить на узле
Оба ресурса смотрят вместе — по отдельности любой из них выглядит спокойным:
pmta show status
df -h /var/spool/pmta && free -m
Первая печатает число получателей в очереди — это и есть множитель для памяти. Дальше сравнить: получателей на 2 КБ против свободной памяти, размер спула против свободного места. Узел, у которого один показатель на пределе, а второй свободен, — обычное дело, а не признак ошибки.
В Хабе
Цена ошибки
безопасно: неверное значение ничего не ломает
Сценарии
Планирование мощности · Подготовить узел к отправке