On Saturday November 18 2006 02:05, Matt Kettler wrote:
> I also expect a lot of the memory usage is the annotation tables and
> such for regexes. It would be interesting to compare the size of spamd
> without any rules loaded against one with a stock ruleset. The
> difference between the two can't really be improved by any means other
> than using a slower regex interpreter that doesn't use tables as
> extensively.
It just happens I measured memory sizes a couple of days ago.
This was with amavisd-new, but should not be much different than
spamd, except for somewhat smaller daemon main program in clamd.
Here it goes...
From: Mark Martinec <[EMAIL PROTECTED]>
To: amavis-user@lists.sourceforge.net
Date: Thu, 16 Nov 2006 19:06:00 +0100
Subject: Re: [AMaViS-user] Forward mail directly to an MDA
> >> How limited is the RAM?
> > 64MB PC100 SDRAM currently.
> >
> > I'll try that out. If the box runs out of RAM I'll simply buy some more.
> > Those old DIMMs are not very expensive anymore.
>
> If the machine architecture will allow it, you really need to.
> Performance goes through the floor when you start swap thrashing.
> A message that might normally take 50 seconds to process could end
> up timing out instead, ending up in the deferred queue, only to
> have the same thing happen again. If it's an old machine, you will
> probably need low density (16 chip) DIMMs. An additional 128MB might
> get you closer to a functional system.
I collected some figures, concentrating on low memory usage.
All this with amavisd-new-2.4.4, SA 3.1.7, perl 5.8.8 on FreeBSD,
although it should pretty much apply to nearby versions.
VSZ
--------
2.6 MB bare-bones Perl (interactive, no program);
18.9 MB (increase by 16.3 - basic amavisd)
as above + running amavisd with AV i/f,
with disabled decoders ($bypass_decode_parts=1),
disabled cache and nanny db ($enable_db=0),
and disabled SA: @bypass_spam_checks_maps=(1);
38.3 MB (increase by 19.4 - barebones SA code)
as above + SA standard code, NO RULES;
45.5 MB (increase by 7.2 - standard SA rules)
as above + standard SA 3.1.7 rules updated with sa-update;
120 MB (increase by 75 - de-luxe SA rules and plugins)
as above + mid-range SARE rules, FuzzyOCR,
[EMAIL PROTECTED], Razor2, ...
The shown figure is virtual memory size per amavisd process.
Resident memory size depends on how tight memory is,
but could go down to maybe 60% of VSZ if truly necessary.
In anticipated setup with clamd and SA, I suggest shedding
decoders (ClamAV can do most decoding) which saves about 3.1 MB,
and BarkeleyDB cache+nanny+statistics, which saves about 2.6 MB.
With little memory one can not afford more than one or perhaps
two amavisd processes. The pre-forking environment becomes
pretty much useless, as you always pay the memory footprint price
for one parent process. It is possible to tell Net::Server to
do it all with only one process, no forking. To do so, find
the following two lines in file amavisd:
# @ISA = qw(Net::Server);
@ISA = qw(Net::Server::PreForkSimple);
and swap the commenting-out:
@ISA = qw(Net::Server);
# @ISA = qw(Net::Server::PreForkSimple);
This yields exactly one amavisd process, regardless of the
$max_servers setting (which makes it suitable also for hardcore
debugging). Make sure to adjust the maxproc in Postfix master.cf
to 1 for a smtp service that feeds mail to amavisd (README.postfix).
This hasn't been tested extensively, but appears to work.
(I'm not sure what happens after $max_requests tasks,
just in case set it to a high value).
So I would think it is possible to run on a 64 MB host
one amavisd process (no pre-forking), with all standard
SA rules and network tests (possibly with Bayes, I'm not sure),
clamd, Postfix and a basic Unix OS.
128 MB would be more advisable, and 256 MB can get quite
comfortable with two amavisd processes and some SARE rules,
and there would even be room for X11 and emacs.
Running the whole setup on a virtual host (qemu or some virtualizer)
can make adjusting memory size very easy, so it may be worth
trying the setup on a virtual host first.
Mark
