Patrick, Versions before amavisd-new 2.7.0 and SA older than 3.3.0 are not particularly suitable for a pre-queue filtering setup. The combined new features of 2.7.0, SA 3.3.* and the postfix 'speed_adjust' made such a setup much better behaved.
Please read the introductory sections of 2.7.0 (pre)release notes: http://www.ijs.si/software/amavisd/release-notes.txt > Sep 2 13:00:47 ru amavis[87682]: (87682-15) TIMING [total 257879 ms] - > SMTP greeting: 25055 (10%)10, 25 s to get a greeting probably means there were more incoming sessions than the number of available amavisd processes. The smtpd_proxy_options=speed_adjust can help here. > SMTP DATA: 24052 (9%)19, The 2.7.0-pre7 brings a 4-fold speedup in receiving of large mail messages over SMTP. On our mailer the receiving transfer rate (postfix->amavisd) is now about 32 MiB/s. > check_init: 25053 (10%)29, Hard to say what is going on here. Either a very busy machine, or maybe access contention on a Berkeley DB. > gen_mail_id: 21050 (8%)37, A slow/overloaded SQL server? > mime_decode: 21063 (8%)45, A very busy machine, or huge mail - probably both. > AV-scan-1: 21058 (8%)53, Very busy machine or a very slow virus scanner. > decide_mail_destiny: 25156 (10%)63, Explicable only by a very much overloaded host, or memory shortage and swapping. > fwd-connect: 64265 (25%)88, postfix too busy to accept another connection??? Or perhaps you have too low a limit on the number of back-end smtpd processes. > nop, it's mostly shared memory here, With 80 amavisd process, I've still > 2GB RAM free, and absolutely no swap. With 120 amavisd process and a max > of 120 smtpd, I still have more than 1.5 MB of free RAM, and no swap. If you are not running SpamAssassin, the 80 processes on a 4 Gb host is probably still reasonable. So it must be the CPU overload, not a memory exhaustion. > > Also, to RUN those 80 amavis threads, I would start with at least 4 > > cores. > > I do agree about cores. The VM what tuned for 30-40 amavisd, I should > double the CPU, or remove amavisd and smtpd processes. I think I'm going > to remote amavisd/smtpd processes. I've found out few hours after sending > my question here that updating few perl modules could be the solution to > my problem. I'm writing "could be", because I'm still not sure it's THE > solution. After updating few perl modules (including NET::Socket) and > restarted amavisd, it immediately started to work great. It does not > guaranty it will not break under load again. Maybe, although I'm not aware of any performance-related problems with underlying perl modules. More processors would definitely help. Mark
