forum.lissyara.su

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Логично!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

bagas писал(а):

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

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

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

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

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

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

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