You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Gary MacKay <ga...@edisoninfo.com> on 2005/02/08 20:23:09 UTC
Incredibly slow SA checks
What process takes place during the "Calling SA checks" routine? I have amavis-new and spamassassin 3.02 running, with SA configured to use SQL. I cranked up the amavis log_level to 5 and watched the logs. They show a message coming in at what I guess to be acceptable speed until just after the ClamAV check. Right after the ClamAV check I see the "Calling SA checks" message, then nothing for 20 to 40 seconds, then the next log message. How can I find out what is taking so long?
- Gary
Re: Incredibly slow SA checks
Posted by JamesDR <ro...@bellsouth.net>.
Depends on which DNS server you use, for the most part, you'll need a
file called 0.168.192.in-addr.arpa.dns (for a 192.168.0.x subnet, I use
the windows dns server.) Inside I have (watch for word wrapping):
;
; Database file 0.168.192.in-addr.arpa.dns for 0.168.192.in-addr.arpa zone.
; Zone version: 1852
;
@ IN SOA server.domain.domain. rsp.domain.domain. (
1852 ; serial number
300 ; refresh
600 ; retry
86400 ; expire
3600 ) ; minimum TTL
;
; Zone NS records
;
@ NS server.domain.domain.
server.domain.domain. A 192.168.0.1
;
; Zone records
;
4 PTR mysqlsa.domain.domain.
The 4 is the last digit of the ip, mysqlsa is my spamd server (along
with mysql). Also, make sure your mysql server has proper dns setup in
it as well, with out dns, it falls down the chain of name res. to
determine the connecting machine for auth.
HTH
Thanks,
JamesDR
Gary MacKay wrote:
> Thanks for the help James. I have two servers, the email/web server
> running dns for the domain(s) ie. outside IP's, and another samba server
> with dns for the Winbloze "domain" ie. 192.168. IP's. What should the
> PTR's look like?
>
> - Gary
>
>
> JamesDR wrote:
>
>> This may seem way out there, but not to long ago we experienced
>> something similar to what you are talking about. SA would take
>> between 10 to 90 seconds to scan a message. We disabled network tests,
>> removed rules but none helped. The only thing that helped was to
>> disabled bayes, user_prefs, and awl. This lead us to believe that
>> there was an issue with mysql or a related issue with it. We only
>> enabled one of the sql items at a time, but they all showed the same
>> issue when scanning. We then took a look at why SA may have been
>> taking a long time to connect to the mysql server. At about this time
>> it dawned upon us that, mysql does a lookup of the connecting host
>> name when doing its Auth phase of the connection. Long story short,
>> we added PTR's for all of the connecting spamd servers, and the issue
>> went away (was mentioned in this list.) You may want to try adding
>> PTR records in your local dns records. This even happened when SpamD
>> was connecting to the local Mysql server using localhost or 127.0.0.1
>> and remotely with the name or the ip.
>>
>> Something to consider.
>> Thanks,
>> JamesDR
>>
>> Gary MacKay wrote:
>>
>>> ClamAV is running and the amavis log_level=5 setting shows it
>>> scanning very very fast. It is whatever takes place next that is
>>> boggin things down.
>>>
>>> - Gary
>>>
>>> Richard Ozer wrote:
>>>
>>>> Is clamd running? Is clamav.conf set up to scan via a tcp socket?
>>>> If neither of those are happening, then you may be experiencing an
>>>> amavis timeout while it tries to communicate with clamd.
>>>>
>>>> RO
>>>>
>>>> To: <us...@spamassassin.apache.org>
>>>> Sent: Tuesday, February 08, 2005 11:23 AM
>>>> Subject: Incredibly slow SA checks
>>>>
>>>>
>>>>> What process takes place during the "Calling SA checks" routine? I
>>>>> have amavis-new and spamassassin 3.02 running, with SA configured
>>>>> to use SQL. I cranked up the amavis log_level to 5 and watched the
>>>>> logs. They show a message coming in at what I guess to be
>>>>> acceptable speed until just after the ClamAV check. Right after the
>>>>> ClamAV check I see the "Calling SA checks" message, then nothing
>>>>> for 20 to 40 seconds, then the next log message. How can I find out
>>>>> what is taking so long?
>>>>>
>>>>> - Gary
>>>>>
>>>>
>>>
>
Re: Incredibly slow SA checks
Posted by Gary MacKay <ga...@edisoninfo.com>.
ClamAV is running and the amavis log_level=5 setting shows it scanning very very fast. It is whatever takes place next that is boggin things down.
- Gary
Richard Ozer wrote:
> Is clamd running? Is clamav.conf set up to scan via a tcp socket? If
> neither of those are happening, then you may be experiencing an amavis
> timeout while it tries to communicate with clamd.
>
> RO
>
> To: <us...@spamassassin.apache.org>
> Sent: Tuesday, February 08, 2005 11:23 AM
> Subject: Incredibly slow SA checks
>
>
>> What process takes place during the "Calling SA checks" routine? I
>> have amavis-new and spamassassin 3.02 running, with SA configured to
>> use SQL. I cranked up the amavis log_level to 5 and watched the logs.
>> They show a message coming in at what I guess to be acceptable speed
>> until just after the ClamAV check. Right after the ClamAV check I see
>> the "Calling SA checks" message, then nothing for 20 to 40 seconds,
>> then the next log message. How can I find out what is taking so long?
>>
>> - Gary
>>
>
Re: Incredibly slow SA checks
Posted by Richard Ozer <ro...@ois-online.com>.
Is clamd running? Is clamav.conf set up to scan via a tcp socket? If
neither of those are happening, then you may be experiencing an amavis
timeout while it tries to communicate with clamd.
RO
To: <us...@spamassassin.apache.org>
Sent: Tuesday, February 08, 2005 11:23 AM
Subject: Incredibly slow SA checks
> What process takes place during the "Calling SA checks" routine? I have
> amavis-new and spamassassin 3.02 running, with SA configured to use SQL. I
> cranked up the amavis log_level to 5 and watched the logs. They show a
> message coming in at what I guess to be acceptable speed until just after
> the ClamAV check. Right after the ClamAV check I see the "Calling SA
> checks" message, then nothing for 20 to 40 seconds, then the next log
> message. How can I find out what is taking so long?
>
> - Gary
>