[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Memory footprint of a mail server

On Tuesday 04 May 2010 23:51:24 Thomas Goirand wrote:
> Hi,
> Back when we were running Sarge, we were able to run clamav,
> spamassassin and amavis, together with apache, mysql and an ftp server,
> in just 200MB RAM and same as swap.
> Today, running Lenny, top shows us some crazy results:
> clamav: 156 MB
> amavisd-new: 80 MB per process (running 3 processes is the minimum)
> spamd: 105 MB per process (same remark)

Is that virtual or resident?  While virtual memory usage can be important, 
resident memory is a better initial measuring stick.

For my two-VPS system, I have:
exim4 -- 83M virt; 344K resident (listener; always around)
exim4 -- 83M virt; 1.7M resident (worker; not always around)
exim4 -- 83M virt; 1.7M resident (worker; not always around)
spamd -- 101M virt; 4M resident

exim4 -- 42M virt; 124K resident
clamd -- 280M virt; 159M resident
clamd -- 280M virt; 159M resident
freshclam -- 42M virt; 124K resident

You can guess why I moved clamAV to a separate system.  Upstream is fine with 
the memory footprint, so I don't expect it to go down.  Very hard to fit with 
any other services on a 256M VPS.  Also, clamAV's memory usage tends to spike 
at just the wrong times, so I do recommend isolating it.

Technically, the exim on vps2 doesn't participate in providing mail services.  
It's exim handles local delivery, doesn't listen on non-loopback interfaces, 
and, and uses vps1 (over a "private" network) as a smarthost for all non-local 

Virtual memory usage isn't a good measure by itself since virtual memory pages 
can be a) shared (but top/htop charges each process with all pages) and b) 
file-backed and never accessed.  For example, when a shared library is loaded, 
the whole .so is mapped into memory.  However, only the pages that are 
actually read by the program are read from disk and copied into RAM.

If the program loads a large library but only uses a couple of functions in 
it, the virtual memory usage of that program will greatly increase but the 
shared memory usage of that program will only increase slightly and the 
resident memory usage of that program won't change.[1]

> That makes the total amount of RAM needed to run these 3 up to something
> like 700 MB, which makes it a hard fit for smaller end VPSes.

Virtual memory usage can't simply be added like that, because part of virtual 
memory usage includes shared pages.

exim4+clamav+spamd is not confortable on a 256M vps, mainly because clamd is a 
memory "hog".  I've split them between 2 256M vpses, and it has been working 
well.  I imagine a 512M VPS could also handle it without trouble.  ClamAV is 
the biggest problem, I've seen its resident memory size exceed 250M during 

> Is there a way to improve perl apps memory footprint, so it's not a dog,
> in a more global way on the server?

Taking a lot of virtual memory means nothing.  Virtual memory addresses are 
not necessarily backed by either RAM or swap on Linux.  The resident memory of 
perl applications really shouldn't be much more (if any) than the equivalent 
C++ program using boost or the STL.

[C programs are probably a little bit of a win here, if you don't re-implement 
the garbage collection and dynamic typing of Perl.]

> Has anyone tried clamsmtp and how much RAM does
> it take (we would remove amavisd-new totally)?

If the goal is to get rid of amavisd-new, exim4-daemon-heavy has built-in 
support for virus scanning through clamav.

> How about the integration of dspam and
> clamsmtp in Debian?

I'm not sure why you need either of these programs.  exim4-daemon-heavy 
already contains support for interfacing with a number of spam/virus detection 
daemons that run on the same or different systems.
Boyd Stephen Smith Jr.           	 ,= ,-_-. =.
bss@iguanasuicide.net            	((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy 	 `-'(. .)`-'
http://iguanasuicide.net/        	     \_/

Attachment: signature.asc
Description: This is a digitally signed message part.

Reply to: