Ron I'd check what RBL's and URI-RBL's you are running.
If you haven't turned any of them then you're running them all - which can lead to very long processing times. Choose one or two you want by looking through the 20_dnsbl_tests.cf file. And give then rest a zero score in local.cf Running a local caching nameserver on the machine itself can help quite a bit here too. -- Martin Hepworth Snr Systems Administrator Solid State Logic Tel: +44 (0)1865 842300 > -----Original Message----- > From: Ron Smith [mailto:[EMAIL PROTECTED] > Sent: 25 July 2008 15:45 > To: [EMAIL PROTECTED]; users@spamassassin.apache.org > Subject: Re: Memory Leak? > > Thanks, Duane for your kind comment. Yes I have tried > different methods. I used to use cgpsa. cgpav was only for > antiviral stuff and it failed miserably when I tried to have > it doing the spamassassin calls also. It seems that no matter > how I call spamd there is an issue. > > I'm using scanspam.sh as an execute call in CGPro. In fact I > think I've actually identified where in the shell script the > issue may be occurring. Here's an excerpt from the key part: > > /var/CommuniGate/spam/spamprep "$myCgate/$QueuePath" > "$ReturnPath" > "$Username" | > /usr/bin/spamc -d 127.0.0.1 -t 100 -u "$Username" >> > "$myCgate/ Submitted/$NewFile" > mv /var/CommuniGate/Submitted/$NewFile > /var/CommuniGate/Submitted/ $FinalFile > > CG Pro gives execute scripts 2 minutes to finish or it kills them. > Possibly it calls the script again, or so I thought, which > might be the source for the multiple .tmp extensions and long > processing times. > If the first line above is calling the spamd, then CG Pro > kills the script before the mv command adds the .sub > extension. That would account for the orphaned .tmp files > that have the spamd processing finished, but never got submitted. > > Still that does not tell me that there is a problem with CG > Pro and shell scripts. It could likely just as much mean that > spamd is slowed because of a memory leak in that code. > > Notice also that the -t 100, which means that spamd should > finish processing within 100 seconds (or so I understand) > SHOULD mean that CGPro shouldn't ever reach the 120 second (2 > minute) limit that would cause it to kill the sh process. > > When I watch the submitted folder, MOST of the processing > however occurs very quickly and there are usually not more > that 3 or 4 .tmp files being processed. Until the spam load > increases. That's where my suspicion of a memory leak in > spamd comes from. > > In order to further test this, I'm considering altering the > script above to actually call another script basically > containing the two lines above, thereby preventing CGPro from > killing the script prematurely. That's a next step. If the > delay in processing is still present then, I would think that > I've moved suspicion away from CG Pro/ spamd interaction as a > cause for this. > > Ron Smith > [EMAIL PROTECTED] > > "Having an email problem is painful, but character-building." > > On Jul 25, 2008, at 9:46 AM, Duane Hill wrote: > > > For a test, ever thought about changing to a different script? > > > > Even through we have two Postfix border servers doing filtering, I > > still have something on our internal (antiquated) > CommuniGate server. > > > > I am using SA 3.2.5 with cgpsa and there hasn't been one bit of an > > issue. > > > > http://www.tffenterprises.com/cgpsa/ > > > > -d > > ********************************************************************** Confidentiality : This e-mail and any attachments are intended for the addressee only and may be confidential. If they come to you in error you must take no action based on them, nor must you copy or show them to anyone. Please advise the sender by replying to this e-mail immediately and then delete the original from your computer. Opinion : Any opinions expressed in this e-mail are entirely those of the author and unless specifically stated to the contrary, are not necessarily those of the author's employer. Security Warning : Internet e-mail is not necessarily a secure communications medium and can be subject to data corruption. We advise that you consider this fact when e-mailing us. Viruses : We have taken steps to ensure that this e-mail and any attachments are free from known viruses but in keeping with good computing practice, you should ensure that they are virus free. Red Lion 49 Ltd T/A Solid State Logic Registered as a limited company in England and Wales (Company No:5362730) Registered Office: 25 Spring Hill Road, Begbroke, Oxford OX5 1RU, United Kingdom **********************************************************************
