[LMStone]

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.