Demo
Demo
База знаний PMTA›Блок <source-group>›Директива§ 3.3.9.1

max-smtp-in

<source-group>

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

Умолчание — unlimited. Строка ограничивает число одновременных входящих соединений от всех источников группы вместе.

Это потолок, а не гарантия: он говорит «не больше», а «не меньше» говорит соседняя строка — reserved-smtp-in. Обе нужны там, где узел делят несколько сторон: одной ставят потолок, чтобы не съедала всё, другой — резерв, чтобы ей всегда осталось.

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

Главная ловушка — сумма потолков не обязана сходиться с общим. Ничто не мешает задать трём группам по 500 соединений при общем потолке узла в 1000. Конфигурация при этом законна, а поведение получается не то, что задумано: две группы вдвоём выберут общий предел, и третьей не достанется ничего, хотя её собственный потолок не тронут.

Проверять надо арифметику, а не строки: MTA её не проверяет.

Что делает Хаб. Не пишет: групп источников в его конфигурации нет. Предел на входящие соединения задан один на узел — total-max-smtp-in 1000 в базовой конфигурации.

Для узла парка этого достаточно: подающая сторона одна, и делить между сторонами нечего. Группы понадобились бы на узле, которым пользуются несколько клиентов.

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

Что ставить. Значение считают от общего потолка узла, а не от нужд группы:

Значение Когда
unlimited (умолчание) подающая сторона одна, делить нечего
доля от общего потолка несколько сторон, и ни одна не должна выбрать всё
небольшое число сторона, которой много соединений не нужно, но которая может их занять

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

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

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

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

Раздают потолки, не сверяясь с общим пределом узла

наш опыт

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

Принимают потолок за гарантию

§ 3.3.9.1

Чем чреватоПотолок говорит только «не больше». Группа с потолком в десять соединений может не получить ни одного, если узел занят другими.
Как заметитьПотолок задан, а соединения группы всё равно не проходят.
Как правильноДобавить резерв: гарантию даёт только он.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
Справочные данные
Синтаксис
max-smtp-in <integer>
Значения
unlimited или целое число соединений
Умолчание
unlimited § 3.3.9.1
Применение
reload, перезапуск не нужен
Очередь
уже поставленное в очередь не затронет
Где писать
<source-group>
Сколько раз
один раз в блоке
Всё здесь — из руководства, с разделом.
Наследование
Директива живёт в <source-group> и относится к одной группе. Наследования между группами нет: блоки групп не сливаются, как сливаются источники. Но действует строка под общим потолком узла — тот сильнее.
⇄

Связанные директивы

2 связи

Зависит от

total-max-smtp-inGlobalПотолки групп действуют под общим пределом узла: кончился общий — групповой уже ничего не решает. § 3.3.1.3

Работают в паре

reserved-smtp-in<source-group>Один говорит «не больше», другая — «не меньше»; вместе они и делят узел между сторонами. § 3.3.9.2

Сюда ссылаются

source-group<source>Общий потолок соединений группы; задаётся в блоке группы, а не здесь. § 3.3.9.1

Как проверить на узле
Записанные пределы видно в конфигурации, занятые соединения — на узле:
grep -n -A3 '^<source-group' /etc/pmta/config
pmta show status | grep -i 'inbound\|smtp-in'
Сумму потолков групп стоит сравнить с общим потолком узла: MTA их согласованность не проверяет, и расхождение проявляется только под нагрузкой.
◇

Что ещё почитать

3 статьи

◇Как письмо попадает в MTAШесть описанных способов подачи: расширенный SMTP, четыре языковые обвязки и каталог, за которым узел следит на диске.◇Кому разрешено сдавать почту и для кого её приниматьИз коробки узел принимает подачу только с самой машины; два разных вопроса — «кто может слать через нас» и «на чьи адреса мы принимаем» — решаются разными директивами.◇Заголовки, которыми отправитель управляет доставкойШесть служебных заголовков позволяют подающей стороне выбрать поток, пометить письмо заданием, задать настройки и ключ подписи, идентификатор конверта и расписание; каждый разрешается отдельно и по источникам.

В Хабе
Цена ошибки
обратимо: вредит, пока стоит
Сценарии
Подключить платформу отправки
Соседние настройки блока <source-group>:reserved-smtp-inВсе 2 директив блока →