lookup-domain-daemon.pl memory usage

I run a small server (256mb vps in this case). The largest memory usage is the lookup-domain-daemon.pl and I am curious as to what is causing this to use such large memory amounts. It shows differences from 50 to 120mb of memory usage. If you can explain this process better than the documentation, or suggest ways to reduce its memory usage, i do thank you.

lookup-domain-daemon.pl is the daemonized version of lookup-domain.pl, which is a wrapper around clamscan or clamdscan, and spamassassin or spamc.

Mail processing, with anti-virus and spam filtering, is an extremely resource intensive task. On probably 90% of Virtualmin systems, mail processing is the most demanding task on the system. It certainly is on Virtualmin.com.

The actual lookup-domain process is not quite as resource intensive as it looks–memory usage of a specific process on a UNIX/Linux system is difficult to accurately assess, because shared libraries can lead to dramatically different real usage than appears at first glance. In the case of lookup-domain.pl it’s probably only using a third or half what it looks like it is using, because the majority of the usage is in Perl (which is shared with Webmin and Usermin, and any other Perl processes on the system, like SpamAssassin). But, nonetheless, if memory is a concern, you probably don’t want to be processing mail on your system. SpamAssassin and ClamAV are pretty much out of our control, and are both pretty big and CPU intensive (particularly ClamAV)…so there’s not a lot of advice I can offer on reducing usage. lookup-domain-daemon.pl is almost certainly not the most demanding thing on your system…it just looks that way because it is marshalling the most demanding things on your system (Clam and SpamAssassin). :wink:

Some folks with very low memory (and 256MB is right on the border of “low memory”) simply don’t process mail on their server, and instead have mail sent to GMail, or similar. I believe you can probably have a pretty close to fully functional system, including mail, in 256MB, though you’ll want to make sure you’ve followed all of the advice in the “Virtualmin on Low Memory Systems” guide in the documentation, and thought hard about what services you need and what you can get rid of.

Virtualmin’s mail processing is a wee bit more demanding than is strictly necessary because it adds several niceties that folks have asked for over the years…things like reporting, timed spam removal, per-domain spam and AV configuration, etc. All of these things add some resource usage to the mix.

If you really wanted to go as small as possible, you could disable the Virtualmin spam/AV features, and instead use a system-wide content_filter in Postfix, though the most popular of those (amavisd-new) is also pretty resource intensive. I haven’t compared the two stacks in several years (since we only use the Virtualmin mail processing stack for our systems), but the last time I did, the Virtualmin stack was smaller–but Virtualmin’s mail processing has grown dramatically in complexity and capability in that time, so it’s probably similar in size, or possibly bigger. I dunno. (And, again, remember that it’s impossible to know exactly without digging very deeply into the process table, because top is simply not an accurate picture of memory usage.)

If you receive extremely low volumes of mail (like a few per day), you may want to disable the daemon and, instead, simply use the standalone version that starts every time mail is received. In high load environments, this would use more resources, but in a light load environment, it’ll leave that memory free except when mail arrives.

Where should I look to find the options for enabling the stand alone version?