Performance tuning

[thunder04]

More RAM is on order.

...put Amavis's tmp directory on a RAM disk...

How large of a RAM disk would you recommend? Is there an easy way to find out how much Amavis needs?

[LMStone]

More RAM is on order.



How large of a RAM disk would you recommend? Is there an easy way to find out how much Amavis needs?

Good question: "It depends."

There's a thread a few years back here where I provided the step-by step info. If you Google for "Ralf Hildebrandt's Postfix Shrine" (a terrific book on Postfix BTW), his web site has excerpts, including how to size and configure the RAM disk. Between the two you should be all set.

Hope that helps,
Mark

[thunder04]

If you Google for "Ralf Hildebrandt's Postfix Shrine" (a terrific book on Postfix BTW), his web site has excerpts, including how to size and configure the RAM disk.

I found it: Ralf Hildebrandt: Homepage

I'm looking at the formula for determining the size of the RAM disk, and one of the factors is the number of Amavis instances are spawned. How many instances of Amavis is Zimbra configured to spawn out-of-the-box?

[LMStone]

I found it: Ralf Hildebrandt: Homepage

I'm looking at the formula for determining the size of the RAM disk, and one of the factors is the number of Amavis instances are spawned. How many instances of Amavis is Zimbra configured to spawn out-of-the-box?

Zimbra spawns up to ten Amavis instances by default. You can see this in /opt/zimbra/conf/amavisd.conf.in (the master config file) and /opt/zimbra/conf/amavisd.conf (the run time file generated each time Zimbra is restarted:

viognier:~ # cat /opt/zimbra/conf/amavisd.conf | grep max_servers
$max_servers = 10;            # number of pre-forked children (2..15 is common)
viognier:~ #

In our testing with a RAM disk, an MTA-only server with ten children and four cores maxed out processed between 25,000 and 40,000 emails per hour through Amavis, so unless you have more volume than that, there is no need to increase nor decrease the number of Amavis processes from the Zimbra default.

Hope that helps,
Mark

[thunder04]

No interest in messing with the number of spawned instances, just needed to know for the RAM disk size calculation.

Thanks!

[thunder04]

Ok, so I've got the additional memory installed and am ready to create the RAM disk for Amavis. I've broken our Zimbra server enough these past few days (8.0.2 upgrade complications), so I want to avoid breaking it again.

For the RAM Disk, I'm going to add the following to /etc/fstab. This was pulled from the guide linked above. I simply replaced the mountpoint with the location of the Amavis temp directory, and adjusted the size to match my calculation (which was ~880 MB, but I added plenty of RAM so I figured it wouldn't hurt to round it to 1024 MB)

/dev/shm   /opt/zimbra/data/amavisd/tmp   tmpfs defaults,noexec,nodev,nosuid,size=1024m,mode=750,uid=7509,gid=54322 0 0

Once I've done that, I'll do:

zmmtactl stop (as Zimbra)
mount /opt/zimbra/data/amavisd/tmp (as root)
zmmtactl start (as Zimbra)

Is this correct?

[LMStone]

You are almost there!

First, the line to add to /etc/fstab looks fine, but just to double check why not run:

lmstone@viognier:~> cat /etc/passwd | grep zimbra
zimbra:x:1003:1000::/opt/zimbra:/bin/bash
lmstone@viognier:~>

In this way you can confirm that the UID:GID numbers in /etc/passwd match exactly those in /etc/fstab.

Second, there's no need to stop the whole MTA function; you can run /opt/zimbra/bin/zmamavisdctl instead. And I would confirm both the mount operation and that the zimbra user can write to the RAM disk before restarting Amavis. In summary:

/opt/zimbra/bin/zmamavisdctl stop (as zimbra)
/bin/mount -t tmpfs -o defaults,noexec,nodev,nosuid,size=1024m,mode=750,uid=7509,gid=54322 /dev/shm /opt/zimbra/data/amavisd/tmp (as root)
df -h (as root, to see that the RAM disk is mounted and sized correctly)
chown zimbra:zimbra /opt/zimbra/data/amavisd/tmp (as root)
chmod 750 /opt/zimbra/data/amavisd/tmp (as root)
touch /opt/zimbra/data/amavisd/tmp/TESTFILE (as zimbra, to confirm writeability)
rm /opt/zimbra/data/amavisd/tmp/TESTFILE (as zimbra, to clean up)
/opt/zimbra/bin/zmamavisdctl start (as zimbra)
ls -alh /opt/zimbra/data/amavisd/tmp/ (as zimbra, to confirm amavis is indeed writing to the RAM disk OK)

If the very last step completes OK and you see the Amavis temporary processing directories nested within the RAM disk tmp directory, then you are all set:

zimbra@viognier:~> df -h | grep amavis
/dev/shm              768M  888K  768M   1% /opt/zimbra/data/amavisd/tmp
zimbra@viognier:~> ls -alh /opt/zimbra/data/amavisd/tmp/
total 4.0K
drwxr-x--- 11 zimbra zimbra  220 Jan  8 12:42 .
drwxr-xr-x 10 zimbra zimbra 4.0K Dec 19 11:29 ..
drwxr-x---  3 zimbra zimbra   80 Jan  8 11:55 amavis-20130108T115521-11799
drwxr-x---  3 zimbra zimbra   80 Jan  8 12:01 amavis-20130108T120119-13873
drwxr-x---  3 zimbra zimbra   80 Jan  8 12:03 amavis-20130108T120346-17337
drwxr-x---  3 zimbra zimbra   80 Jan  8 12:06 amavis-20130108T120631-18759
drwxr-x---  3 zimbra zimbra   80 Jan  8 12:10 amavis-20130108T121022-17355
drwxr-x---  3 zimbra zimbra   80 Jan  8 12:11 amavis-20130108T121148-17020
drwxr-x---  3 zimbra zimbra   80 Jan  8 12:16 amavis-20130108T121637-21492
drwxr-x---  3 zimbra zimbra   80 Jan  8 12:22 amavis-20130108T122224-26877
drwxr-x---  3 zimbra zimbra   80 Jan  8 12:36 amavis-20130108T123641-00476
zimbra@viognier:~>

Hope that helps,
Mark

[thunder04]

Woot! Worked beautifully. Thanks!

Just out of curiosity, are there any other temp directories that Zimbra uses that may be worth mounting to a RAM disk? I'm all for anything that will minimise disk I/O.

[LMStone]

Nice! I'm glad it worked for you!

To your question, that's the only thing we put on a RAM disk. Recall that RAM disks are not persistent across reboots, nor during power failures etc.

The only reason that using a RAM disk in Amavis like is is safe is due to how Amavis processes mails and interacts with Postfix... Postfix hands off email for processing to Amavis on one port, Amavis then processes that email and hands it back to Postfix for delivery on a different port. The key is that Postfix has a multiple personality disorder, and one port has no clue what the other port is doing. Consequently, Amavis only tells the Postfix port that gave it the email in the first instance that Amavis got good delivery of that email AFTER Amavis has finished processing the email, reinjected it back into Postfix on that second port, and that Postfix on that second port has told Amavis that it received the analyzed email OK.

In that way, email is always on a hard disk, even when being processed by Amavis on the RAM disk; that's why using a RAM disk for this purpose is data-safe.

Even so, this is yet another good reason not to skimp on RAM quality for a mission-critical server!

All the best,
Mark

[thunder04]

I figured that any temporary workspace would be OK in RAM, but if Amavis is the only process that this is safe to do it with then I will accept that.

...another good reason not to skimp on RAM quality for a mission-critical server!

We (a public school district) have very limited funds and typically buy the cheapest stuff we can find as long as it matches the specs we need (and works, obviously). In terms of RAM, other than using servers that require registered ECC memory (which all of ours do), is there really a difference in RAM A vs RAM B?