Назад | Перейти на главную страницу

Производительность Postfix

Запуск 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) E5405 @ 2,00 ГГц с оперативной памятью 4 ГБ

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

Экземпляры Postfix от 16 до 32

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

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

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

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

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

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

Миллион сообщений в день - это примерно 11 сообщений в секунду при постоянной пропускной способности. Postfix сам по себе должен быть способен обрабатывать, по крайней мере, на порядок больше, чем на серверном оборудовании начального уровня. Так что я подозреваю, что у вас есть нечто большее, чем просто запущенный постфикс или очень неравномерно распределенные пики пропускной способности.

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

Найдите время, чтобы настроить ввод / вывод на обоих /var/spool/postfix и /var/log. Лучшая практика для загруженных постфиксных серверов - разделить их на разные шпиндели и убедиться, что асинхронное ведение журнала включено. префикс имени файла журнала для вашего почтового журнала с тире в Linux.

mail.info                              -/var/log/mail.log

или похожие.

Если вы используете amavisd-new, убедитесь, что его рабочая область находится в файловой системе tmpfs. Мы обычно надеваем это /tmp/vscan/. Это безопасно, поскольку amavisd-new не возвращает ответ о конце данных до тех пор, пока нисходящий переход (пост-фильтр) не примет сообщение.

Некоторые рекомендуют noatime варианты крепления катушки postfix. Это потенциально неразумно, поскольку постфикс зависит от семантики файловой системы. См. Например http://archives.neohapsis.com/archives/postfix/2006-01/1916.html.

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

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

Мне кажется, что это проблема производительности хранилища.

Iowait 99,88 говорит вам, что ваша система тратит много времени на ожидание вашего хранилища.

Я согласен с Биллом Вайсом. Вам следует изучить настройку raid10 для очереди.

или начать с

vmstat 1

"iostat 1", предложенный мошеном, тоже хорош

Судя по вашей статистике, было бы неплохо, если бы более быстрая дисковая подсистема. raid-10 на 6-8 дисках 15к об / мин, возможно, с небольшим количеством кеша, парой гигабайт встроенной памяти.

смонтируйте каталог спула с параметрами noatime, nodiratime. подумайте о настройке или изменении вашей файловой системы для работы с большим количеством небольших [я полагаю] файлов.

Брайан

Вам действительно нужно получить более быстрый диск или, желательно, перейти на решение рейда. Что это за сервер?

Джеймс

Если вы используете amavis для фильтрации спама и вирусов, вам следует увеличить количество параллельных процессов amavis. В соответствии с вашими настройками вам может потребоваться увеличить как количество процессов smtp-amavis из postfix master.cf, так и соответствующий параметр в amavis.conf.

Сколько ядер в коробке и какова реальная нагрузка? Какова реальная скорость отправки сообщений?

Как и большинство, моя первая мысль - это диск, так что проверьте это.

Однако причиной может быть загрузка сети, а также высокая нагрузка прерываниями (плохая карта?), Поэтому проверьте их. Я обнаружил, что даже для скромного почтового сервера наличие быстрого кэширующего DNS-сервера (я неравнодушен к «несвязанному») на том же самом ящике помогает уменьшить задержку и нагрузку на сеть.

если вы выполняете 630 операций чтения и 1042 записи в секунду, я определенно предлагаю увеличить объем вашей памяти в системе (чтобы лучше справляться с ОС и RAM-диском), а затем сделать вашу папку postfix RAM-диском.

Также предложил бы разместить ваши почтовые журналы на отдельном разделе, если не на собственном диске.

Это не проблема ввода-вывода, это проблема конфигурации постфикса. Вы просите его сделать слишком много сразу и создаете себе узкое место. Проверьте настройка производительности постфикса readme и / или разместите свой main.cf, чтобы мы могли помочь.

Похоже, у вас хитрый диск. Ваш сервер выполняет только 72 запроса на чтение в секунду и 42 записи в секунду. Мой настольный жесткий диск seagate 7200 об / мин может выполнять более 100 случайных запросов чтения / записи в секунду и при этом справляться с этим.

Попробуйте установить катушку на sda и посмотрите, улучшится ли нагрузка.

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

  1. Запустите qshape active, qshape deferred и qshape incoming и сообщите нам общий итог каждой команды.

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

  2. Убедитесь, что ваш почтовый сервер не занесен в черный список (http://www.mxtoolbox.com/blacklists.aspx )

  3. Проверьте время ответа DNS и запустите локальный кеш DNS.

    Почтовый сервер довольно активно использует DNS. Делать dig somedomain.com mx Запустите его на нескольких разных хостах. Обычно время отклика должно быть меньше 100 - 400 мс. Если вы получите более высокий отклик, ваш DNS может работать некорректно. Попробуйте другой DNS (вы можете попробовать Google 8.8.8.8 или OpenDNS: 208.67.222.222)

  4. Проверьте свою сеть. (например, ifconfig) и посмотрите, сколько пакетов ошибок. Проверьте, насыщена ли ваша ссылка или имеет форму. Проверьте, не было ли большого количества операций тайм-аута в почтовых журналах. Выполните tcpdump и убедитесь, что пакеты не теряются и не передаются повторно.

  5. Можете ли вы сказать нам, реагирует ли консоль (например, когда вы вводите какую-либо команду, насколько быстро система дает вам обратную связь)?

    Обычно проблема с сетью (например, DNS) приводит к резкому увеличению нагрузки, но система по-прежнему реагирует.