Оптимизация postfix для рассылки 100к писем в сутки

[bagas]

Добрый день.
Подскажи как лучше оптимизировать postfix для рассылки примерно 100k писем в сутки?
Это не спам, это данные по авторизации.
система debian 7
Сеть две гигабитные карты intel.
Памяти 64Гиг.
Процессор Е5 xeon - 12 ядер.
Конфиг postfix.

Код: Выделить всё

myhostname = mx.chat.net
inet_interfaces = all
mydestination = $myhostname, localhost.$mydomain $mydomain
relayhost =
mynetworks = 192.168.1.0/24, 127.0.0.0/8
home_mailbox = .maildir/
anvil_rate_time_unit = 60s
smtpd_client_message_rate_limit = 0
smtpd_client_recipient_rate_limit = 0
smtpd_client_connection_rate_limit = 100
minimal_backoff_time=30m
queue_run_delay=
maximal_backoff_time=2m
maximal_queue_lifetime=0
milter_default_action = accept
milter_protocol = 2
smtpd_milters = inet:localhost:8891
non_smtpd_milters = inet:localhost:8891

[Хостинг HostFood.ru]

Тарифы на хостинг в России, от 12 рублей: https://www.host-food.ru/tariffs/hosting/
Тарифы на виртуальные сервера (VPS/VDS/KVM) в РФ, от 189 руб.: https://www.host-food.ru/tariffs/virtualny-server-vps/
Выделенные сервера, Россия, Москва, от 2000 рублей (HP Proliant G5, Intel Xeon E5430 (2.66GHz, Quad-Core, 12Mb), 8Gb RAM, 2x300Gb SAS HDD, P400i, 512Mb, BBU):
https://www.host-food.ru/tariffs/vydelennyi-server-ds/
Недорогие домены в популярных зонах: https://www.host-food.ru/domains/

[vadim64]

а сейчас он не справляется? какие ресурсы проседают?

[bagas]

Еще не запускали в шатном режиме.
Пока настраиваю.

[moury]

Сам постфикс оптимизации не требует. Считается, что он разработан как раз под крупные почтовые системы.

Торможение может быть при работе с БД, поэтому надо оптимизировать саму СУБД, а в постфиксе - взаимодействие с ней, и обязательно соединения с БД проксировать. Тут я мало что помню.

Если используете acl на основе БД, при больших трафике и спаме будет не хватать сокетов для соединения с БД. так что советую: увеличить количество сокетов в настройках СУБД; статические acl на основе БД не делать (только cdb или hash).
В документации утверждается, что cdb быстрее hash.

Диск узким звеном не будет, однако обязательно контролировать состояние диска (массива) - если соединение с БД - через файловые сокеты, сбойный участок может очень эффектно затормозить работу почтовой системы.

[bagas]

Сам постфикс оптимизации не требует. Считается, что он разработан как раз под крупные почтовые системы.

Торможение может быть при работе с БД, поэтому надо оптимизировать саму СУБД, а в постфиксе - взаимодействие с ней, и обязательно соединения с БД проксировать. Тут я мало что помню.

Если используете acl на основе БД, при больших трафике и спаме будет не хватать сокетов для соединения с БД. так что советую: увеличить количество сокетов в настройках СУБД; статические acl на основе БД не делать (только cdb или hash).
В документации утверждается, что cdb быстрее hash.

Диск узким звеном не будет, однако обязательно контролировать состояние диска (массива) - если соединение с БД - через файловые сокеты, сбойный участок может очень эффектно затормозить работу почтовой системы.

Спасибо за совет.
Сервер настроен как релей.
сам постфикс в бд ничего не хранит.
Диск ssd да и оперативки вроде не мало.

[bagas]

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

[FiL]

Добрый день.
Подскажи как лучше оптимизировать postfix для рассылки примерно 100k писем в сутки?

100K в сутки - это 70 писем в минуту. Копейки.
Вот только у вас smtpd_client_connection_rate_limit стоит 100 на 60 секунд. И это на релее. Что-то сильно близко к среднему значению, которое надо достичь (70). То есть любые всплески будут упираться в этот лимит и создавать затыки. Не уверен, что это хорошая идея.

[bagas]

А какой параметр рекомендуешь?
smtpd_client_connection_rate_limit - как я понял это количество соединение с одного ип адреса.
Релей принимает толкьо от одной машины письмы.

[FiL]

если релей принимает письма только от одной машины, то зачем вообще rate ограничивать?

[bagas]

Логично!

[moury]

bagas, Вы писали, что почтовик будет рассылать данные по авторизации. Какой? Контрольные письма после регистрации на сайтах?

Если да - Вы попали. Боты начнут регистрацию аккаунтов с несуществующими адресами, и Вы утонете отлупах и их обработке. Особенно если администратор сайта использует бесплатный адрес e-mail.
Сама почтовая система-ретранслятор должна быть настроена примерно по такой схеме: http://moury.ru/spora/admin/mailadmin_req.html , плюс крайне желательно право давать по башке обслуживающему сайт персоналу.

[FiL]

moury,
не надо так нервничать. Контрольные письма можно рассылать с адреса noreply@microsoft.com и пускай в отлупах тонет кто-то другой

[moury]

FiL, во-первых, "отлупы" придется рассылать ретранслятору (он и потонет); во-вторых, такие действия чреваты. Подделка технической информации - то,чем занимаются спамеры.

Если на мою систему пойдут письма от форума с явно чужими обратными адресами, внесу ретранслятор в локальный "черный список". Серьезные же конторы внесут ретранслятор в публичные DNSBL - и не отмоешься.

А для админа ретранслятора такая подделка - основание административно дать по башке админу сайта.
И начальство присоединится: подделка адреса - угроза бизнесу на сайте.

[bagas]

bagas, Вы писали, что почтовик будет рассылать данные по авторизации. Какой? Контрольные письма после регистрации на сайтах?

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

[FiL]

FiL, во-первых, "отлупы" придется рассылать ретранслятору (он и потонет); во-вторых, такие действия чреваты. Подделка технической информации - то,чем занимаются спамеры.

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

А если серьезнее, то я не очень понимаю чем таким страшным грозят отлупы. Ну получает сервер 550 User unknown, ну генерит письмо отправителю. Которое или сразу в /dev/null складывается (у меня так) или кладется в локальный ящик. Никакой особой дополнительной нагрузки это не дает.
Несколько хуже вариант, когда удаленный сервер почту сначала принимает, а уж потом генерит отлуп. Тогда надо сначала доставить почту, а потом отлуп надо принять как новое письмо. То есть по сути нагрузка удваивается. Так это легко решается разносом исходящего и принимающего релеев на разные сервера. Вот только смысла это имеет на совсем других нагрузках. У меня во время спам-аттак сервер (Pentium-4, 2Gb ram, сеть сотка) без напряга перемалывал по 250 писем в минуту (360К в сутки) и даже не замечал нагрузки. А уж описываемый сервак перемелет пару миллионов писем лениво пошевеливая одним ядром из 12.

[moury]

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

Да просто я на эту тему никогда не шучу. Вы наступили на любимую мозоль

Кроме того, форум посещают не только здравомыслящие люди. Некоторые примут Вашу шутку как руководство к действию.

А если серьезнее, то я не очень понимаю чем таким страшным грозят отлупы. Ну получает сервер 550 User unknown, ну генерит письмо отправителю. Которое или сразу в /dev/null складывается (у меня так) или кладется в локальный ящик. Никакой особой дополнительной нагрузки это не дает.

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

Если доставлять почту в /dev/null, как у Вас, распухания очереди не будет, но можно пропустить важное письмо (например. уведомление от скрипта CMS о сбое) или не заметить, что характер окучивания ботами сайта изменился.

То есть, почту, адресованную отправителю (www-data@www.domain.ru ) надо доставлять веб-мастеру. Но я столько раз видел. как веб-мастера вели себя не лучше обычных юзеров! Они не читали свою почту, потому что просто не хотели видеть эти уведомления! Ящик веб-мастера переполнялся. становилось весело.

Проблема - невелика (для Вас уже - не проблема), только о ней надо подумать заранее. Вот и все.

[moury]

bagas, Вы писали, что почтовик будет рассылать данные по авторизации. Какой? Контрольные письма после регистрации на сайтах?

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

НЯМС, в таком случае оптимизация вообще не требуется.

[FiL]

Если доставлять почту в /dev/null, как у Вас, распухания очереди не будет, но можно пропустить важное письмо (например. уведомление от скрипта CMS о сбое) или не заметить, что характер окучивания ботами сайта изменился.

Рассылка информационных сообщений от форума совершенно не должна идти с того-же адреса, куда пишут важные письма, например, уведомления от скриптов.
Дерьмо рассылается с noreply@domain и этот ящик привязан к /dev/null, а письма админу идут на webmaster@domain или admin@domain или еще какие там прописаны адреса в настройках - те должны доставляться живым людям. С надеждой на то, что они их читать будут.

Проблема - невелика (для Вас уже - не проблема), только о ней надо подумать заранее. Вот и все.

Собственно, об том и речь, что проблемы с рассылкой 100К писем в принципе нет. Ничего особо твикать не нужно. На таких объемах все достаточно хорошо работает 'искаропки'.