☰

Производительность постфикса

tag-icon • tag-icon performance postfix performance-tuning
Производительность постфикса

Запускаю postfix на ubuntu, отправляю много почты (~ 1 миллион сообщений) в день. Нагрузки очень высокие, но не слишком большие с точки зрения нагрузки на процессор и память. Кто-нибудь был в похожей ситуации и знает, как устранить узкое место?

Вся почта на этом сервере является исходящей.

Я бы предположил, что узким местом является диск.

Просто обновление, вот как выглядит iostat:

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.00    0.00    0.12   99.88    0.00    0.00

Device:         rrqm/s   wrqm/s     r/s     w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await  svctm  %util
sda               0.00    12.38    0.00    2.48     0.00   118.81    48.00     0.00    0.00   0.00   0.00
sdb               1.49    22.28   72.28   42.57   629.70  1041.58    14.55   135.56  834.31   8.71 100.00

Соответствуют ли эти цифры производительности, которую можно ожидать от одного диска?

sdb предназначен для postfix.

Я думаю, что это перетасовка очереди, из входящей->активной->отложенной.

Более подробная информация из вопросов:

Сервер: четырехъядерный процессор Xeon(R) CPU E5405 @ 2.00GH с 4 ГБ оперативной памяти

Средняя загрузка: 464,88, 489,11, 483,91, 4 ядра. но использование памяти и процессора минимально

Постфиксные экземпляры от 16 до 32

решение1

Это может показаться немного безумным, но вам следует:

  1. Уменьшите ведение журнала до необходимого минимума. Сделайте так, чтобы syslog регистрировал только mail.err или выше.
  2. Добавьте больше оперативной памяти. Да, Postfix это не нужно, но дополнительная оперативная память означает дополнительный кэш страниц для ядра.
  3. Вы не упомянули, какая файловая система находится на /dev/sdb (что тоже имеет значение), но определенно переключите ее на noatime, что должно хотя бы немного снизить нагрузку.
  4. Посмотрите, насколько велик ваш /var/spool/postfix. Если он меньше пары гигабайт, рассмотрите возможность его переноса на ramdisk.

решение2

Я не согласен с теми, кто предлагает использовать RAM-диск для "/var/spool/postfix". Это означает, что вся ваша почтовая очередь будет храниться в RAM. Если ваш сервер выйдет из строя или отключится питание, сообщения в очереди исчезнут навсегда. Это действительно плохо с точки зрения клиента/пользователя, поскольку сообщение уже было успешно принято для доставки. Хуже того, ваш сервер не отправит уведомление о том, что электронное письмо отклонено или не может быть доставлено, поскольку очередь будет пуста, когда сервер снова запустится.

Вместо этого я бы добавил столько быстрых дисков, сколько вы можете себе позволить; я не могу точно оценить, сколько вам понадобится с предоставленной информацией. Из вывода "iostat" выше, похоже, что вы делаете ~ 120 IOPS для 'sdb' (сумма r/s и w/s). Вы можете разумно оценить, что один диск SCSI или FC на 15k RPM будет обрабатывать 150 IOPS. Я бы начал с 5 дисков SCSI на 15k RPM и приличного RAID-контроллера. Настройте его как RAID-10 на 4 дисках с 1 горячим резервом. Я не уверен, что это полностью решит вашу проблему, но это определенно не ухудшит ее.

решение3

Запустите postfix под каким-нибудь профайлером (gprof?) или посмотрите в журналах. Postfix записывает много информации о времени, которая может подсказать, где задержка. Обычные места для поиска:

  1. Производительность диска. Возможно, пришло время для RAID-10 для вашей очереди.
  2. Любой сетевой ввод-вывод сообщений. Черные списки DNS? SAV?
  3. Фильтры Milters и другие установленные вами фильтры.
  4. Аутентификация и поиск UID выполняются по сети или в процессе (ldap, sql).
  5. не используя прокси: для медленных карт (как выше)

решение4

Определенно похоже, что ваша дисковая подсистема должна быть рассмотрена как часть проблемы. Из-за того, как postfix перемешивает файлы вокруг /var, я бы посоветовал погуглить "tweak ext3 filesystem" (по крайней мере, установив noatime и writeback), чтобы посмотреть, нельзя ли повысить производительность на уровне файловой системы.

У меня есть два кластера серверов, которые выполняют функции DNS и исходящего SMTP для электронной почты клиентов и обрабатывают 250 тыс. сообщений ежедневно (2–10 тыс. в час), но при этом не имеют ничего общего с такой нагрузкой на ввод-вывод.

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