On Tuesday 26 October 2004 16:42, [EMAIL PROTECTED] shaped the electrons to say: > On Mon, 25 Oct 2004, Eric Worthy wrote: > > Anyone have any advice on what I could be doing wrong or how to improve > > the performance of the scanning? > > We always get a great performance boost in software by adding > -march=(yourcpuhere) -O2 -fomit-frame-pointer -static to the build lines. > If you can build static binaries an additional CPU register is available > for function calls (EDX iirc). If you're a quad p3 xeon, you want > -march=i686. You might also play with benching -O2 vs -03. We seem to > get mixed results depending on the nature of the software. Some perform > worse at -O3 and except for some weirdness in loop unrolling, I'm not sure > why O3 would give slower performance. Make sure that this happens for at > least clam and clamd. (caveot: some optimizations can create instability > so test it). Clam uses many libraries like libz and rebuilding those > dependent libraries may help as well (may not matter if staticly linked?) > > Another point to look at is disk o/i bottle neck. Mail has a tendency to > write-copy-write-copy-write especially when you have a scanner and an MTA. > This creation and deletion of spool files makes for a lot of journal > traffic (ext3/reiser, assuming Linux) to the hard drive. Unfortunately, > journal traffic is largely synchronous so it can rollback transactions in > the event of a failure. Filesystem noatime,notail options are your friend > here.
A good solution here is to have a seperate disk preferably on a hardware raid controller for your mail queue (/var/qmail/queue if you use qmail). That coupled with reiserfs with blocksize 4096 hugely increases performance. If you are lucky to have a fibre channel SAN, you can put the queue on there for uber performance! > > You can get some mileage by putting your MTA's temp dir on a shmfs/tmpvs or > other type of VM filesystem if you're on a different OS to reduce the disk > i/o cycles. By freeing I/O cycles, the cpus can do more *real* work and > not wait precious cycles on io time. On a 2.6 kernel, vmstat will tell > you io-wait time (wa) get a feel for where the bottle neck is. This can be dangerous. If your mta stores any mail here for whatever reason and the box (again for whatever reason) reboots/dies - you lose all that mail. > > Hope this helps. We're constantly fighting io wait here due to the virus > spam and message spool/accounting database and currently our bottleneck is > definitely disk, not cpu (3.2ghz p4-ht). Same here. We use qmail and find that 128Mb Raid controller for the queue dir increase the I/O immensely. Reiserfs helps as well. -- +----------------------------------------------+ (0> Scott Ryan //\ Senior Unix/Linux Engineer V_/_ Telkom Internet - South Africa +----------------------------------------------+ He who controls the past, controls the future, He who controls the present, controls the past. - George Orwell, 1984 ================================================ _______________________________________________ http://lists.clamav.net/cgi-bin/mailman/listinfo/clamav-users
