http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5451
[EMAIL PROTECTED] changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |WORKSFORME
------- Additional Comments From [EMAIL PROTECTED] 2007-05-08 13:21 -------
(In reply to comment #3)
> when this happens, we see 300+ database connections to postgres on
> another server. This only happens when the max children is reached. Its almost
> like when the server reaches the max children and then keeps trying the
> database.
I would imagine that you'll see a DB connection open for each of user_prefs,
bayes and AWL for each child, so if 140 children are all running (and probably
taking a long time to do anything, if anything at all, if you've run out of
memory) 300+ connections would sound reasonable to me.
(In reply to comment #4)
> It's been working better, but when it gets busy I get alot of
> "spamd[61105]: prefork: server reached --max-children setting, consider
> raising
That's normal, it just means that all of the children are busy and at least one
new request has been queued, but will be served. It's up to you to decide if
increasing the number of children is appropriate or possible.
> it". The memory usage just went up to 1Gig but went down right away to about
> 400mb. So it seems more stable with -m80
Down to 400MB with all 80 children spawned? That sounds *really good*.
Actually 1GB for 80 children sounds really good too.
> The server should be able to handle alot more I would think.
I'm not familiar with FreeBSD memory management, but if your typical child size
is 50MB, and say you share half of it, you're looking at only 40 children per
GB.
You could try incrementally increasing the number of children. I'd be surprised
if you make it much past 100.
Anyway... since there's nothing to suggest a bug, I'm going to close this as
WORKSFORME. Feel free to re-open this if you think there's a bug (or you find
one). Otherwise, you're more than welcome to continue this discussion on the
users@ list.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
