кто-то тестировал sendmail/postfix/exim под нагрузкой?
Dmitry A. Yanko
Меня в принципе sendmail бы устроил, но поглядываю в сторону exim.
Стоит ли?
--
#include <regards.h>, fm.
GnuPG fpr = 9150 ED37 F6E4 9707 1D35 695F B7F9 02CE F401 C208
Mail message with GPG-KEY in subject to get my public key
Alexander Kolesnikoff
> Что посоветуете для большого трафика в режиме relay-only(в основном)?
> Меня в принципе sendmail бы устроил, но поглядываю в сторону exim.
> Стоит ли?
>
Alexander
Valentin Nechayev
DAY> Что посоветуете для большого трафика в режиме relay-only(в основном)?
DAY> Меня в принципе sendmail бы устроил, но поглядываю в сторону exim.
DAY> Стоит ли?
Следует определиться с:
1. Уровнем предполагаемой автопилотности тачки и оперативностью мер по
остановке ухода системы вразнос.
В случае sendmail нормальную автопилотность можно обеспечить для такого
профиля работы только спецмерами. Я бы даже рекомендовал свой sendmail
(ftp://segfault.kiev.ua/pub/sendmail/), там есть несколько заточек на
стабилизацию нагрузки (в первую очередь - ограничение количества фоновых
доставщиков), можно взять все вместе или выдрать патч.
Exim имеет примерно аналогичные проблемы, но там демпфера более разумные,
как правило до позы зю машина не доходит.
Postfix не имеет проблем из-за централизованного ограничения.
Smail, zmailer - я не в курсе.
2. Типом релея: исходящий в мир с широкой раздачей (эмиттер), входящий MXер,
другое. Для эмиттера, который не последний в цепочке fallback'ов, оптимум -
postfix. Если последний - скорее sendmail, у него ряд алгоритмов умнее
(в частности, переход на следущий MXер, если предыдущий сказал "мне тут
чегой-то плохо). Для входящего MXера разницы практически нет, разве что
если накапливаются тысячи писем - sendmail хуже держит нагрузку, чем
большинство остальных.
3. Нужностью DSN.
Postfix, qmail не умеют DSN. Остальные вроде умеют.
В принципе оно нужно ~1% пользователям или даже меньше.
4. Нужностью ручных операций над группами писем и одиночными письмами.
Проще всего это в sendmail, есть правильные подпорки. Нереально без остановки
всего демона - для postfix. Также нереально в qmail. Про остальные не в курсе.
5. Типом и свойствами применяемых фильтров.
Sendmail лучше всего для milter; postfix хорошо умеет транзитные фильтры
pipe-типа. Exim - пайпы и внутренние фильтры на его языке.
Выставить веса признакам. Попытаться просуммировать.
/netch
Andrew Filonov
>>>> основном)? Меня в принципе sendmail бы устроил, но поглядываю в
>>>> сторону exim. Стоит ли?
AK> Если нужна скорость - ставь postfix, однозначно.
А кроме скорости, больше ничего не нужно? Ни вирусы чекать, ни особо
наглых спамеров отсевать, ни резервировать мощности для своих хостов,
ни даже проверять наличие юзера в релеемом домене? Я тоже так хачу!
>> А чего такая вот однозначность ? Чесспионерское интересно.
>> Примеры что там freebsd.org под постфиксом не канают, бенчмарки и
>> выкладки в студию.
>>
AK> Давно это было. Я сравнивал exim, CGP и postfix. Конкретные
AK> цифры сейчас просто не помню. Но то что exim проиграл по всем
AK> статьям - это точно, а безус- ловный лидер - CGP.
Эт пофиг. Сколько в России мылопотоков, которые хоть один из них не
сможет прожевать?
AK> Как настроить exim, чтобы он всю почту слал на 127.0.0.1:9001 ?
AK> Повторю тесты для шибко сомневющихся. ;-)
manualroute + пара параметров для smtp-транспорта.
--
Andrew E. Filonov
If reproducibility may be a problem conduct the
test only once.
Alexander Kolesnikoff
> Alexander Kolesnikoff wrote:
> AK> Ты уж определись для начала чего ты хочешь, лимитировать
> AK> "per-host" или "резервировать для группы хостов". И кстати
> AK> говоря зарезервировать энное количество коннектов для опре-
> AK> делённой группы хостов тоже не проблема.
>
> Саша, не кипятись. exim как универсальный шаровой МТА -
> просто вне конкуренции.
Да я разве против ? :-)
> А по тому, как к нему прикручиваются контент чекеры вообще супер. Возможно,
> что postfix/cgp/sendmail умеют то же самое.
А что конкретно супер ? Давай вместе посмотрим чего не хватает
постфиксу и что уже есть в экзиме.
> Только вот сендмыл сразу спугнул
> меня на первых порах и пошел я искать простого пути сначала с постфиксом,
> а потом уже и с exim'ом. В итоге разобрался я _досконально_ только
> с exim'ом.
> И скажу честно - очень им доволен.
Ну что ж, это очень хорошо.
> Скажу еще по секрету, чтобы не изобретать
> велосипед, я просто подсмотрел на чем сидит mail.ru и поставил то же самое.
> Так что надо сначала разобраться в common tasks при работе/мейтненсе МТА,
> а потом уже плясать дальше в выборе. Скажу сразу, я еще не смог придумать
> себе такого изврата, который не смог бы реализовать на exim'е.
> Вопрос скорости поднимали, хммм... Скорость ЧЕГО ?
Принятия/отправки писем. Я ж спрашивал что написать в конфиг
экзиму, чтобы он всю почту релеил на 127.0.0.1:9001, для тестов.
Так толком никто и не ответил. А разбираться с экзимом - мне пока
некогда. Если скажешь как сконфигурить экзим - будут тебе бенчмарки.
Когда заходит речь о массовых рассылках я бы всем советовал ис-
пользовать именно постфикс а не экзим. Именно потому, что постфикс
быстрее это делает чем экзим. Посмотри чем рассылают почту
security.focus, ( а ведь там крутится ещё и qmail ), или amazon.com.
Если кто скажет что таких почтовых потоков на всём пространстве СНГ
не бывает - не верь. Дату не назову точно, но как-то обратился в
postfix.users наш товарищ, из России, с просьбой настроить почтовик
на рассылку миллиона писем, причём разных, с максимальной скоростью.
И ведь всё у него было: и машина с рэйдом, пень какой-то с гигагерцами,
памяти больше гига, канал наружу свободный 2Мбита. А выбор он свой
остановил на ... qmail, добившись итоговой производительности 12 msg/sec.
С постфиксом он получил 8 msg/sec. :-) Это так к слову.
Мне если честно, в постфиксе нравится стройность и логичность его
архитектуры и конечно же надёжнось. Да и код, можно сказать, образцовый.
В общем на вкус, на цвет...
Alexander
Ivan Fedorov
Четверг Hоябрь 21 2002 года (а было тогда 15:51)
Andrew Filonov в своем письме к Artem Chuprina писал:
AC>> отсеивать, то тоже postfix. Хотя и за счет потери скорости (как и
AC>> при проверке на вирусы), зато фильтровалка прямо в комплекте.
AF>> Она у всех в комплекте.
AC>> Угу, то-то к сендмейлу надо чего-то прикручивать, чтобы по
AC>> хедерам по регулярным выражениям отстреливать...
AF> А сендмейл тут разве кто-то упоминал?
Hу ты хоть субж посмотри ;)
С уважением, Ivan Четверг Hоябрь 21 2002 года
... XMMS play: Rammstein - Du Riechst So Gut
Ilia Kuliev
21 Nov 02, Valentin Nechayev wrote:
VN> P.S. Hу-ка, твои предложения по политике доставки, когда очередь в 20
VN> тысяч писем и из них 16 тысяч надо просто убрать куда-то вбок, чтобы
VN> остальным дать разбежаться. А потом думать, что с этими 16 тысячами
VN> делать. Что ты будешь делать - заморозишь эти 16 тысяч и оставишь их
VN> болтаться?
Давно хотел спросить: а что, сбалансировать нагрузку так, чтобы эти 20
тысяч писем никогда не накопились на единственном сервере, почему-то
нельзя?
ilia
Valentin Nechayev
VN>> P.S. Hу-ка, твои предложения по политике доставки, когда очередь в 20
VN>> тысяч писем и из них 16 тысяч надо просто убрать куда-то вбок, чтобы
VN>> остальным дать разбежаться. А потом думать, что с этими 16 тысячами
VN>> делать. Что ты будешь делать - заморозишь эти 16 тысяч и оставишь их
VN>> болтаться?
IK> Давно хотел спросить: а что, сбалансировать нагрузку так, чтобы эти 20
IK> тысяч писем никогда не накопились на единственном сервере, почему-то
IK> нельзя?
Нельзя.
Длинная очередь означает, что нагрузка _уже_ сбалансирована. Потому что
почтовая нагрузка крайне неравномерно зависит от времени суток, дня
недели и пр., и размещение в очереди ждущих - уже есть средство балансировки.
Не идет речь о случае, когда очередь в тысячи писем является постоянной -
если бы это было так, то надо было бы добавлять мощностей, ставить MTA
ведущие в памяти базу состояния очереди (это даже не postfix и не exim,
а уже ближе к CGPro); речь о ситуации нештатного всплеска, который регулируется
средствами самого MTA за счет размещения очереди на диске и увеличении
интервала до попытки доставки.
Закрывать прием при превышении длины очереди не практикуется - если разброс
нагрузки уже сделан иными средствами, то это легко автоматизировать внешними
средствами, а если не сделан - то в среднем лучше принять, чем не принять.
/netch
Valentin Nechayev
AC>>> А какой это сендмейл умеет регексовые мапы?
VN>> Любой из современных. Даже 8.9 умеет.
AC> Тогда второй вопрос: а в каком месте документации это можно увидеть? Я могу
AC> поверить, что отстал от жизни, но сендмейловская документация написана, прямо
AC> скажем, слабо пригодным для поиска образом. Постфиксовая, впрочем, немногим
AC> лучше...
В конце op.me есть оглавление.
Пункт key file declaration (название идиотское, конечно). Среди прочих
есть тип regex, который дает проверку на соответствие некоторому выражению.
Пример -
Kregaa regex -a@@ ^aa
LOCAL_RULE_0
R$*<$=w.> $: $1<$2.> $| $(regaa $1 $: x $)
R$*$|@@ $#error $@nafig $:nafig
- отсекает почту на все локальные ящики вида aa*
/netch
Valentin Nechayev
VN>> P.S. Ну-ка, твои предложения по политике доставки, когда очередь
VN>> в 20 тысяч писем и из них 16 тысяч надо просто убрать куда-то
VN>> вбок, чтобы остальным дать разбежаться. А потом думать, что с
VN>> этими 16 тысячами делать.
AF> Настроить Retry rules/queue_*/hold_domains.
Тогда еще увеличь количество писем.;)
Я собственно о чем: перечитывание очереди, даже со всякими hold_domains,
retry_rules - работа, и немалая. С какого-то момента и она начинает грузить
так, что мешает остальному. Да, в sendmail'е это раньше. Я помню еще случай
с ~6000 писем исходящих с mailnews застрявших в очереди на машине уровня
2xPPro-180: разгребальщики читали очередь и отказывались работать из-за
нагрузки, созданной другими такими же разгребальщиками;) - помогло
sendmail -q -v -ox99. Можно оптимизировать, как в postfix'е, когда на файлы
очереди ставится дата наперед. Можно еще как-то делать. Но все равно чтение
очереди займет ресурсы, и немаленькие. Так почему не выселить просто в другое
место, если админ все равно пришел заниматься ручным контролем ситуации?
VN>> Что ты будешь делать - заморозишь эти 16 тысяч и оставишь их
VN>> болтаться?
AF> Тоже вариант, при настроенном auto_thaw.
AF> Или без настроенного - скормить batch
AF> grep ' frozen by root' mainlog |cut -f 3 -d \ | xargs exim -Mt
Ну и нафига их тут размораживать?
-netch-
Andrew Filonov
VN> P.S. Ну-ка, твои предложения по политике доставки, когда очередь
VN> в 20 тысяч писем и из них 16 тысяч надо просто убрать куда-то
VN> вбок, чтобы остальным дать разбежаться. А потом думать, что с
VN> этими 16 тысячами делать.
AF> Настроить Retry rules/queue_*/hold_domains.
VN> Тогда еще увеличь количество писем.;)
Где я их тебе возьму? :-) А количество серверов увеличить при этом
никак? :-)
VN> Я собственно о чем: перечитывание очереди, даже со всякими
VN> hold_domains, retry_rules - работа, и немалая. С какого-то
VN> момента и она начинает грузить так, что мешает остальному.
Так выкини это <censored> sendmail. База retry в exim'е - BerkeleyDB
HASH, и надо ОЧЕНЬ много писем, чтобы проверка retry стала жрать
существенные ресурсы. толпы queue runner'ов там нафиг не нужны
VN> Что ты будешь делать - заморозишь эти 16 тысяч и оставишь их
VN> болтаться?
AF> Тоже вариант, при настроенном auto_thaw. Или без настроенного -
AF> скормить batch grep ' frozen by root' mainlog |cut -f 3 -d \ |
AF> xargs exim -Mt
VN> Ну и нафига их тут размораживать?
Ну доставлять-то их надо, а по условиям задачи других серверов нет
--
Andrew E. Filonov
Virtue is its own punishment.
Valentin Nechayev
VN>> P.S. Ну-ка, твои предложения по политике доставки, когда очередь
VN>> в 20 тысяч писем и из них 16 тысяч надо просто убрать куда-то
VN>> вбок, чтобы остальным дать разбежаться. А потом думать, что с
VN>> этими 16 тысячами делать.
AF>> Настроить Retry rules/queue_*/hold_domains.
VN>> Тогда еще увеличь количество писем.;)
AF> Где я их тебе возьму? :-) А количество серверов увеличить при этом
AF> никак? :-)
Зачем? Это ведь временный поток, а не постоянный.
Просто пришла лавина.;)
VN>> Я собственно о чем: перечитывание очереди, даже со всякими
VN>> hold_domains, retry_rules - работа, и немалая. С какого-то
VN>> момента и она начинает грузить так, что мешает остальному.
AF> Так выкини это <censored> sendmail. База retry в exim'е - BerkeleyDB
AF> HASH,
Ой как интересно. А если я новые письма переложу - оно их подхватит?
А если заберу - оно выкосит из базы?
VN>> Что ты будешь делать - заморозишь эти 16 тысяч и оставишь их
VN>> болтаться?
AF>> Тоже вариант, при настроенном auto_thaw. Или без настроенного -
AF>> скормить batch grep ' frozen by root' mainlog |cut -f 3 -d \ |
AF>> xargs exim -Mt
VN>> Ну и нафига их тут размораживать?
AF> Ну доставлять-то их надо, а по условиям задачи других серверов нет
Ну это и так понятно.
-netch-
Andrew Filonov
VN> P.S. Ну-ка, твои предложения по политике доставки, когда очередь
VN> в 20 тысяч писем и из них 16 тысяч надо просто убрать куда-то
VN> вбок, чтобы остальным дать разбежаться. А потом думать, что с
VN> этими 16 тысячами делать.
AF> Настроить Retry rules/queue_*/hold_domains.
VN> Тогда еще увеличь количество писем.;)
AF> Где я их тебе возьму? :-) А количество серверов увеличить при
AF> этом никак? :-)
VN> Зачем? Это ведь временный поток, а не постоянный. Просто пришла
VN> лавина.;)
А все каналы на отправку при этом дружно лежали? :-)
VN> Я собственно о чем: перечитывание очереди, даже со всякими
VN> hold_domains, retry_rules - работа, и немалая. С какого-то
VN> момента и она начинает грузить так, что мешает остальному.
AF> Так выкини это <censored> sendmail. База retry в exim'е -
AF> BerkeleyDB HASH,
VN> Ой как интересно.
VN> А если я новые письма переложу - оно их подхватит?
Не знаю - не пробовал.
VN> А если заберу - оно выкосит из базы?
Да. Но почему-то у меня нехорошие ощущения, что ты путаешь базу retry
и очередь.
--
Andrew E. Filonov
People can be divided into three groups:
Those who make things happen,
Those who watch things happen and
Those who wonder what happened.
Igor Karpov
Alexander Kolesnikoff <a...@hvv.uku.com.ru> wrote:
> Vladimi...@ukr.net wrote:
>> Вопрос скорости поднимали, хммм... Скорость ЧЕГО ?
>
> Принятия/отправки писем. Я ж спрашивал что написать в конфиг
> экзиму, чтобы он всю почту релеил на 127.0.0.1:9001, для тестов.
> Так толком никто и не ответил. А разбираться с экзимом - мне пока
> некогда. Если скажешь как сконфигурить экзим - будут тебе бенчмарки.
> Когда заходит речь о массовых рассылках я бы всем советовал ис-
> пользовать именно постфикс а не экзим. Именно потому, что постфикс
> быстрее это делает чем экзим. Посмотри чем рассылают почту
> security.focus, ( а ведь там крутится ещё и qmail ), или amazon.com.
> Если кто скажет что таких почтовых потоков на всём пространстве СНГ
> не бывает - не верь. Дату не назову точно, но как-то обратился в
> postfix.users наш товарищ, из России, с просьбой настроить почтовик
> на рассылку миллиона писем, причём разных, с максимальной скоростью.
> И ведь всё у него было: и машина с рэйдом, пень какой-то с гигагерцами,
> памяти больше гига, канал наружу свободный 2Мбита. А выбор он свой
> остановил на ... qmail, добившись итоговой производительности 12 msg/sec.
> С постфиксом он получил 8 msg/sec. :-) Это так к слову.
> Мне если честно, в постфиксе нравится стройность и логичность его
> архитектуры и конечно же надёжнось. Да и код, можно сказать, образцовый.
> В общем на вкус, на цвет...
Благо, сегодня видел и недалеко искать. Из Exim FAQ, раздел Performance:
Q1002: How well does Exim scale? A1002: Although the author did not
specifically set out to write a high- performance MTA, Exim does seem to
be fairly efficient. The biggest server at the University of Cambridge
(a large Sun box) goes over 100,000 deliveries per day on busy days (it
has over 20,000 users). There was a report of a mailing list exploder
that sometimes handles over 100,000 deliveries a day on a big Linux box,
the record being 177,000 deliveries (791MB in total). Up to 13,000
deliveries an hour have been reported.
These are quotes from some Exim users:
"... Canada's largest internet provider, uses Exim on all of our mail
machines, and we're absolutely delighted with it. It brought life back
into one of our machines plagued with backlogs and high load averages.
Here's just an example of how much email our largest mail server (quad
SS1000) is seeing ... " [230,911 deliveries in a day: 4,475MB]
"... Exim has to ... do gethostbyname()s and RBL lookups on all of the
incoming mail servers, and he runs from inetd (TCP Wrappers connected).
All the same, it seems to me that he runs as fast as lightning on our
SCO 5.0.4 box (1 Pentium 166) - far faster than MMDF which I (and many
customers) had before."
"On a PII 400 with 128M of RAM running Linux 2.2.5, I have achieved
36656 messages per hour (outgoing unique messages and recipients). For
about a 5 minute period, I was able to achieve an average of 30 messages
per second (that would be 108000 m/hour)! We are using:
(options that make a difference):
queue_only
split_spool_directory
queue_run_max = 1
remote_max_parallel = 1
We have a cron job hat runs every five minutes that spawns 5 exim -q if
there are less that 120 exim processes currently running. We found that
by manually controlling the concurrency of exim -q processes contending
for the spool for remote_smtp delivery that we gained considerable
performance - 10000 m/hour."
Regards,
--
Igor A. Karpov phone: +380(44)238-0624
Unix System Administrator
I don't suffer from stress. I'm a carrier.