[uanog] Re: Postfix perfomance

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