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

Это может звучать немного сумасшедшим, но Вы должны:

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

Выполненный постфикс при некотором профилировщике (gprof?), или взгляд в журналах. Постфикс регистрирует большую информацию синхронизации, которая могла бы сказать Вам, где держание. Общие места для взгляда:

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

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

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

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

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

или подобный.

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

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

Похож на горлышко бутылки производительности хранилища мне.

iowait 99,88 говорит Вам, что Ваша система проводит много времени, ожидая на Вашем устройстве хранения данных.

Я соглашаюсь с Bill Weiss. Необходимо изучить установку raid10 для очереди.

или запустите с

vmstat 1

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

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

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

Brian

Действительно необходимо получить более быстрый диск или предпочтительно переместиться в решение для набега. Какой сервер - это?

James

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

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

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

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

с Вами делающий 630 чтений и 1 042 записи в секунду, я определенно предлагаю увеличить Вашу память в системе (чтобы лучше обработать ОС и электронный диск) и затем делать Вашу постфиксную папку электронным диском.

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

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

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

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

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

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

похож у Вас есть изворотливый диск. Ваш сервер, только делающий 72 запроса/секунда чтения и 42 записи/секунда. Моя Seagate настольный жесткий диск на 7 200 об/мин может сделать 100 + случайный запрос чтения-записи в секунду и все еще справиться с ним.

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

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

1. Выполненный qshape активный, qshape задержанный, и поступление qshape и сообщают нам общее количество каждой команды.

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

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

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

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

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

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

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