show queues

критично

Состояние очередей вместе с историей событий
Самая содержательная команда чтения — и события в ней по умолчанию

Печатает состояние очередей: сколько получателей ждёт, сколько килобайт, сколько соединений открыто, в каком режиме очередь. Очередь здесь — пара «приёмник плюс адрес отправки» (queue-identity), поэтому один домен с трёх адресов даст три строки.

События включены по умолчанию. Вместе с очередями команда печатает последние пятьдесят доставок, отказов и задержек. Руководство говорит об этом прямо и даёт ключ, чтобы их скрыть, — а раз есть ключ «скрыть», значит по умолчанию они есть.

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

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

Сортировка — по имени, по числу получателей или по объёму; по умолчанию печатается двадцать очередей.

Главная ловушка — умолчание в двадцать очередей. На узле, где очередей сотни, команда без ключа покажет двадцать и ничем не намекнёт, что остальные существуют. Вывод выглядит полным и полным не является. Тот же вопрос по узлу целиком надо задавать с явным числом, а лучше вместе с сортировкой — иначе двадцать строк окажутся случайными.

И второе — имя домена без адреса отправки. show queues gmail.com показывает одну очередь gmail.com/{default}, а не все очереди этого приёмника; все — gmail.com/* (проверено на узле 15.09.2026: из трёх очередей домена команда показала одну пустую).

Что делает Хаб. Вызывает через POST /command с ключом узла: раз в пять минут show queues –mode=backoff — так он складывает эпизоды щадящего режима, — и show queues –paused=yes для снимка управления. Длину передаёт явно, –maxitems=10000: без неё выборка обрезалась бы двадцатью очередями, и эпизоды открывались бы и закрывались по тому, что попало в верхушку. Выборку, дошедшую до этой длины, Хаб считает неполной и эпизоды по ней не закрывает. Перечень очередей для экрана «Мониторинг PMTA» и телеметрии Хаб берёт запросом /queues.

Историю смены режимов Хаб восстанавливает опросом — сравнивает выборку с прошлой. Ключ –mode-events отдал бы её сразу и точнее: опрос между двумя обходами слеп, и короткий заход в щадящий режим он пропустит.

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

Ключи, которые стоит держать в руках:

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

Начинать с сортировки по получателям. Двадцать самых крупных очередей отвечают на большинство вопросов; двадцать случайных — ни на один.

Отбор по приостановке — первое, что стоит проверить, когда очередь «не отправляет»: остановлена оператором и придержана узлом выглядят одинаково, а лечатся по-разному.

Порядок разбора и советы по ключам наши. Из руководства здесь состав вывода, умолчание в двадцать очередей, включённые по умолчанию события и полный набор отборов.
Пример в конфигурации
# двадцать самых крупных очередей с историей смены режимов
pmta show queues --maxitems=20 --sort=rcpt --mode-events# только те, что в щадящем режиме, без шума событий
pmta show queues --mode=backoff --no-rcpt-events
Выделенная строка отвечает на вопрос «что сейчас на узле»: крупнейшие очереди и когда каждая меняла режим. Нижняя — на вопрос «что придержано».
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

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

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

Принимают двадцать строк за весь узел

§ 6.3.14

Чем чреватоПо умолчанию печатается двадцать очередей, и вывод ничем не намекает, что остальные есть. Вопрос «что творится на узле» получает ответ по случайной двадцатке.
Как заметитьРазбор упирается в то, что проблемной очереди в выводе нет, хотя письма для неё копятся.
Как правильноЗвать с явным числом и сортировкой по получателям — тогда двадцать строк будут двадцатью крупнейшими.

Путают приостановленную очередь с придержанной узлом

§ 6.3.14

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

Восстанавливают историю режимов опросом

§ 6.3.14

Чем чреватоОпрос между двумя замерами слеп: очередь, успевшая войти в щадящий режим и выйти, не попадёт в историю вовсе. У команды есть ключ, отдающий переходы сразу.
Как заметитьВ истории переходов пусто, а отказы приёмника были.
Как правильноСпрашивать историю ключом, а не выводить её из разницы между замерами.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
⇄

Связанные записи

5 связей

Как проверить на узле
Команда сама и есть проверка. Сопоставить её стоит с двумя другими срезами:
pmta show queues --sort=rcpt --maxitems=50
pmta show domains
pmta show settings gmail.com/mta-news-1
Первая — по строке на очередь, вторая складывает адреса и даёт по строке на домен: числа не совпадут, и это не ошибка. Третья покажет, какие лимиты действуют на конкретную очередь из первой.
В Хабе
Цена ошибки
безопасно: неверное значение ничего не ломает
Сценарии
Разобраться с доставляемостью · Настроить темп под провайдера · Разобрать зависшую очередь
Важность
критично