[Mimedefang] really high cpu

[James Ebright]

On Sun, 20 Mar 2005 17:57:11 -0600 (CST), -ray wrote

> Far more common i see is an extremely large /var/spool/mqueue dir on 
> very slow (ext2) filesystem.  Consider splitting it into several 
> queues, and move old messages into slower queues.

Being a private entity... we do not have a large mailq at any given time. We
do however have a very strict EULA/TOS agreement with our customer that
explicity spells out what will happen if they are cuaght sending spam..
including "clean up" fees they are responsible for.. we have had only 2
spammers since we have implemented this policy, both caught before they sent
over 200 messages and both promptly terminated.

Also, most people running Linux have not run the ext2 file system for quite
some time.... ext3 is the default now days and is quite a bit faster...
rieserfs and XFS are also better in some ways (and worse in others) JFS is
available... and pretty much ANY file system out there except only limited
support for NTFS (like we really want to use it anyway). I prefer a
journalling system like rieserfs or ext3 for most of my file systems... ext2
partitions are relegated to recovery and repair tools now days. Also... isn't
Solaris still using UFS???

Split queues we used to use back on what is now the Earthlink cluster (sadly
no longer a *nix cluster :-( )... but that was due to lack of any real TOS
agreement or monitoring or even understanding by the management team. Yes,
there we did see rather large queues build up, that is a good tip if you are
experiencing this issue... but overkill if you are not.

Even back then I did not consider 1MB to be "big" in the general sense, but to
be enormous for a host file (hehe) and yes, if you have real users on the box
then /etc/passwd file size would also be critical. Basically any file that
sendmail touches on a per message/resipient basis (we used truss to watch it).

Jim





--
EsisNet.com Webmail Client