AW: Amavis SA Check high load

[Cedric Knight]

Grooz, Marc (regio iT) <Marc.Grooz at regioit.de>:
>> Dear mailing list,
>>
>> For some days I have notice the following in my amavis systems. Mails 
>> from a sender take 20 or 30 seconds to pass the amavis SA Check and 
>> heavy utilize the cpu. Normally the whole amavis check is completed in 
>> a few seconds (1-4).
>> By SA timing indication I could see that this is caused by the tests_pri_0.
>> Do you know if there is a way to look even more closely what takes so 
>> much time?
>> I had already tried the HitFreqsRuleTiming.pm. But that didn't help me.
>>
>> I had only a test email and not the original mail. The Mails that 
>> course the problem are S/Mime signed.

On 15/03/13 19:13, Patrick Ben Koetter wrote:
> 
> Have you feed the mail to spamassassin on command line?

On 16/03/13 08:14, Grooz, Marc (regio iT) wrote:
> No, unfortunately I didn't get the original mail. Should I get more information from the sa command line?

If you don't have a sample that causes the high CPU, you don't have
anything with which to replicate the problem with spamassassin -D -t.

The TIMING log entries list real time, not CPU time.  You would expect
tests_pri_0 to take longest anyway, particularly if you have remote
tests on (which do not use much CPU but may wait for up to about 10
seconds or rbl_timeout), since most SpamAssassin tests are priority 0.

When you say you tried HitFreqsRuleTiming.pm, did it produce any
timing.log?  I wouldn't expect it to on a live stream with amavis,
because it never finishes.  Possibly some logging could be added at
check_end() at regular intervals.  Hacking at your own risk and it might
produce massive log files.

What version of SpamAssassin and amavis are you running?

How do you know the messages are S/MIME signed?  Are they also
encrypted?  Neither should be any problem.

Your options might include:

* Contact the recipient and sender (if it's not spam) of the message and
ask for a copy of the message for debugging purposes.
* If they can't find it, you could in theory use amavisd-nanny to
identify a problematic message as it goes through, and take a copy of
the txt file from the amavis working directory; or quarantine the sender
by setting a high @score_sender_maps, and $spam_quarantine_to =
'spam-quarantine'.

* Look at any rules you have downloaded or added yourself.  Particularly
look for regexes similar to \s*[\n-]{0,1000} that might cause a
combinatorial explosion and high CPU.
* Try disabling modules and rulesets and see if the problem continues.
This may not be practicable.
* Assign each rule (or set of rules, or suspect rule) a unique priority
x and look in the TIMING_SA at tests_pri_x.

Hope that is of some use.

C