Postfix под нагрузкой: throughput‑тюнинг, кэш соединений и TLS‑ресюмпция

Когда Postfix начинает «задыхаться» под всплеском почтового трафика, интуитивно хочется дать ему больше CPU и памяти. Это помогает, но не решает главного: накладные расходы на установку TCP/TLS‑соединений и очередное планирование часто становятся основными ограничителями throughput. В этой статье разбираем, как диагностировать узкие места и что настроить, чтобы пропускная способность росла предсказуемо: конкурентность по направлениям, кэширование исходящих SMTP‑соединений, TLS‑ресюмпцию и аккуратные таймауты.

Как понять, что именно тормозит

Первое, что нужно отделить: «не принимает входящий трафик» (узкое место на smtpd) или «медленно высылает из очереди» (узкое место на smtp/qmgr). Разные симптомы требуют разных решений.

• Очередь растет, коннектов много: вероятен дефицит процессов smtpd, фильтров/авторизации или узкие таймауты по сети.
• Очередь растет, входящий фронт справляется: ограничение на конкурентность доставок по доменам, бэк‑офф или медленные удаленные MX.
• CPU загружен, но трафик «рваный»: высокая доля TLS‑рукопожатий без ресюмпции и отсутствие кэша исходящих соединений.

Полезные быстрые проверки:

postqueue -p
qshape active
postconf -n | sort
postfix status

qshape покажет, на каких доменах «горячие» направления: если у пары доменов много сообщений в active, то нужно отдельно тюнить конкурентность по этим назначениям.

Базовые лимиты процессов и конкурентности

Postfix масштабируется за счет пула процессов. Слишком низкие лимиты удерживают throughput, слишком высокие — убьют диск и сеть всплесками (и спровоцируют отказы на стороне удаленных MX). Нужен баланс.

Сколько процессов вообще разрешено

default_process_limit — общий потолок для всех демонов, если не переопределено в master.cf для конкретной службы.

postconf -e default_process_limit=500
postfix reload

Начинайте консервативно: 200–500 на узле среднего класса обычно достаточно; дальше решает профиль трафика и размеры очереди.

Конкурентность исходящих доставок

Очередной менеджер ограничивает одновременные доставки на направление (домен/хост). Главные параметры:

• default_destination_concurrency_limit — базовое значение для всех транспортов.
• smtp_destination_concurrency_limit — именно для smtp‑клиента (исходящие доставки).
• initial_destination_concurrency — «разгон» конкурентности (сколько попыток открыть сразу).

postconf -e default_destination_concurrency_limit=20
postconf -e smtp_destination_concurrency_limit=40
postconf -e initial_destination_concurrency=5
postfix reload

Идея проста: если у вас много писем на один и тот же домен, повышайте конкурентность именно туда. Если удаленный MX отвечает ошибками «4xx» или начинает замедляться, снизьте лимит и включите мягкую задержку.

Плавная подача на «капризные» домены

Чтобы не выстрелить себе в ногу и не попасть под временные баны у крупных провайдеров почты, добавьте «заминку» между попытками на одно направление:

postconf -e smtp_destination_rate_delay=1s
postfix reload

Значение в 0.5–2 секунд часто успокаивает удаленную сторону, выравнивает latency и снижает количество повторных попыток.

Управление очередями: backoff и «время жизни»

Правильный backoff спасает диск и сеть, когда адресат временно недоступен. Здесь не нужно экстремальных значений, цель — не забивать active повторными попытками.

postconf -e minimal_backoff_time=5m
postconf -e maximal_backoff_time=1h
postconf -e maximal_queue_lifetime=5d
postconf -e bounce_queue_lifetime=2d
postfix reload

Для отдельных направлений с постоянными 4xx‑ответами лучше комбинация: умеренная конкурентность, smtp_destination_rate_delay и большее окно между ретраями.

Кэширование исходящих SMTP‑соединений (connection caching)

Зачем это нужно

Каждое новое исходящее соединение — это 3‑way TCP‑handshake, EHLO, опционально STARTTLS с полным TLS‑рукопожатием, а затем MAIL/RCPT/DATA. При десятках тысяч сообщений в час львиная доля CPU уходит именно «в воздух». Кэш снижает «соединительные» RTT и экономит CPU на шифровании.

Включаем и проверяем

В типовой установке кэш включается «по требованию», но консервативно. Явно зафиксируйте параметры и проверьте лимиты самого scache в master.cf.

# Разрешаем кэш исходящих соединений и повышаем TTL
postconf -e smtp_connection_cache_on_demand=yes
postconf -e smtp_connection_cache_time_limit=30s

# Для "горячих" доменов можно сделать кэш агрессивнее (пример шаблона)
postconf -e smtp_connection_cache_destinations=example.com

# Убедитесь, что сервис scache присутствует в master.cf и при необходимости повышен его maxproc
# Пример (редактировать master.cf, затем reload):
# scache unix  -       -       n       -       10      scache
postfix reload

Пояснения:

• smtp_connection_cache_time_limit — сколько держать неиспользуемое соединение в кэше; значения 15–60 секунд подходят для «волнами» поступающего трафика.
• smtp_connection_cache_destinations — ограничивает кэш только заданными направлениями; удобно, если большинство получателей «редкие», а 2–3 домена «горячие».
• scache — самостоятельный демон; при высокой параллельности ему может понадобиться больше процессов.

Кэш соединений не панацея: если удаленный MX явно закрывает соединение после каждого письма или отказывает в PIPELINING/CHUNKING, выгода будет меньше. Но в среднем экономия ощутимая.

TLS‑ресюмпция: уменьшаем стоимость шифрования

Без ресюмпции каждое STARTTLS‑рукопожатие — это эллиптическая (или классическая) криптография и несколько RTT. Ресюмпция (Session ID/Session Ticket) позволяет сократить время и CPU на последующих соединениях к тому же узлу. В Postfix есть кэш TLS‑сеансов для клиентской и серверной стороны.

Включаем кэш TLS‑сеансов

Создадим файлы кэша и активируем их. Форматы btree:/sdbm: подходят для локальной инсталляции.

mkdir -p /var/lib/postfix
chown postfix:postfix /var/lib/postfix
chmod 750 /var/lib/postfix

postconf -e smtpd_tls_session_cache_database=btree:/var/lib/postfix/smtpd_scache
postconf -e smtp_tls_session_cache_database=btree:/var/lib/postfix/smtp_scache
postfix reload

Так мы включили:

• smtpd_tls_session_cache_database — для входящих клиентов (серверная сторона).
• smtp_tls_session_cache_database — для исходящих подключений (клиентская сторона).

Кэш будет работать вместе с кэшированием исходящих соединений: при переоткрытии коннекта к тому же MX шанс на «reused session» заметно выше.

Наблюдаем ресюмпцию в логах

Чтобы видеть, как часто срабатывает повторное использование TLS‑сеанса, поднимите уровень логирования TLS на единицу.

postconf -e smtp_tls_loglevel=1
postconf -e smtpd_tls_loglevel=1
postfix reload

В логах появятся строки с пометками о параметрах рукопожатия и признаках повторного использования. При стабильном трафике на «горячие» домены вы увидите рост доли «reused/resumed».

Версии и наборы шифров

Для минимизации накладных расходов и рисков используйте только современные протоколы и известные быстрые суиты. Пример консервативных настроек:

postconf -e smtpd_tls_protocols=!SSLv2,!SSLv3
postconf -e smtp_tls_protocols=!SSLv2,!SSLv3
postconf -e tls_preempt_cipherlist=yes
postfix reload

Отдельно оцените кривые ECDHE на вашей криптобиблиотеке — они обычно дают лучший баланс между безопасностью и производительностью. Если вы обслуживаете свои MX, не забудьте о валидных сертификатах сервера — это повышает доверие и упрощает шифрованные коннекты.

Надежные SSL-сертификаты

Мы предлагаем широкий спектр SSL-сертификатов от GlobalSign по самым низким ценам. Поможем с покупкой и установкой SSL бесплатно!

Подробнее

Таймауты и взаимодействие с «медленными» клиентами

Слишком щедрые таймауты «захламляют» пул процессами, слишком жесткие — увеличивают повторы и рост очереди. Начальные ориентиры:

# Входящая сторона (smtpd)
postconf -e smtpd_timeout=60s
postconf -e smtpd_starttls_timeout=30s
postconf -e smtpd_helo_required=yes

# Исходящая сторона (smtp)
postconf -e smtp_connect_timeout=30s
postconf -e smtp_helo_timeout=60s
postconf -e smtp_mail_timeout=60s
postconf -e smtp_rcpt_timeout=60s
postconf -e smtp_data_init_timeout=120s
postconf -e smtp_data_xfer_timeout=300s
postfix reload

Отслеживайте «подвешенные» процессы в момент пиков; если видите накопление smtp с долгими DATA, обычно помогает ограничение конкурентности именно на эти направления и аккуратный smtp_destination_rate_delay.

PIPELINING, размер писем и буферы

Если удаленная сторона поддерживает PIPELINING, Postfix использует его автоматически. На своей стороне не отключайте его без причины. Для крупных писем проверьте лимиты и буферы, чтобы не терять соединения на середине:

postconf -e message_size_limit=52428800
postconf -e smtp_line_length_limit=990
postfix reload

При больших вложениях нагрузка смещается в диск и сеть. Следите за iowait и скоростью дисковой подсистемы: медленный диск быстро «закредитует» очередь deferred.

Практические профили настроек

Профиль «много доменов, равномерный поток»

• default_process_limit=300
• smtp_destination_concurrency_limit=30
• initial_destination_concurrency=5
• smtp_connection_cache_on_demand=yes, smtp_connection_cache_time_limit=30s
• smtp[d]_tls_session_cache_database=btree:..., smtp[d]_tls_loglevel=1
• smtp_destination_rate_delay=1s

Цель — умеренное расширение конкурентности и экономия на рукопожатиях за счет кэша и ресюмпции.

Профиль «несколько горячих доменов»

• Оставьте общий default_destination_concurrency_limit невысоким.
• Поднимите smtp_destination_concurrency_limit точечно через отдельный транспорт в master.cf, подключенный через transport_maps, для 2–3 доменов.
• Для этих доменов задайте smtp_connection_cache_destinations и увеличьте smtp_connection_cache_time_limit до 45–60 секунд.
• Добавьте smtp_destination_rate_delay=1–2s, если видите 4xx от удаленной стороны.

Так вы избежите «ддос» собственным трафиком отдельных MX и не перегрузите остальную доставку.

Мониторинг и верификация улучшений

Чтобы не настраивать «вслепую», фиксируйте ключевые метрики до и после изменений:

• Средний и пиковый msg/s на вход и выход.
• Размеры active/deferred, время пребывания писем в очереди.
• Доля TLS‑ресюмпций (по логам при smtp[d]_tls_loglevel=1).
• Количество установленных исходящих соединений и их средняя длительность.

Быстрые утилиты для тестов под нагрузкой (на стенде):

# Генератор исходящей нагрузки (часть инструментов Postfix)
smtp-source -s 100 -l 5120 -c -f sender@example.org -t rcpt@example.com your.mx:25

# Приемник для проверки входящего фронта на стенде
smtp-sink 0.0.0.0:2525 1000

На бою используйте аккуратный канареечный подход: меняйте 1–2 параметра, измеряйте динамику 30–60 минут, фиксируйте результат, откатывайтесь при ухудшении. Кроме производительности не забывайте о доставляемости: проверьте SPF и PTR для ваших исходящих IP — пригодится наш материал «Чек‑лист SPF/PTR для Postfix» по теме доставляемости и технических записей.

Типичные ловушки

• Слишком высокий default_process_limit: загрузите диск и сеть всплеском параллельных доставок, очередь начнет «пилить».
• Игнорирование «горячих» доменов: без точечного тюнинга вы либо перегрузите их, либо будете стоять в медленных ретраях.
• Отключенный TLS‑кэш: CPU уходит на криптографию, хотя ресюмпция могла бы сэкономить десятки процентов.
• Отсутствие или заниженный лимит процессов scache: кэш соединений включен номинально, но работает как «бутылочное горлышко».
• Агрессивные таймауты: рост отказов на стороне получателей, лавинообразный requeue.

Чек‑лист перед релизом изменений

• Сделан снэпшот текущей конфигурации: postconf -n сохранен.
• Выбраны KPI: целевой msg/s, допустимое время в очереди, верхняя граница CPU.
• Подтверждено наличие и лимиты scache в master.cf.
• Включены smtp[d]_tls_session_cache_database и smtp[d]_tls_loglevel=1.
• Проверены smtp_destination_* и default_destination_concurrency_limit на соответствие профилю.
• Назначен план отката и окно наблюдения.

Вывод

Производительность Postfix под нагрузкой редко упирается только в «железо». Основные выигрыши приходят от сокращения накладных расходов: кэширование исходящих соединений, TLS‑ресюмпция, разумные лимиты конкурентности на «горячие» направления и адекватные таймауты. Системно измеряйте, включайте кэш и ресюмпцию, придерживайтесь постепенных изменений — и вы увидите устойчивый рост throughput без излишних рисков для доставляемости.