reserved-smtp-in

<source-group>

Сколько входящих соединений гарантировано этой группе
в конфигурации это строкаreserved-smtp-in unlimitedвнутри блока <source-group>
Гарантия, а не потолок

Строка резервирует за группой источников определённое число входящих соединений. Это «не меньше» — в отличие от соседнего max-smtp-in, который говорит «не больше».

Резерв вычитается из общего предела узла total-max-smtp-in: слоты, отданные группе, для всех остальных перестают существовать — даже пока группа их не занимает.

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

Умолчание в руководстве выглядит опечаткой. Для директивы, которая резервирует число слотов, там написано unlimited — то же значение, что у соседнего потолка. Зарезервировать «неограниченно» нельзя, поэтому читать это следует как «резерва нет», а не как «резерв бесконечен». Похоже на скопированную строку из соседнего раздела.

Вторая половина ловушки настоящая: резерв отнимается у всех остальных сразу. Сумма резервов, близкая к общему пределу узла, оставляет незарезервированным сторонам почти ничего — и узел начинает отказывать в соединениях, хотя половина слотов простаивает.

Что делает Хаб. Не пишет: групп источников в его конфигурации нет, и резервировать нечего — предел на входящие задан один на узел.

Между тем случай для резерва у нас есть: узел одновременно принимает подачу и входящую почту — жалобы, асинхронные отказы и роль-адреса. Второго мало, но потерять его хуже, чем задержать подачу.

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

Что ставить. Резерв считают от того, сколько соединений группе нужно в худший момент, а не в среднем:

Значение Когда
не писать делить узел не между кем
5–10 приём жалоб и отчётов: соединений мало, но терять их нельзя
заметная доля общего сторона, для которой узел и заводился

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

Назначение — из руководства, § 3.3.9.2. Умолчание там указано как unlimited, что для резерва бессмысленно; читаем как «резерва нет» — это наше чтение. Разбивка значений наша.
Пример в конфигурации
# пять слотов из общего предела узла достаются группе всегда
<source-group localSources>
    max-smtp-in 10
    reserved-smtp-in 5</source-group>
Группа не займёт больше десяти соединений разом, но пять получит при любой загрузке узла. Эти пять для остальных не существуют, даже когда группа простаивает.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

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

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

Резервируют почти весь общий предел

наш опыт

Чем чреватоНезарезервированным сторонам остаются единицы слотов, и узел начинает отказывать в соединениях при том, что половина зарезервированных простаивает.
Как заметитьОтказы в соединениях при невысокой фактической загрузке.
Как правильноДержать сумму резервов заметно ниже общего предела и резервировать только тем, кого нельзя вытеснять.

Читают умолчание буквально

§ 3.3.9.2

Чем чреватоУказанное в руководстве unlimited для резерва бессмысленно: зарезервировать неограниченное число слотов нельзя. Прочитанное буквально, оно наводит на мысль, что резерв уже есть, — тогда как его нет.
Как заметитьСтроки резерва нет, а на гарантию слотов рассчитывают.
Как правильноСчитать, что без строки резерва нет, и задавать число явно.

Резервируют для группы без участников

§ 3.3.7.55

Чем чреватоСлоты вычитаются из общего предела узла и не достаются никому: группа объявлена, но ни один источник не назвал её своей. Узел теряет часть пропускной способности впустую.
Как заметитьОбщий предел как будто уменьшился, а группа не используется.
Как правильноПроверить, что участники группы названы строкой группы в своих блоках источника.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
Справочные данные
Синтаксис
reserved-smtp-in <integer>
Значения
целое число соединений
Умолчание
unlimited § 3.3.9.2
Применение
reload, перезапуск не нужен
Очередь
уже поставленное в очередь не затронет
Где писать
<source-group>
Сколько раз
один раз в блоке
Всё здесь — из руководства, с разделом.
Наследование
Директива живёт в <source-group> и относится к одной группе. Наследования между группами нет. Но резерв вычитается из общего предела узла — то есть действует не только на свою группу, а на все остальные сразу.
Как проверить на узле
Резервы видно в конфигурации; их согласованность с общим пределом придётся считать самому:
grep -n -A3 '^<source-group' /etc/pmta/config
grep -n 'total-max-smtp-in' /etc/pmta/config
Сумма резервов должна быть заметно меньше общего предела: остаток — это всё, что достанется сторонам без резерва. Проверки со стороны MTA нет.
В Хабе
Цена ошибки
обратимо: вредит, пока стоит
Сценарии
Подключить платформу отправки · Разделение отправителей
Соседние настройки блока <source-group>:max-smtp-inВсе 2 директив блока →