[Maia-users] lost connection after CONNECT (solved?)

[Robert LeBlanc]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Blake Hudson wrote:
> 
> I've found that above 2 amavisd processes per CPU  (sorry I forgot to
> include the per CPU qualifier in my prev. email) that each amavis
> process just slows down, so the total throughput in msg/min is the same
> whether you run half the number of amavis processes as smtpd or the
> same.

Certainly the amavisd-maia processes are many times more resource
intensive than Postfix instances, and as long as you're running at least
as many Postfix listeners as amavisd-maia listeners you shouldn't see
any loss of performance.  Going overboard with the Postfix listeners,
though, will eventually have a resource impact without further benefit,
so don't take it farther than your traffic volume requires.


> The downside is the 50MB+ of RAM each amavisd process is taking ...

This is a common observation, but it's probably not accurate.  There's a
well-known "bug" in newer Linux kernels that causes the memory
management subsystem to report shared memory in ways that are no longer
consistent with applications like 'top', such that the numbers you see
aren't necessarily correct.  See
<http://wiki.apache.org/spamassassin/TopSharedMemoryBug> for a more
detailed explanation.

This makes sense, if you think about it.  There's a large amount of code
shared by every amavisd-maia child--they all load the same set of
SpamAssassin rules, for instance, so there's no need for that to be
stored as separate copies for every child.  Likewise the amavisd-maia
code itself, and the loaded Perl modules are identical among the child
processes, so that should only need to be stored in memory once.  The
only "new" memory that each child needs is its own variable stack and
data buffers, which should be relatively small.  Yet apps like 'top'
mislead you into thinking that every child is hogging a ton of memory
because it's misreading what the memory management subsystem is telling it.


> Another thing I found is that there was very little to no improvement by
> using a RAM drive for the amavis tmp directory. In fact, there didn't
> seem to be a whole lot of disk access on a dedicated amavis scanning box
> (database and pop/imap on separate system) at all. This didn't seem to
> be hardware specific because I tried on a desktop class PC as well as a
> server with hardware RAID and both showed the same results. I imagine
> this is because the disk time spent (a few ms) pales in comparison to
> the CPU time spent (a few seconds) processing a message.

You're right about that last point--the disk accesses involved in
processing a mail item are relatively small compared to the time spent
with CPU processing and waiting on network tests to complete.  In part,
though, this is assisted by disk and filesystem caching, so depending on
the sizes of your read and write caches and DMA mode you may not be
hitting the disk more than once, in which case a ramdisk is of little
benefit--you've effectively /got/ one in the form of those caches.  On
slower filesystems without caching, and with older drives with poor
access times and throughput, though, a ramdisk can make a significant
improvement.

In short, it's mainly a benefit for people using older hardware, which
is sadly quite common--a lot of people seem to "repurpose" an aging
machine as a mail filtering box, not realizing the strain this sort of
application is going to visit upon that hardware :(


> I found the best way to scale amavis is to reduce scanning (by adjusting
> spamassassin rules), increase the CPU speed, and increasing the number
> of cores (or machines) available. Memory, disk, and number of processes
> did not seem to be a concern. However, for your database server (or if
> you house the database on the same system as your scanners) it would
> certainly make sense to focus on memory and disk subsystems as much as
> CPU since I/O is more of a performance concern for this function.

Good observations, certainly, particularly for those Maia users who have
enough traffic to warrant a distributed arrangement like yours.  Most
Maia users, though, seem to run everything on one box, so all of those
recommendations need to apply in their case.

- --
Robert LeBlanc <rjl at renaissoft.com>
Renaissoft, Inc.
Maia Mailguard <http://www.maiamailguard.com/>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQFGu3+7GmqOER2NHewRAhKmAJwKViWai9S6DrDz6Zt7DfbhCI4cegCeKlzP
dkyBCn06xBL7C3wMRHZldP4=
=YqBS
-----END PGP SIGNATURE-----