MailWatch / Learning extremely slow

[Sephiroth]

Hi!

I'm having some performance issues with my installation.
When I click the learn spam link on the bottom of my mail, I usually end up in a timeout.
I have to refresh multiple times, till I get the confirmation.

This happens on the internet as on the local LAN.
CPU/MEM seem to be fine, no load at all.

Any hints?

Regards

Philippe

[jon doe]

I have the same issue as well. To work around the issue for now maybe there is a timeout setting that can be extended so that we don't have to refresh to get it to learn?

[Sephiroth]

I moved the VM from iSCSI to a local SSD, and now everything is working smothly.
I'm not sure now if some serious paging is going on in the VM, or what needs so much IO's.

[AITCS]

jon,

edit /etc/MailScanner/MailScanner.conf

Change the following line to something more suitable. I've used 900 for my setup.
SpamAssassin Timeout = 900
(Should be set to 75 by default)

Anything less than this and spam would pass through to our mail server.
I'm not sure what the issue is, but of the 3 installs I've done of EFA, only one is behaving slooooowly.
Unfortunately no SSDs to offload the VM to however.

[stusmith]

Are any of you using munin to monitor your MySQL server installs? I'm curious to see what the query times look like...

I had some trouble with my learn+report throwing an error in IP::Country::Fast, but just the learning itself doesn't seem to complain. I'm going to try AITCS's fix and see if that resolves my problem as well.

[121mhz]

It's a new problem in 3.0.1.8, I didn't have it before and I have three installations that have it now. In all cases, it seems to be a disk I/O problem and can't be easily resolved. You have to up the spamassassin timeout.

[AITCS]

We upgraded our RAID card from zero to 4GB of cache, and what a difference it made.
It now takes 1-2 secs to learn compared to the ~30 it used to take.
This very much feels like it's related to disk IO speed.