Я наблюдаю проблемы с производительностью при приеме почты Postfix, когда очередь уже большая. Есть какие-нибудь предложения?

Я наблюдаю проблемы с производительностью при приеме почты Postfix, когда очередь уже большая. Есть какие-нибудь предложения?

Я использую postfix для окончательной доставки для почтовой системы, которую я написал. Поэтому эта установка postfix принимает почту только от меня и возвращает ее. Когда очередь postfix пуста, она может принять часть почты примерно за 5 мс. Когда в очереди 150–200 тыс. сообщений или около того, скорость передачи от меня к postfix очень низкая, около 50–100, иногда 500 мс.

У меня есть время лога для каждого фрагмента SMTP-разговора, поэтому я могу видеть, куда уходит время. Часть времени уходит, когда я жду ответа от команды RCPT TO, но большая часть времени исчезает после того, как я отправляю последнюю точку, прежде чем я получаю ответ "250 Okay Queued as...".

Я думаю, что задержка RCPT TO связана с поиском DNS, но это не помогает мне со временем ожидания в очереди. Я держу один TCP-сокет открытым для всех отправляемых писем и RSET-сообщение для каждого письма, поэтому не теряю время на создание и разрыв TCP-соединений, все время уходит на ожидание, пока postfix поставит сообщение в очередь.

Все, что я читал о настройке производительности postfix, связано с управлением очередями и отправкой почты для того или иного домена здесь и там. Но меня беспокоит получение postfix только для быстрого приема почты в первую очередь.

Есть ли способ узнать, что делает postfix все это время, или есть способ ускорить его работу? Очередь /var/spool/postfix находится на локальном диске, поэтому я не могу сделать ее быстрее.

Какие-либо предложения?

решение1

Установите следующее вmain.cf

hash_queue_depth = 3
hash_queue_names = deferred, defer, incoming, active

Это создает подкаталоги во входящих и активных очередях, так что плоские каталоги не содержат все письма сразу. Теперь они помещаются в подкаталоги.

Но обратите внимание: наличие 150-200 тыс. сообщений, ожидающих доставки, показывает невероятно неверное понимание сбалансированной отправки писем. Мне это кажется спамом...

решение2

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

решение3

Это очень старый вопрос, но технологии не сильно изменились / существующие ответы не очень полезны.

Когда в очереди около 150–200 тыс. сообщений, скорость передачи сообщений от меня к Postfix становится очень медленной.

Судя по тому, как поставлен этот вопрос, создается впечатление, что автор ссылается наактивныйочередь здесь (Postfix имеет несколько очередей). И Postfix делает именно то, что должен делать, чтобы не задохнуться. Активная очередь — это то место, где все умные штуки с планированием доставки. Когда она становится слишком большой, планирование становится узким местом.

Если вы столкнулись с проблемами производительности, связанными с нагрузкой, рекомендуется проверить показатели нагрузки, ЦП и ввода-вывода, чтобы выявить узкие места в оборудовании.

Если вы используете только ретранслятор отправки, уменьшение in_flow_delay здесь уменьшит регулирование клиентов. Но вам нужно сохранить размер активной очереди небольшим. Ограничение скорости, с которой сообщения передаются из входящей очереди в активную очередь, может помочь здесь. Но лучшее решение — быстрее извлекать данные из активной очереди. Лучшее, что вы можете сделать здесь, — это хорошее управление репутацией, быстрый DNS и, если возможно, распределение отправки по нескольким IP-адресам. Уменьшение частоты повторных попыток также поможет со скоростью заполнения активной очереди и с поставщиками, которые ограничивают прием на основе частоты попыток подключения.

SPF, DMARC и DKIM (правильно настроенные) следует рассматривать как необходимые.

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

Связанный контент