When using top you see sa-learn processes causing high load on the server. This is usually caused when spamassassin or dovecot have problems. This will cause the real-time spam learning sieve filter to loop when it tries to call sa-learn to train a message.
1. Stop the dovecot service:
systemctl stop dovecot2. Kill any active sa-learn processes (this should bring the server load level back down to normal):
pkill -f sa-learn3. Note: After you have completed any of the solutions below remember to restart the dovecot service:
systemctl start dovecotSpamAssassin Problems
You can check that your SpamAssassin config has no errors using the command (It should not return any errors):
spamassassin --lintDovecot Problems
This error can also be caused by mailbox dovecot.index.cache files being over the default 512MB limit set by Warden. You can raise the limit vsz_limit as per the KB article:
If you are still having problems after trying both solutions above you can try the options below:
Options To Reduce CPU Usage
Option to use Redis as the Storage Backend
Warden supports using Redis as the Bayes storage engine instead of MySQL (this should speed up sa-learn). This can be found under Warden -> Settings -> Learning Settings -> Storage Settings. Detailed instructions for how to to switch to Redis can be found here.
Option To disable the Real-time Learning
You have the option of disabling the real-time learning under Warden -> Settings -> Learning Settings -> Sieve learning -> uncheck Use IMAP sieve learning and save the page. When the real-time learning is disabled in Warden the system will fall back to the Plesk nightly training task and auto-learning instead. Disabling the real-time learning will have minimal impact on spam training.
