You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@spamassassin.apache.org by bu...@bugzilla.spamassassin.org on 2005/02/08 08:33:29 UTC
[Bug 4123] New: Spam children should check memory usage and die if fat
http://bugzilla.spamassassin.org/show_bug.cgi?id=4123
Summary: Spam children should check memory usage and die if fat
Product: Spamassassin
Version: unspecified
Platform: Other
OS/Version: other
Status: NEW
Severity: enhancement
Priority: P3
Component: spamc/spamd
AssignedTo: dev@spamassassin.apache.org
ReportedBy: lwilton@earthlink.net
This is vaguely related to bug 3838, and probably several others.
The big problem (pun intended) that most people seem to have with the new
algorithm for keeping children around is that one will get fat suddenly for
some reason, and then sit around consuming memory for possibly quite a long
time. If several children happen to all get fat during that period the machine
falls over.
The current 'solution' to this is a combination of limiting message size
processed, limiting number of connections per life, and limiting number of
children.
The actual desire is to limit total percentage if actual memory consumed. The
current options only provides assorted means to approximate the desired goal.
Since they don't actually measure total memory usage (or even their won usage)
this is to be expected.
Suggest a new option that will make a child die after it gets indigestion,
regardless of the number of children/lives/etc specified. The amount of memory
consumed could be an administrator set option, or it could be a computed
percentage if the mean child size over the last hour, or something else that
seemed appropriate. The simplest might be an administrator option, but it
would make more sense to try to guess the right size automatically.
Yes, I realize the problems with determining shared memory size on various
versions of *nix. Those are certainly annoyances, but I don't see them as
negating the basic concept.
An alternate way to decide when to die might be to factor load average times
memory size and die above some cutoff amount.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 4123] Spam children should check memory usage and die if fat
Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4123
felicity@apache.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|3.1.2 |3.2.0
------- Additional Comments From felicity@apache.org 2006-03-15 01:47 -------
in thinking about this more, this isn't trivial, and it's an enhancement request, so I'm pushing it to 3.2.0.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 4123] Spam children should check memory usage and die if fat
Posted by bu...@bugzilla.spamassassin.org.
http://bugzilla.spamassassin.org/show_bug.cgi?id=4123
Bob@Menschel.net changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|Undefined |3.1.1
------- Additional Comments From Bob@Menschel.net 2005-04-28 22:47 -------
Triage: Given that a fairly large number of sites have suffered from fat spamd
children throughout the 3.0.x series to date, and that at least one cause of fat
children, bug 3082, has been scheduled to 3.2.0, I'm setting a provisional
target milestone of 3.1.1 for this request, hoping it's a fairly simple
work-around to the generic problem.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 4123] Spam children should check memory usage and die if fat
Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4123
jan@gingerall.cz changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jan@gingerall.cz
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 4123] Spam children should check memory usage and die if fat
Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4123
felicity@apache.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|3.2.0 |Future
------- Additional Comments From felicity@apache.org 2006-09-10 06:20 -------
punting again
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 4123] Spam children should check memory usage and die if fat
Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4123
felicity@apache.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|3.1.1 |3.1.2
------- Additional Comments From felicity@apache.org 2006-02-22 22:54 -------
I don't actually believe we can do this -- as far as I know there's no way to have perl tell the script how
much RAM is being used. but punting to 3.1.2 for now.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
[Bug 4123] Spam children should check memory usage and die if fat
Posted by bu...@bugzilla.spamassassin.org.
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4123
------- Additional Comments From jan@gingerall.cz 2006-11-28 06:33 -------
(In reply to comment #2)
> I don't actually believe we can do this -- as far as I know there's no way to
> have perl tell the script how much RAM is being used. but punting to 3.1.2
> for now.
(In reply to comment #3)
> in thinking about this more, this isn't trivial, and it's an enhancement
> request, so I'm pushing it to 3.2.0.
I think it would be pretty enough just to kill the child which memory usage
exceeds a configured limit (the same way it could be killed now when it
processed a configured number of requests)...
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.