Frank Chan wrote:
I had the same issue at the end of 2010 which someone or people flooded
my mail server and cause spamd to lock up and these are the things I did
to relieve this from suggestions from people on this mailing list.
1) Reduce the custom rules in local.cf to a minimum possible size. I had
a 246KB size & 6k lines in local.cf during those spamd lock ups and
someone suggested to reduce the size of local.cf so I removed many
custom rules and consolidated some rules and it now it is 40KB size & 1k
lines.
2) Reduce the timeout of spamd child to a minimum possible. I have
checked the logs to see what was the maximum amount of time to spamd to
process a message from legitimate people and add an small time buffer on
top that and that will be your timeout-child.
*nod* I could probably review the local rules again, but I'm not sure I
could remove many without impacting the spam catch rate. We have the
child-timeout set to a point that should allow for "normal overload"
conditions, with some extra headroom, and the spamc caller implements
its own timeout anyway IIRC.
These both just affect per-child process times though; neither of these
have any impact where the entire spamd process tree just... takes a
smoke break.
3) Reduce the timeout of spamd ident timeout to minimum possible. Again
I checked the logs to what was the maximum time to for ident to return
and add a small time buffer and that will be your ident-timeout.
We have ident disabled; I'm not even sure what use it is TBH.
These are good places to look for fixing up problems with bad
performance under heavy load... the problem at hand is random lockups
during *normal* (or low) load levels - ie, 1-5 messages per second,
where "high" load means 30+/s.
-kgd
