http://bugzilla.spamassassin.org/show_bug.cgi?id=3516
Summary: DNS query steady slowdown if spamd left running
Product: Spamassassin
Version: SVN Trunk (Latest Devel Version)
Platform: Other
OS/Version: other
Status: NEW
Severity: normal
Priority: P5
Component: spamc/spamd
AssignedTo: spamassassin-dev@incubator.apache.org
ReportedBy: nneul@umr.edu
Just started noticing this on a test machine running 3.0svn. If I set spamd to a
requests-per-child greater than 1, the URIDNSBL checks appear to get slower
after every iteration - to the point of 120 second lookup times. If I had a slow
connection and was using the outside servers - even then that would be really
bad - but my this is on a dedicated box, with 1 user, doing MOST of the rbldns
queries to another local box (over GigE) with mirrors of most of the major rbls.
Timeouts are set to the defaults for the most part.
As soon as I switched spamd to only do 1 request per child, the queries remained
consistently timed. (Still slower than I'd expect at a few seconds, but I'd
imagine that it due to timing being joint for all of the queries in a batch or
something.)
As this is totally a test installation (independent of our production install),
I'll be happy to test anything you'd like to me test out, I just wasn't sure of
any really good way to test it, and the background dns lookup code wasn't
immediately obvious how it functioned.
In my view, this behavior would make spamd 3.0.0 w/ a >1 requests per child
unusable for a large install, since it rapidly became unusable on a single-user
installation.
Note also - it's not a instantaneous jump, it's as if each successive request is
taking longer and longer. 3,5,10,16,25,35,...120 seconds like that.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
Summary: DNS query steady slowdown if spamd left running
Product: Spamassassin
Version: SVN Trunk (Latest Devel Version)
Platform: Other
OS/Version: other
Status: NEW
Severity: normal
Priority: P5
Component: spamc/spamd
AssignedTo: spamassassin-dev@incubator.apache.org
ReportedBy: nneul@umr.edu
Just started noticing this on a test machine running 3.0svn. If I set spamd to a
requests-per-child greater than 1, the URIDNSBL checks appear to get slower
after every iteration - to the point of 120 second lookup times. If I had a slow
connection and was using the outside servers - even then that would be really
bad - but my this is on a dedicated box, with 1 user, doing MOST of the rbldns
queries to another local box (over GigE) with mirrors of most of the major rbls.
Timeouts are set to the defaults for the most part.
As soon as I switched spamd to only do 1 request per child, the queries remained
consistently timed. (Still slower than I'd expect at a few seconds, but I'd
imagine that it due to timing being joint for all of the queries in a batch or
something.)
As this is totally a test installation (independent of our production install),
I'll be happy to test anything you'd like to me test out, I just wasn't sure of
any really good way to test it, and the background dns lookup code wasn't
immediately obvious how it functioned.
In my view, this behavior would make spamd 3.0.0 w/ a >1 requests per child
unusable for a large install, since it rapidly became unusable on a single-user
installation.
Note also - it's not a instantaneous jump, it's as if each successive request is
taking longer and longer. 3,5,10,16,25,35,...120 seconds like that.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.