Руководство даёт таблицу типов машин у одного облачного провайдера и честно называет её прикидкой: результат сдвигают конфигурация, железо, набор программ, сеть и репутация адресов. Ценность не в таблице, а в двух правилах под ней — они ни к какому провайдеру не привязаны.
Память растёт от числа получателей — примерно 2 КБ на каждого, кто ждёт в очереди, независимо от размера письма. Сто тысяч получателей — около двухсот мегабайт, сколько бы ни весило само письмо.
Место растёт от объёма — от суммарного размера писем. Пример из руководства: сто тысяч получателей по 50 КБ требуют не меньше шести гигабайт спула, причём фактическая потребность оказывается чуть выше суммы размеров. Учёт и журналы считаются отдельно.
Отсюда главное следствие. Это два независимых ресурса с независимыми причинами роста. Узел бывает упёршимся в память при пустом диске — много получателей на лёгких письмах — или упёршимся в диск при свободной памяти — тяжёлые письма на небольшом списке. Прикидка, считающая их одной величиной, обязательно ошибётся в одной из двух.
Опорные точки по пропускной способности, если они нужны: от четырёх ядер и 8 ГБ на двух миллионах писем по 50 КБ в час до шестнадцати ядер и 32 ГБ на восьми миллионах.
Считать под план Хаб мог бы, и данных ему хватает: ресурсы узла он знает, планируемый объём и размер письма — тоже. Не хватает профиля отправки — всплесками или ровно, насколько глубоко копится очередь при отказах, — а без него расчёт под план даст число, верное только для спокойного дня.
Считать так:
| Ресурс | От чего | Как прикинуть |
|---|---|---|
| память | получатели одновременно в очереди | 2 КБ на получателя плюс запас на само приложение |
| диск под спул | суммарный размер писем в очереди | размер письма на число получателей, и чуть больше |
| диск под учёт и журналы | объём отправки | считается отдельно, в спул не входит |
Ключевое слово — «одновременно». Число получателей в очереди задаётся не суточным объёмом, а тем, насколько долго письма в ней живут: срок отказа, расписание повторов и поведение приёмников. Разумная прикидка — суточный объём, умноженный на срок отказа в сутках, для худшего дня.
Запас брать не процентами, а разами. Оба ресурса растут скачками при неприятностях у приёмника, и как раз тогда узел меньше всего должен упираться в память.
# прикидка под план: 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
2 связи
Развёртывание в облакеМеханизм, на котором держится этот шаг. § 1.7.1.1Чем опасна виртуальная машинаСмежный механизм: они работают вместе. § 1.7.1.2Поддельный приёмник внутри самого узлаРасчёты мощности из первой главы — оценки; это способ получить настоящую цифру на своём железе. inferencetotal-max-smtp-outGlobalЧисло соединений тратит память и дескрипторы, а их и считает прикидка. inferencespool-max-recipientsGlobalПотолок — одна из двух границ запаса: вторая по памяти. § 1.7.1.2min-free-space<spool>Порог — часть расчёта запаса: сколько места должно остаться, когда приём уже остановлен. § 1.7.1.2
pmta show status df -h /var/spool/pmta && free -m
3 статьи
◇Ключ активации — условие установки, а не шаг после неёБез ключа активации от поддержки SparkPost MTA не ставится и не работает, а уровень лицензии задаёт потолок исходящих соединений: на стандартной всё сверх 200 игнорируется.◇Ограничения облакаОблака ограничивают исходящую почту через порт 25, пока не попросишь снять лимит, а их диапазоны адресов почтовики встречают с подозрением.◇Лицензия на парк, а не на серверЛицензия не привязана к серверу: её ставят на столько машин, сколько разрешает предел экземпляров, а узлы раз в час отправляют вендору статистику объёма.