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 2006/10/18 14:01:49 UTC
[Bug 3839] increase amount of memory shared between spamd processes
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=3839
------- Additional Comments From jm@jmason.org 2006-10-18 05:01 -------
Created an attachment (id=3718)
--> (http://issues.apache.org/SpamAssassin/attachment.cgi?id=3718&action=view)
experiment; parse config in a subprocess
as a curiosity, here's a hack I was just trying.
The idea is to move parsing of the config into a sub-process, using a nifty
Storable hack from Brad Fitzpatrick's djabberd code -- the in_sub_process()
method in the patch.
with the patch applied, run spamd and a couple of spamcs:
cd t
../spamd/spamd -D -x -s stderr -C log/test_rules_copy --siteconfigpath
log/localrules.tmp -p 42580 -L & sleep 3; ps axuww | grep spamd ;
../spamc/spamc -F data/spamc_blank.cf -d localhost -p 42580 < data/spam/001; ps
axuww | grep spamd ; ../spamc/spamc -F data/spamc_blank.cf -d localhost -p
42580 < data/spam/001; ps axuww | grep spamd
(fwiw you may have to "prep" the t dir with ./spamd.t first.)
Sadly there's no appreciable difference between spamd running the old way
(parsing the 600KB of config_text string in-process) or this way (parsing in a
subprocess).
top -b -n1 output --
with patch:
9910 jm 16 0 35400 32m 2376 S 0.0 3.2 0:01.84 spamd
9922 jm 18 0 35928 32m 2036 S 0.0 3.3 0:00.52 spamd
9923 jm 15 0 35400 30m 724 S 0.0 3.1 0:00.00 spamd
without:
10152 jm 16 0 35408 32m 2376 S 0.0 3.2 0:02.15 spamd
10160 jm 18 0 35916 32m 2036 S 0.0 3.2 0:00.28 spamd
10161 jm 17 0 35936 32m 2032 S 0.0 3.2 0:00.28 spamd
I think that indicates that the theory that config-parsing is memory-heavy,
causing a bloated arena full of deleted objects and scalars after it
completes, is probably not truly the case.
Maybe I've missed something, though. if anyone feels like carrying this on to a
stage where it works, feel free ;)
(note btw that this patch will cause bugs; some of the config data is not
copied over. it's just a POC.)
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.