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,
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?
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.Code:viognier:~ # cat /opt/zimbra/conf/amavisd.conf | grep max_servers $max_servers = 10; # number of pre-forked children (2..15 is common) viognier:~ #
Hope that helps,
No interest in messing with the number of spawned instances, just needed to know for the RAM disk size calculation.
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)
Once I've done that, I'll do:Code:/dev/shm /opt/zimbra/data/amavisd/tmp tmpfs defaults,noexec,nodev,nosuid,size=1024m,mode=750,uid=7509,gid=54322 0 0
Is this correct?Code:zmmtactl stop (as Zimbra) mount /opt/zimbra/data/amavisd/tmp (as root) zmmtactl start (as Zimbra)
You are almost there!
First, the line to add to /etc/fstab looks fine, but just to double check why not run:
In this way you can confirm that the UID:GID numbers in /etc/passwd match exactly those in /etc/fstab.Code:lmstone@viognier:~> cat /etc/passwd | grep zimbra zimbra:x:1003:1000::/opt/zimbra:/bin/bash lmstone@viognier:~>
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:
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:Code:/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)
Hope that helps,Code: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:~>
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.
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,
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.