At 13:16 3/03/03 -0500, Alan Brown wrote:

This is a bit off topic, but....

On Mon, 3 Mar 2003, Steve Hillman wrote:

> At 04:06 AM 3/3/2003 -0500, you wrote:
> >The mailserver I had handling 1-2 million messages/day was only a
> >k6/400. Tweaking sendmail makes a big difference.
>
> Just curious - Sendmail and qpopper (or some other popper) on the one box,
> or just sendmail acting as an MX?

Both on the same box, with some level of spam filtering too - using
DNSBLs (light load)  and Spam Assassin (tagging only).

Whether you use Spam Assassin for "tagging only" or sorting spam into other folders, the load is the same. It is the tests that determine if it is spam or not which take most of the CPU time.


I had to update from a 486 to handle body tagging. Spam Assassin is
/bin/sh based so was killing the machine.

Umm, not sure what you mean by /bin/sh based - Spam Assassin is most definately Perl based.


Perl based filtering agents have the same (or worse) problem. The
startup load for a dozen parallel perl proceses can quickly kill a
ramstarved (< 256Mb) machine.

Which is why Spam Assassin gives you the option of using the spamc/spamd client server pair.


One spamd daemon (a full perl copy of spamassassin) runs in the background waiting for connections. It uses approximately 15MB of ram, and because its running all the time, that is preloaded.

spamc is a very small C program that connects to spamd, and has a neglibible startup time or memory footprint. Each spamc request causes spamd to fork off a process to handle it, but because of copy on write VM there is no startup overhead or memory overhead in forking that new spamd child.

Memory is more important than CPU most of the time - if you start
hitting swap, you're only going to run as fast as your hard drives, even
if you have a 200GHz Itanium processor from5 years in the future.


Indeed.

Regards,
Simon



Reply via email to