On Wed, Oct 02, 2002 at 11:17:31AM +0800, Eddie Javier wrote: > If it's possible, avoid using Amavis. It's a memory hog (at least the > last one I used). You mentioned that in every message that comes in, > Amavis spawns the virus scanner. Imagine if you have thousands of > email coming in.
Last night we had some major downtime because of building power issues, so our backup mail exchange -- you know who you are, thank you very much again, hehehe --- took the brunt of storing the messages for our domains until our server got back up. We were using amavis-ng, which I recently migrated to from the standard amavis in an attempt to check it out. To my dismay I found that amavis-ng does not have any limits as far as scanner concurrency is concerned. It will spawn a copy of each scanner for each message that arrives as it is passed to it by the mail server. The flood of email from our backup mail exchange obviously brought our system to its knees -- load levels shot up WAAAY above normal, until the kernel ran out of memory started killing random processes. The good news of course is that the AMaViS "new" tree, which the amavis-exim, amavis-milter and amavis-postfix packages on Debian Sid are based on, allows you to define how many concurrent scanners it will use (indirectly, through the maximum number of servers to have open). With this the system worked really well. Postfix accepted the mail as they came in, and waited patiently until amavisd was ready to accept new messages for processing. I set amavisd to a conservative concurrency of two servers, since McAfee uvscan does a full modprobe scanning devices in /dev for some wierd reason on each invocation. This works nicely, and the system can handle well, as much as its been thrown so far. I know there are other ways to do the same thing, but I just thought I'd mention this for the record, and for anyone interested. :) --> Jijo PS- on a different note, I also just transferred our primary and secondary servers to ext3 from XFS. I was hitting wierd mount recovery hangs on XFS that I couldn't reproduce and yet happened enough that it was "reproducible" (albeit I didn't know exactly what to do to accomplish it, or exactly what to do to fix it, either, tsambahan lang). I know I could have worked things out with the SGI XFS team, but that would need waiting for another hang and then running a backtrace using KDB, which I do -NOT- want to go through on our servers anymore. Performance has been okay so far. Nothing great but nothing significantly slow during normal loads, either. I have yet to do benchmarks, but not now. I have this warm fuzzy feeling that things are "safer" with ext3, though, and the ordered data writes are comforting. -- Federico Sevilla III : http://jijo.free.net.ph Network Administrator : The Leather Collection, Inc. GnuPG Key ID : 0x93B746BE _ Philippine Linux Users Group. Web site and archives at http://plug.linux.org.ph To leave: send "unsubscribe" in the body to [EMAIL PROTECTED] Fully Searchable Archives With Friendly Web Interface at http://marc.free.net.ph To subscribe to the Linux Newbies' List: send "subscribe" in the body to [EMAIL PROTECTED]
