total-max-transmissions-api

Global

Потолок одновременных соединений Transmissions API
в конфигурации это строкаtotal-max-transmissions-api 50внутри блока Global
Потолок на подачу по HTTP, а не по SMTP

Сколько одновременных входящих соединений Transmissions API узел согласен обслуживать. Это второй способ подачи писем — не по SMTP, а по HTTP: подающая система шлёт письмо запросом, а не почтовой сессией.

Один из трёх потолков уровня узла. Рядом с ним total-max-smtp-in для входящих почтовых соединений и total-max-smtp-out для исходящих. Все три ограничивают экземпляр PowerMTA целиком, а не отдельный адрес или приёмник.

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

Директива появилась в шестой версии. В PowerMTA 5 её нет, как нет там и самого Transmissions API в нынешнем виде.

Главная ловушка. Строка ограничивает подачу по HTTP и ничего не делает для SMTP. На узле, куда всё подают почтовой сессией, она не участвует ни в чём — сколько её ни поднимай, число подающих соединений упрётся в total-max-smtp-in. Спутать легко: имена похожи, оба потолка на подачу, оба уровня узла.
Что делает Хаб. Не пишет — остаются вендорские пятьдесят.

Весь парк подаёт письма по SMTP: и прогрев Хаба, и подающие платформы открывают почтовую сессию и отдают письмо в ней. Transmissions API у нас не задействован ни одной площадкой, поэтому и ограничивать нечего. Строка понадобится, если появится площадка, подающая по HTTP.

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

Не трогать, пока подача идёт по SMTP. Пятьдесят соединений для интерфейса, которым не пользуются, — не расход и не риск.

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

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

Порядок расчёта — наша рекомендация. Из руководства здесь умолчание 50, предупреждение об отсутствии верхней границы и то, что предел задают возможности машины.
Пример в конфигурации
# потолок уровня узла — вне всяких блоков
total-max-transmissions-api 100total-max-smtp-in 100
Обе строки пишутся на верхнем уровне конфигурации, без блока. Первая считает подачу по HTTP, вторая — по SMTP; общий у них только запас дескрипторов машины.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

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

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

Поднимают этот потолок, упираясь в почтовую подачу

§ 3.3.1.1

Чем чреватоСтрока считает только соединения Transmissions API. На узле, куда подают по SMTP, она ни на что не влияет, а настоящий предел остаётся в total-max-smtp-in — там, где его и не трогали.
Как заметитьПодающая система получает отказы в соединении, хотя потолок в конфигурации поднят.
Как правильноПосмотреть, каким интерфейсом идёт подача, и править потолок того интерфейса. Имена похожи, интерфейсы разные.

Пишут большое число, полагаясь на проверку MTA

§ 3.3.1.1

Чем чреватоВерхней границы MTA не проверяет — конфигурация с любым числом разберётся без замечаний. Упрётся всё в дескрипторы и память машины, и проявится это под нагрузкой, а не при перезагрузке конфигурации.
Как заметитьПод нагрузкой соединения перестают приниматься раньше выставленного потолка; в системном журнале видны отказы по дескрипторам.
Как правильноСчитать от возможностей машины и проверять предел дескрипторов процесса. Руководство предупреждает об этом для всех трёх потолков уровня узла.

Ищут директиву на узле с PowerMTA 5

§ 3.3.1.1

Чем чреватоВ пятой версии её нет. Строка, перенесённая из шестой конфигурации, окажется нераспознанной — и это не опечатка, а разница версий.
Как заметитьКонфигурация, работавшая на шестой версии, не принимается на пятой, а имя директивы в её руководстве не находится.
Как правильноСверять версию узла перед переносом конфигурации. Проверять разбор командой проверки конфигурации, не полагаясь на то, что файл переносим между версиями.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
Справочные данные
Синтаксис
total-max-transmissions-api <number>
Значения
положительное целое; верхнюю границу MTA не проверяет — её задаёт машина
Умолчание
50 § 3.3.1.1
Применение
reload, перезапуск не нужен
Очередь
уже поставленное в очередь не затронет
Где писать
Global
Сколько раз
один раз в блоке
Всё здесь — из руководства, с разделом.
Наследование
Не наследуется и не переопределяется: это настройка экземпляра целиком. В блоках она не встречается, перекрыть её для отдельного адреса или приёмника нельзя. Подхватывается по pmta reload; уже открытые соединения при снижении потолка не обрываются.
Как проверить на узле
Действующее значение печатается вместе с прочими настройками узла:
grep -n 'total-max-transmissions-api' /etc/pmta/config
pmta show status
В конфигурации строки может не быть вовсе — тогда действуют вендорские пятьдесят. Сводка состояния покажет, сколько соединений открыто сейчас; если Transmissions API не задействован, там будет ноль.
В Хабе
Цена ошибки
безопасно: неверное значение ничего не ломает
Сценарии
Подключить платформу отправки