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: vps1: 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 vps2: 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 delivery. 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 scans. > 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.