Listen queue overflow во FreeBSD при почтовой рассылке. Где подкрутить?

Question

[alexan]

Дело происходит так.
Выделенный сервер. PHP скрипт делает небольшую почтовую рассылку, 1000-2000 писем. При этом почему-то забивается системная очередь у pickup (вспомогательный сервис у Postfix):

netstat -Lan
...
unix  151/0/100        public/pickup
...

и система ругается:

kernel: sonewconn: pcb 0xfffff8004cbbf870: Listen queue overflow: 151 already in queue awaiting acceptance
last message repeated 972 times

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

Feb 15 17:01:02 theserver postfix/pickup[29787]: 7627929DE4A5: uid=1001 from=<theuser>
Feb 15 17:01:02 theserver postfix/cleanup[33164]: 7627929DE4A5: message-id=<[e-mail]>
Feb 15 18:01:02 theserver opendkim[972]: 7627929DE4A5: DKIM-Signature field added (s=thedomen, d=thedomen.ru)
Feb 15 17:01:02 theserver postfix/qmgr[81797]: 7627929DE4A5: from=<[e-mail]>, size=1811, nrcpt=1 (queue active)
Feb 15 17:01:03 theserver postfix/smtp[33168]: 7627929DE4A5: to=<[e-mail]>, relay=mx.yandex.ru[87.250.250.89]:25, conn_use=11, delay=58, delays=57/0/0/0.61, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued on mxfront3j.mail.yandex.net as 1487167263-xPE7azV17j-12jSJTiT)
Feb 15 17:01:03 theserver postfix/qmgr[81797]: 7627929DE4A5: removed

..но кто же его знает, что там происходит если очередь на входе уже переполнена. Может система просто отбрасывает письма и они не попадают в очередь?

Разумное увеличение размера очереди результата не приносит.
Конфиг postfix-а ничего особенного не содержит, его отличия от чистого установочного конфига примерно такие:

smtpd_recipient_restrictions = permit_mynetworks, reject_unauth_destination, check_recipient_access hash:/usr/local/etc/postfix/access

# Запрещение приёма почты с некоторых адресов
smtpd_sender_restrictions = hash:/usr/local/etc/postfix/incoming_access

smtpd_banner = $myhostname ESMTP

local_recipient_maps = hash:/usr/local/etc/postfix/recipient_map $alias_maps

# DKIM
smtpd_milters = inet:127.0.0.1:8891
non_smtpd_milters = $smtpd_milters
milter_default_action = accept

Где копать?

Answer 1

[athacker]

Это очередь так-то не почты, а входящих TCP-соединений. Тупит ваш pickup, не успевает обрабатывать новые соединения. Воткните паузу в скрипт, который письма шлёт, пусть шлёт не всю 1000 сразу, а по 100 за раз. Либо смотрите, из-за чего pickup может тупить. Может, нагрузка на диск высокая. Может, памяти мало и оно свопится постоянно.

Comments

[alexan]

Воткнуть паузу - это значит на приличных рассылках в более чем 100К (они тоже иногда бывают) можно будет весь день отдыхать.

pickup тупит - факт, вот и хочется понять чего он тупит. Раньше не тупил. Памяти хватает, своп почти не используется.

Только это же не входящие TCP соединения, а внутренние unix sockets.

[athacker]

Попробуйте non_smtpd_milters вырубить. Возможно, пикап тупит потому, что opendkim (это же он у вас на 8891 порту висит?) не успевает принимать от него почту.

[alexan]

Да это он, спасибо, попробую. Но разве не должны письма сначала попасть в очередь, а уже потом по мере сил оттуда разгребаться (в т.ч. и для добавления подписей opendkim)?

[alexan]

athacker: похоже отключение opendkim действительно влияет. Можете посоветовать как настроить Postfix, чтобы нормально наполнял/разгребал/подписывал, без костылей-задержек со стороны отправщика писем?

Answer 2

[Александр Черных]

в ком стороке дайте
sysctl kern.ipc.somaxconn

Comments

[alexan]

Там всё хорошо, до энтих лимитов дело не доходит.
kern.ipc.somaxconn: 4096

[Александр Черных]

alexan: сообщение ядра. нужно смотреть в тут сторону и настройки sysctl

[alexan]

Александр Черных: я увеличивал переполняемую очередь в несколько раз, не помогает. Много лет всё работало хорошо, а сломалось в какой-то момент возможно, со обновлением postfix, или чего-то ещё. Отправить 1000 писем - не такая большая задача, чтобы лимитов по умолчанию не хватало.

[Александр Черных]

alexan: высылаем по 140К мейлов в сутки.
напишите мне на [e-mail] я Вам скину ядро и sysctl.conf

[alexan]

Александр Черных: не помогли параметры. Но всё равно спасибо.

Answer 3

[Max Kostikov]

Задайте значение kern.ipc.soacceptqueue больше текущего в sysctl.conf.
Старый параметр

kern.ipc.somaxconn

deprecated