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.