From: "John Fleming" <[EMAIL PROTECTED]>
> From: "jdow" <[EMAIL PROTECTED]>
> > From: "John Fleming" <[EMAIL PROTECTED]>
> >
> > > jdow said:
> > > > On another paw I note that most family tools are not left running
> > > > 24x7. If this is his case then a large portion of his 250 messages
> > > > may be coming in right after he boots. If he is setup to spawn
> > > > too many spamds then he could experience a memory crisis.
> > >
> > > That's not it. It's mostly a family/hobby server, but it functions
> > > "fairly professionally" - I just meant I'm not an ISP or big business
> > > with thousands of emails a day. The server's on 24/7/365 running
> > > Apache, Mailman and other common server stuff - but all at a VERY low
> > > activity/use level.
> > >
> > > I've reviewed my local.cf, and there was some duplication. I've
> > > removed the dupes and we'll see if that helps.
> > >
> > > I call spamd via spamc in procmail. I've read man spamc/d - I see
> > > where to limit the spamd children when using the spamd option, but I
> > > don't see how to pass that option on when using spamc. IOW, I don't
see
> > how
> > > to limit spamd children when using spamc.
> > >
> > > Also, my procmailrc uses a lock file when evaluating the results of
> > > spamd - I guess that doesn't limit starting another spamd before
> > > that file has been evaluated? - John
> >
> > Um, you do not limit with spamc. You simply setup the limit in spamd
when
> > you start or restart it. It is probably a good idea to play with several
> > values to see which gives you performance closest to your desired
> > performance. As soon as you get enough spamds up to trigger paging the
> > overall performance will take a serious dive. To a fairly real extent
> > a limit of two or three is probably best for single processor systems
> > modulo how much time is spent computing compared to waiting on IO for
> > any given spamd. If it is heavily compute bound 2 might be optimum.
>
> OK, I'll bare my ignorance here in hopes of enlightenment. I'm probably
> lucky that I have SA working as well as I do. I only have a loose
> understanding of the different roles of "spamassassin", "spamc", and
> "spamd". I start things with /etc/init.d/spamassassin. Then in procmail,
I
> pipe the msg to spamc. In neither of these places do I see how to pass
any
> options to spamd.
>
> I've also tried:
> # spamd -m 2
> but this gets an error about the socket being in use.
>
> What am I missing? - John
OK, from the "spamd --help" output:
-m num, --max-children num Allow maximum num children
So that option is positively "a spamd thing." So how does one get that
option into spamd? On the Mandrake test machine I have the init script
in /etc/init.d as "spamassassin". It includes these lines:
====
# Source spamd configuration.
if [ -f /etc/sysconfig/spamassassin ] ; then
. /etc/sysconfig/spamassassin
else
SPAMDOPTIONS="-d -c -m5 -Hi --user-config"
fi
[ -f /usr/bin/spamd -o -f /usr/local/bin/spamd ] || exit 0
PATH=$PATH:/usr/bin:/usr/local/bin
# See how we were called.
case "$1" in
start)
# Start daemon.
gprintf "Starting spamd: "
daemon spamd $SPAMDOPTIONS
RETVAL=$?
echo
[ $RETVAL = 0 ] && touch /var/lock/subsys/spamassassin
;;
====
The first clause sets some options either from a file in the sysconfig
directory or a default from the /etc/init.d/spamassassin file itself.
As can be seen that default includes the option "-m5". (It appears
that spamd may not be happy with the form "-m 5"?) The next clause
makes sure the /usr/bin and /usr/local/bin directories are on the
path for spamd's execution if spamd is in either of those directories.
Otherwise it leaves the PATH variable unchanged. The final clause is
the start of the case statement on the command arguments for the
/etc/init.d/spamassassin script. In the "start" argument case spamd
gets run as a daemon with the "SPAMDOPTIONS" set in the first one of
the excterpted clauses.
So basically you want to look for the location in your version of
/etc/init.d/spamassassin that holds the "spamd" starting as a daemon
instruction. Note how the parameters are assigned to it, in this case
via SPAMDOPTIONS. Look for where those parameters are assigned and
change the "-m5" (in this case) to "-m2". (Which I think I will do
with this test machine because I note it still bogs down nastily
when a collection of Linux Kernel patch files are sent to the Linux
Kernel Mailing List. That's usually a dozen to two dozen files of
varying length that hit almost all at once. With -m5 it seems the
various spamd invocations are preempting each other to death. With
-m2 there might be fewer preemptions and better overall throughput.
At least, I'm willing to try, not that the machine cracks anything
close to a serious sweat on the load I place on it, about 1000
messages a day. At that rate it's loafing for a "2GHz" Atholn with
1G of memory even with X running.
{^_^}
