On Sat, 13 Mar 2004, Dmitry A.Deineka wrote:

Вопрос в следующем: при включении фильтрации в постфиксе (body_checks), как говорится, драматически падает производительность.

Фильтр - http://www.itl.ua/support/body_checks.itl Почтовый трафик - http://www.itl.ua/support/mailgraph.php

Выглядит это так: взлетают процессы cleanup, которые кушают кучу ресурсов и, соответственно, достаточно долго обрабатывают письма. Разрастается очередь, в общем, полный клинч =/

Было у меня такое дело. Полечилось перестановкой (отдельно просто) библиотеки pcre на последнюю версию. Попробуй, может и у тебя полечится так же. Судя по всему, в каких-то версиях бага была. --- With best regards, Alexander Fedorko =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message

On Sun, Mar 14, 2004 at 07:01:25AM +0200, Victor Forsyuk wrote:

On Sat, Mar 13, 2004 at 01:55:10PM +0200, Dmitry A.Deineka wrote:

...

Вопрос такой: каким образом можно обеспечить высокопроизводительную фильтрацию всяческого спама ? Может, есть смысл помимо антивируса, использовать внешний демон для контекстной фильтрации ? Если да, то какой ?

spamd (spamassassin) - тут вариантов нет. а как в этом чуде добавлять regexp'ы для фильтрации ? SpamAssassin есть вкупе с amavis-new.

=================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message

-- Dmitry A.Deineka DAD1-UANIC DD518-RIPE iTL Company, Kharkov UA phone: +380 57 7136979 http://www.itl.ua fax: +380 572 282375 =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message

Hi! On Tue, Mar 16, 2004 at 12:39 +0200, Dmitry A.Deineka wrote:

...

...

Вопрос в следующем: при включении фильтрации в постфиксе (body_checks), как говорится, драматически падает производительность.

Фильтр - http://www.itl.ua/support/body_checks.itl Почтовый трафик - http://www.itl.ua/support/mailgraph.php

Выглядит это так: взлетают процессы cleanup, которые кушают кучу ресурсов и, соответственно, достаточно долго обрабатывают письма. Разрастается очередь, в общем, полный клинч =/

Было у меня такое дело. Полечилось перестановкой (отдельно просто) библиотеки pcre на последнюю версию. Попробуй, может и у тебя полечится так же. Судя по всему, в каких-то версиях бага была. Сейчас стоит на FreeBSD 5.2.1 все из коробки:

pcre-4.5 Perl Compatible Regular Expressions library postfix-2.0.16.20031223,2 A secure alternative to widely-used Sendmail

Аналогичная фигня и на других версиях. Так что, похоже, в cleanup есть некий bottleneck по производительности.

У тебя либо много, либо сильно неоптимальные регэкспы. Там по всему списку каждая строчка проходит, от этого тормоза. В примерах рекомендуется первой строкой ставить ~^[[:alnum:]+/]{60,}\s*$~ OK что позволяет не проверять по всему списку base64. -- Victor Cheburkin VCW61, VC319-RIPE, VC1-UANIC =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message

On Tue, Mar 16, 2004 at 12:39:20PM +0200, Dmitry A.Deineka wrote:

On Sat, Mar 13, 2004 at 04:30:37PM +0200, Alexander Fedorko wrote:

...

On Sat, 13 Mar 2004, Dmitry A.Deineka wrote:

Сейчас стоит на FreeBSD 5.2.1 все из коробки:

pcre-4.5 Perl Compatible Regular Expressions library postfix-2.0.16.20031223,2 A secure alternative to widely-used Sendmail

Аналогичная фигня и на других версиях. Так что, похоже, в cleanup есть некий bottleneck по производительности. Тама сплошной bottleneck, при соответствующей нагрузке. Вобщем - там и в file i/o упираться можно сильно, и в CPU. Вобщем - экстемальная настройка постфикса состоит в следующем: а) играться с ключиками оптимизации у компилятора (и бенчмаркать попутно), если можно - обойтись без PCRE. б) не держать спул на большом разделе (более 10% от размера всего диска - хотя это более от размеров файлов зависит, и я не думаю, что у Вас поток мелких писем в 100-1000KB/s). в) найти ту нагрузку, при которой ничего не клинит - и ограничить поток до приемлеиого уровня. Пожалуй - это самый главный совет. г) а на других фрях не пробовали то же самое? д) использовать всюду btree а не hash или вообще всякие ttransport maps на sql где-то держать.

-- Best regards, Paul Arakelyan. =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message

Dmitry A.Deineka wrote:

...

а) играться с ключиками оптимизации у компилятора (и бенчмаркать попутно), если можно - обойтись без PCRE. DAD> это не причем: таз P4-2.8 HTT, 512RAM, IDE. Занимается тем, DAD> что держит постфикс и все =)

См ниже.

...

б) не держать спул на большом разделе (более 10% от размера всего диска - хотя это более от размеров файлов зависит, и я не думаю, что у Вас поток мелких писем в 100-1000KB/s). в) найти ту нагрузку, при которой ничего не клинит - и ограничить поток до приемлеиого уровня. Пожалуй - это самый главный совет. DAD> ограничением кол-ва smtpd ? =) wrong way, оно ресурсы сильно не ест.

А вот и ест. Посмотри systat 1 -v на количество tps у веника, где лежит спул. -- UKR.NET Postmaster =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message

On Tue, Mar 16, 2004 at 12:58:02PM +0200, Victor Cheburkin wrote:

У тебя либо много, либо сильно неоптимальные регэкспы. Там по всему списку каждая строчка проходит, от этого тормоза.

И каждого письма, при этом. Хотя в 99.9% случаев письмо размером в, скажем, 500kB спамом не является и его проверка - совершенно бессмысленное расходование вычислительных ресурсов.

В примерах рекомендуется первой строкой ставить

~^[[:alnum:]+/]{60,}\s*$~ OK

что позволяет не проверять по всему списку base64.

И base64-кодированный спам спокойно проходит. В отличие от спамассассина. Раз уж все равно spamd используется, лучше снять с постфикса несвойственные ему задачи. И ограничить размер писем, которые будут пропускаться через spamd. В экзиме это делается элементарно, в амависе тоже наверное возможно. =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message

On Tue, Mar 16, 2004 at 06:21:42PM +0200, Dmitry A.Deineka wrote:

On Tue, Mar 16, 2004 at 05:53:18PM +0200, Paul Arakelyan wrote:

...

Тама сплошной bottleneck, при соответствующей нагрузке. Вобщем - там и в file i/o упираться можно сильно, и в CPU. Вобщем - экстемальная настройка постфикса состоит в следующем: а) играться с ключиками оптимизации у компилятора (и бенчмаркать попутно), если можно - обойтись без PCRE. это не причем: таз P4-2.8 HTT, 512RAM, IDE. Занимается тем, что держит постфикс и все =) CPU: Intel Pentium III (930.96-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x68a Stepping = 10 Features=0x383fbff real memory = 536805376 (524224K bytes) FreeBSD/SMP: Multiprocessor motherboard: 2 CPUs cpu0 (BSP): apic id: 1, version: 0x00040011, at 0xfee00000 cpu1 (AP): apic id: 0, version: 0x00040011, at 0xfee00000 io0 (APIC): apic id: 2, version: 0x000f0011, at 0xfec00000 io1 (APIC): apic id: 3, version: 0x000f0011, at 0xfec01000 aacd0: <Volume> on aac0 aacd0: 34712MB (71091456 sectors) aacd1: <Volume> on aac0 aacd1: 34712MB (71091456 sectors) aacd2: <Volume> on aac0 aacd2: 34712MB (71091456 sectors) Mounting root from ufs:/dev/aacd0s1a ccd0-3: Concatenated disk drivers /dev/ccd0a on /var/spool (ufs, asynchronous, local, noatime, writes: sync 56581 async 16106785, reads: sync 10606488 async 2446) ccd0a==3x9GB partitions. И ниччего там кроме postfix&nfsiod нету. Никаких body checks/etc, только транспорт мап(точнее 2) на 100M+. 100 smtpd limit, но уже 40 могут приложить процентов на 60 запросто. (с IDE/p3-1GHz+2xIDE было визуально хуже) Это правда экстрим какой-то, (а не в целях померяться). Ну и ещё vfs.ufs.dirhash_maxmem: 67108864 (ээ - ну тут наверно всем и 8M хватит,это если в спул загнать xxGB столько надо - иначе помирание в system time совсем сразу при дефолтных 2M dirhash_maxmem, особенно если оно ничего со спулом полезного делать не будет)

...

б) не держать спул на большом разделе (более 10% от размера всего диска - хотя это более от размеров файлов зависит, и я не думаю, что у Вас поток мелких писем в 100-1000KB/s). в) найти ту нагрузку, при которой ничего не клинит - и ограничить поток до приемлеиого уровня. Пожалуй - это самый главный совет. ограничением кол-ва smtpd ? =) wrong way, оно ресурсы сильно не ест. Ест-ест - например, если smtpd будут на каждом адресе/порте свои висеть, а коннектиться к ним будут по очереди (то же самое количество клиентов), то нагрузка получится значительно больше (больше idle smtpd будет).

...

г) а на других фрях не пробовали то же самое? на фрях как 4.8-p_чегототам, так и на других вплоть до 5.2.1 одна и та-же ситуация была. На 5.x ещё не пробовал такое.

...

д) использовать всюду btree а не hash или вообще всякие ttransport maps на sql где-то держать. а причем тут транспорт ? стоит себе релей, задача которого принять коннекшн, по всяким RBL спросить, amavis+clamav+SA отработать и отдать на другой Тут я где-то в гугле начитался, что SA может 300+MB memory сжирать - эт правда? и на каких нагрузках ?

тазик, чтобы тот cyrus положил. Там из транспорта одна строка:

* relay:большой_тазик При небольшом потоке писем (в сравнении с тем, что вы с ними делаете) - оно рояль врядли сыграет, но я б просто smtp transport похакал :).

Спасибо всем, особенно Victor Cheburkin , который обратил мое внимание на простое увеличение производительности путем отключения проверки в base64-сегментах письма.

Включил, работает, не клинит вроде ничего. Игрался я в детстве в Armored fist-2, и была там миссия, где ~50 всяких танков-бтр-бмп ломятся на базу - так вот на p-112 (75MHzx1.5) оно не жило точно так же, как и на p-75. А на p-133 - никаких тормозов, вообще. Эт я к тому - что при критических нагрузках, где как в бассейне с двумя трубами - так главное, чтоб трубы были правильного диаметра :-|. Иначе лавинообразный рост нагрузки опд действием нагрузки - и ничего не взорвётся, а просто тихо загнётся(как хорошо, что мы не АЭСами управляем:)).

-- Best regards, Paul Arakelyan. =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message