Spamd memory hawg
On 12/2/2011 2:48 AM, David Baron wrote:
> I have two spamd (owner nobody) running, likely called by procmail for spam
> detection (obviously). They are eating upwards of a half gig of memory. This
> seems quite excessive.
Hay David, you may recognize me from linux-raid and/or other lists.
The two combined may not be eating a half gig of RAM. See the
copy-on-write explanation at the following link:
Likely your SA processes are eating more like 250MB total, which to me
is still too much for simply fighting spam. For example my entire
Postfix stack with A/S countermeasures requires only ~25MB of real
memory and blocks over 97% of spam at connect or via header checks,
without ever accepting entire messages. However, I've put extensive
time/effort over the past 3-4 years into creating local block lists and
other custom (fast/resource frugal) countermeasures specifically to
avoid needing to use a full up content filter such as SA.
> Is there a way to limit them?
See same article. Killing spam connections with MTA restrictions
prevents that mail from entering SA, thus decreasing SA's load, and is a
best practice. Some such restrictions will make some SA options
redundant and you can thus remove them from SA's config, lowering its
memory footprint. You can also disable Bayes and tweak content
filtering options to lower mem use. Keep in mind that doing these
things will decrease SA's effectiveness to some degree.
If you're using Postfix 2.8+ with SA as an after queue content filter,
you can configure Postscreen to kill nearly all bot spam before it
enters SA. You can also configure DNSBL scoring/rejection in Postscreen
removing that burden from SA.
If you're using Exim/Sendmail/Qmail I'm not of much help as I've never
> BTW, they have no pid, can't kill them. Might be a memory leak. Running Sid.
Use 'pidof <process-name>' to get the PID, then 'kill -9 PID'. Or use
'killall' against the process name: http://linux.die.net/man/1/killall
If you're a Postfix user ping me off, or post a message to the
postfix-users list. There's all kinds of relatively easy tweaking,
tricks, tips, add-ons that can help kill most junk before it enters SA,
reducing that mem footprint and load.
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact firstname.lastname@example.org