Продуктивність Postfix

Запуск постфікса на ubuntu, щодня надсилаючи багато пошти (~ 1 мільйон повідомлень). навантаження надзвичайно великі, але не дуже з точки зору завантаження процесора та пам'яті. Хтось у подібній ситуації і знає, як усунути вузьке місце?

Вся пошта на цьому сервері є вихідною.

Я б припустив, що вузьким місцем є диск.

Просто оновлення, ось як виглядає іостат:

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 присвячений постфіксу.

Я думаю, це перетасування черги, від вхідного-> активного-> відкладеного

Детальніше з питань:

Сервер: чотирьохядерний процесор Xeon (R) E5405 @ 2,00GH з 4 ГБ таран

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

Екземпляри Postfix між 16 - 32

Це може здатися трохи божевільним, але вам слід:

1. Вимкніть ведення журналу до необхідного мінімуму. Зробіть тільки syslog журналом 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 Кб RPM обробляє 150 IOPS. Я б почав з 5-ти дискових SCSI-дисків 15k RPM та гідного RAID-контролера. Налаштуйте його як RAID-10 на 4 дисках з 1 гарячою запасною. Я не впевнений, що це повністю вирішить вашу проблему, але це однозначно не погіршить її.

Запустіть постфікс під деяким профілером (gprof?) Або подивіться в журнали. Postfix записує багато інформації про час, яка може підказати вам, де знаходиться затримка. Загальні місця для перегляду:

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

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

Ваша ситуація, безумовно, схожа на сервер, пов'язаний з входом / виводом Цього можна очікувати з MTA, який повинен робити багато невеликих записів, щоб гарантувати, що він не втратить пошту.

Знайдіть час для налаштування вводу-виводу на і /var/spool/postfixта /var/log. Найкраща практика для зайнятих серверів Postfix - це розділення обох між різними шпинделями та переконання, що асинхронний журнал включений. префікс імені журналу для вашого журналу пошти з тире в 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 .

Це, безумовно, схоже на те, що вашу дискову підсистему слід принаймні розглядати як частину проблеми. Через те, як постфікс переміщує файли навколо / var, я б запропонував googling для "налаштування файлової системи ext3" (принаймні, встановлення режиму часу та зворотного запису), щоб побачити, чи не можете ви підвищити продуктивність на рівні файлової системи.

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

Схоже, горловина для пляшок для зберігання.

Iowait 99,88 говорить про те, що ваша система витрачає багато часу на очікування вашого сховища.

Я згоден з Біллом Вайсом. Ви повинні вивчити налаштування raid10 для черги.

або почати з

vmstat 1

"Іостат 1", запропонований Мошен, також хороший

з вашої статистики явно було б швидше дискову підсистему. raid-10 на 6-8 15k об / хв диски, можливо, з деяким кешем, парою гігів пам'яті на борту.

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

Брайан

Вам дійсно потрібно отримати більш швидкий диск, або бажано перейти до рейдового рішення. Що це за сервер?

Джеймс

Якщо ви використовуєте amavis для фільтрації по спаму + вірусу, вам слід збільшити кількість паралельних процесів Amavis. Відповідно до вашої установки, можливо, вам доведеться збільшити кількість процесів smtp-amavis з postfix master.cf, а також відповідні налаштування в amavis.conf.

Скільки ядер у коробці, і яке фактичне навантаження? Яка фактична швидкість надсилання повідомлень?

Як і більшість, моя перша думка - диск, тому перевірте це.

Однак причиною цього може бути використання мережі, оскільки це може бути велике завантаження перерв (погана карта?), Тому перевірте це. Я виявив, що навіть для скромного поштового сервера швидке кешування DNS-сервера (я частковий до "незв’язаного") у тому самому полі допомагає зменшити затримку та завантаження мережі.

якщо ви робите 630 зчитування та 1042 запису в секунду, я, безумовно, пропоную збільшити вашу пам'ять у системі (щоб краще обробляти ОС та оперативний диск), а потім зробити свою папку Postfix ramdisk.

Також рекомендуємо розміщувати свої журнали пошти на власному розділі, якщо не власний диск повністю.

Це не проблема IO, це проблема конфігурації postfix. Ви просите це зробити занадто багато всього і створити вузьке місце для себе. Ознайомтеся з налагодженням функції readme та / або опублікуйте ваш main.cf, щоб ми могли допомогти.

схоже на те, що у вас є дивний диск. Ваш сервер виконує лише 72 запиту читання / сек і 42 запису / секунду. Мій накопичувач 7200 RPM на робочому диску Seagate 7200 RPM може робити 100+ випадкових запитів читання / запису в секунду і все ж справлятися з цим.

Спробуйте встановити котушку на sda і побачити, чи навантаження покращиться.

Але перед тим, як сплатити більше грошей на диск, зробіть наступне:

1. Запустіть qshape активний, qshape відкладений і qshape вхідний і повідомте нам про загальну кількість кожної команди.

   Незвичайно велика кількість пошти у відкладеній черзі означає, що ваш поштовий сервер може використовувати спамер для передачі своєї спаму (наприклад, відправлення електронної пошти на неіснуючий домен, що призведе до того, що ваш поштовий індекс повторюватиметься знову і знову).

2. Переконайтеся, що ваш поштовий сервер не перебуває у чорному списку ( http://www.mxtoolbox.com/blacklists.aspx )

3. Перевірте час відповіді DNS та запустіть локальний кеш DNS.

   Поштовий сервер досить широко використовує DNS. Do dig somedomain.com mx Run це через кілька різних хостів. Як правило, час реакції має бути менше 100 - 400 мс. Якщо ви отримаєте більш високу відповідь, ваш DNS може не працювати належним чином. Спробуйте різні DNS (ви можете спробувати google's 8.8.8.8 або OpenDNS: 208.67.222.222)

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

5. Чи можете ви сказати нам, чи відповідає консоль (наприклад, коли ви набираєте якусь команду, як швидко система дає вам зворотній зв'язок)?

   Як правило, проблема з мережею (наприклад, DNS) призведе до зростання навантаження, але система все ще реагує.