Zimbra

LMStone · #1 (**permalink**) 07-06-2007, 08:45 AM

A number of Zimbra versions ago, Zimbra used to configure Amavis's temporary directory to run on a RAM disk. Since Amavis doesn't always clean up its temporary directory well, in some installations the RAM disk would fill up and Amavis would stop working. So, Zimbra changed the install scripts going forward by removing the code that set this up.

The Book of Postfix (No Starch Press) and many other Postfix docs point out that running Amavis's temp folder on a RAM disk is actually quite safe. When Postfix hands off an email to Amavis for processing, Amavis does not actually acknowledge receiving the email from Postfix until Amavis has finished processing the email and successfully reinjected it back into Postfix. As a result, you could pull the power plug on the server and not lose any email by running Amavis's temp directory on a RAM disk. (You might hose your server for other reasons there Sparky, but not from running Amavis's temp directory on a RAM disk.)

The key benefit to running Amavis's temp directory in a RAM disk is performance. Processing by clamav, spamassassin (and Razor, Pyzor, DSpam or whatever else an admin has hacked Zimbra's Amavis to use) is very disk intensive.

So, if you have a Zimbra server with a lot of RAM and a growing number of active users, mounting /opt/zimbra/amavisd/tmp on a RAM disk is a simple way to claw back disk idle times and some increased performance.

We've been watching /opt/zimbra/amavisd/tmp since 4.5.3, and have not noticed any "orphaned" Amavis temp files like we saw in the 4.0 series, so we are asking if in Zimbra's opinion if they are OK with us putting /opt/zimbra/amavisd/tmp back on a RAM disk--understanding of course that this may not be a fully supported installation.

To create a 200MB RAM disk, we would:

1. zmcontrol stop
2. rm -R /opt/zimbra/amavisd/tmp/
3. add the following line to /etc/fstab:
/dev/shm /opt/zimbra/amavisd/tmp tmpfs defaults,size=200m,mode=700,uid=1003,gid=1000 0 0
4. reboot

(Note that the uid and gid above are the user id and group id for the 'zimbra' user and group, respectively and will likely have different values on different installations.)

Comments please!

Thanks!
Mark

jrefl5 · #2 (**permalink**) 09-04-2008, 01:41 PM

Quote:

Originally Posted by LMStone

To create a 200MB RAM disk, we would:

1. zmcontrol stop
2. rm -R /opt/zimbra/amavisd/tmp/
3. add the following line to /etc/fstab:
/dev/shm /opt/zimbra/amavisd/tmp tmpfs defaults,size=200m,mode=700,uid=1003,gid=1000 0 0
4. reboot

(Note that the uid and gid above are the user id and group id for the 'zimbra' user and group, respectively and will likely have different values on different installations.)

Comments please!

Thanks!
Mark

Mark,
Its been a while since you posted this, have you implemented it?

I would like to reduce disk I/O on my system and this should have an impact.

Thanks James

LMStone · #3 (**permalink**) 09-04-2008, 02:46 PM

Hi James,

We have implemented it on several Zimbra boxes now for quite a while.

The trick is to size the RAM disk big enough, and that is dependent upon the maximum file size you allow in Zimbra.

Amavis expands zip files to take a look at the contents therein, so if you allow 20MB maximum attachment sizes, the contents of a 20MB zip file might expand to 60MB or more. You've got ten amavis workers running simultaneously, so that would mean you would need a 600MB RAM disk to be (almost) absolutely sure you won't fill the RAM disk under any circumstances.

We've only seen one server fill a RAM disk, and no emails were lost.

In that situation, we did a zmamavisctl stop, unmounted the ram disk, resized it in /etc/fstab, and then remounted it and restarted amavis. No one noticed a thing.

On servers which had been running load factors of 3.5 or more, and %wa as reported by top of 25% or more, after implementing the ram disk load factors dropped to 1.25, wait states dropped to next to nothing, and users noticed a perceptible performance improvement in system responsiveness.

As always, use at your own risk, and YMMV! :-)

Hope that helps,
Mark

P.S. If you configure a BIG RAM disk, either add more RAM to the box or reduce the percentages of memory used by Jetty and MySQL, or you may find the system will start swapping.