Print Page | Close Window

Problems with Spamfilter using 100% cpu

Printed From: LogSat Software
Category: Spam Filter ISP
Forum Name: Spam Filter ISP Support
Forum Description: General support for Spam Filter ISP
URL: https://www.logsat.com/spamfilter/forums/forum_posts.asp?TID=6818
Printed Date: 05 February 2025 at 6:00am


Topic: Problems with Spamfilter using 100% cpu
Posted By: roaridse
Subject: Problems with Spamfilter using 100% cpu
Date Posted: 26 March 2010 at 5:13am
Hi,
 
This is an issue which I have asked about before, but the last couple of months Spamfilter has been totally stable. 3 days ago things just went crazy. Now I have to restart spamfilter 10-15 times every day to get the mail going. It doesn't seem to be any kind of DoS attack either.
 
Memory-usage seems to be low, and I have tried deleting the Bayesian Corpus, and all the spam-quarantine without help.
 
I have also upgraded to 4.1.3.822 - no difference.
 
Any suggestions?
 
Last time this happened, I started to make an Authorized-TO file which will update from Active Directory plus an QmailLDAP-server, with approx 300 domains and 4000 addresses. The theory was to ease the CPU-load on the spamfilter but I stopped the project when I tested this file on ALL DOMAINS, and every mail were dropped as not authorized.... Should I do a new attempt here to ease the load on the server?
 
 
 


Replies:
Posted By: LogSat
Date Posted: 28 March 2010 at 12:53am
roarisde,

Could you please zip and email us SpamFilter's activity logfile for a day this happened to support at logsat.com so we can see what is happening?


-------------
Roberto Franceschetti

http://www.logsat.com" rel="nofollow - LogSat Software

http://www.logsat.com/sfi-spam-filter.asp" rel="nofollow - Spam Filter ISP

Posted By: jmlalley3
Date Posted: 20 April 2010 at 7:16pm
We had a similar problem. Roberto suggested the following which we implemented.
1. Disable Bayesian Filtering by moving slider to 100. This reduced load by 30%

2. His examination of our log file suggested corruption of the corpus. His solution was to stop the service, rename or delete the folder called corpus and restart the service. We are now at about 33% CPU with 100 inbound connections.


Print Page | Close Window