max-smtp-data-volume-rate

<virtual-mta-pool>

Байтовый потолок, который достаётся каждому адресу пула
в конфигурации это строкаmax-smtp-data-volume-rateвнутри блока <virtual-mta-pool>
То же имя ещё 1:<virtual-mta><virtual-mta-pool>— часть из них другие настройки, часть та же самая
Одна строка на группу — но не общая на группу

Тот же байтовый потолок, что и у отдельного адреса, записанный в пуле. Смысл настройки полностью описан на странице max-smtp-data-volume-rate блока <virtual-mta> — руководство здесь и само отсылает туда, повторяя лишь грамматику значения и пример.

Разница между блоками одна, и она в арифметике. Пул не делит значение между участниками, а передаёт его каждому: раздел о пулах говорит о своих директивах «наследуются адресами-участниками». Строка 6g/10h в пуле из пяти адресов означает шесть гигабайт у каждого, то есть до тридцати с пула.

Зачем тогда пул. Ради одной точки правки: изменить норму группы из двадцати адресов проще одной строкой, чем двадцатью. Значение, записанное в самом адресе, пуловое перекрывает — исключение для одного участника делается там.

Умолчания у пуловой формы руководство не даёт. Строки нет — действует то, что унаследовано или задано в самом адресе; у адреса это unlimited.

Главная ловушка. Потолок выглядит групповым, а работает поадресным — и меняется сам собой при изменении состава пула. Добавили шестой адрес в пятёрку — разрешённый объём группы вырос на пятую часть, хотя конфигурацию никто не трогал. Настоящей границы на группу эта строка не даёт: такой границы в блоке пула вообще нет.
Что делает Хаб. Не пишет. В пуле Хаб держит только список участников — ни лимитов, ни ключей подписи туда не кладёт: норму прогрева считает планировщик, и она поадресная по смыслу.

Это осознанно. Пуловая строка раздала бы одно число всем участникам разом, а прогрев ведёт каждый адрес по своему графику: у одного третий день, у другого второй месяц.

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

Ставить, когда у адресов группы одинаковая роль. Одна норма на всех оправданна, пока адреса взаимозаменяемы. Как только у одного появился свой график, пуловая строка начинает мешать: её приходится перекрывать в самом адресе, и настройка расползается по двум местам.

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

Для прогрева не годится. Разные адреса пула почти всегда на разных стадиях, а строка не умеет их различать.

Совет о взаимозаменяемости — наш. Из руководства здесь грамматика значения, отсылка к форме адреса и правило раздела о пулах: директивы наследуются адресами-участниками.
Пример в конфигурации
# 6g/10h достаётся каждому — с пула это до 12g за те же десять часов
<virtual-mta mta1>
</virtual-mta>
<virtual-mta mta2>
</virtual-mta>
<virtual-mta-pool pool>
    max-smtp-data-volume-rate 6g/10h    virtual-mta mta1
    virtual-mta mta2
</virtual-mta-pool>
Пример из руководства, с его же числами. Двенадцать гигабайт с пула, а не шесть: значение достаётся каждому участнику как собственное.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

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

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

Делят норму группы, считая строку общей

§ 3.3.13

Чем чреватоПуловое значение достаётся каждому участнику. Норму пула записали целиком — фактический потолок оказался во столько раз больше, сколько адресов в пуле.
Как заметитьСуммарный объём группы кратен числу участников и не совпадает с задуманным ни на один день.
Как правильноДелить задуманный объём на число адресов и держать в голове, что при пополнении пула делитель меняется.

Ждут, что пул выровняет участников

§ 3.3.13.8

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

Задают строку и в пуле, и в адресе, ожидая суммы

§ 3.3.13

Чем чреватоЗначение адреса перекрывает пуловое целиком, а не добавляется к нему. Пуловая строка при этом остаётся в файле и читается как действующая, хотя на этом участнике не работает.
Как заметитьУ одного из адресов действует не то число, что записано в пуле, и найти его в пуловом блоке не получается.
Как правильноПроверять действующее значение у самого участника командой настроек адреса. Исключения оставлять только там, где они нужны, и помечать комментарием.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
Справочные данные
Синтаксис
max-smtp-data-volume-rate <see-reference>
Значения
unlimited · 0 · N с единицей b|k|m|g|t и знаменателем /[X] и d|h|m|s — грамматика общая с формой адреса
Применение
reload, перезапуск не нужен
Очередь
уже поставленное в очередь не затронет
Где писать
<virtual-mta-pool>
Сколько раз
один раз в блоке
Всё здесь — из руководства, с разделом.
Наследование
Участники получают пуловое значение как своё; значение, заданное в самом адресе, перекрывает пуловое. Ниже — блоки приёмника внутри адреса, но там директива называется иначе (max-data-volume-rate) и ограничивает очередь, а не адрес. Подхватывается по pmta reload.
Как проверить на узле
У пула своей команды нет — действующее значение смотрят у участника, и заодно проверяют, что до него дошло:
pmta show vmta-settings mta1
pmta show vmta-settings mta2
Обе печатают max-smtp-data-volume-rate — и обе покажут одно и то же число, если оно пришло из пула. Расхождение означает, что у одного из адресов есть своя строка, перекрывающая пуловую.
В Хабе
Цена ошибки
обратимо: вредит, пока стоит
Сценарии
Ротация адресов отправки