deliver.db in /dev/shm
James E. Blair
jeblair at berkeley.edu
Tue Dec 22 14:17:12 EST 2009
Sorry, I'm resurrecting an old thread:
Bron Gondwana <brong at fastmail.fm> writes:
> On Tue, Sep 29, 2009 at 04:29:30PM +0200, Carles Xavier Munyoz Baldó wrote:
>> May I put the database file deliver.db in the /dev/shm partition.
>> I have disabled duplicatesuppression and I believe that I will save lot of I/O
>> requests to my hard drives if I put this file in memory.
>> I'am right?
> Not heaps really. Deliver.db IO is pretty low, and mainly affects
> lmtp processes - which aren't very time sensitive anyway.
> What you might want to do it symlink the $conf/proc directory into
> memory somewhere, because that really doesn't have to last over a
>> Which problems will I have with this file in memory?
>> I know that I will lost this database file when system reboots, but this is
>> not a problem for me.
>> Will the cyrus create a new deliver.db if it doesn't exist?
> It should be fine - except: how are you going to put it in the /dev/shm
> partition? It sits in the $conf directory, so you really need to symlink
> it out. I'm not convinced cyrus will create a new one over a symlink.
> Also, I don't know how happy BDB would be. It uses environment stuff in
> $conf/db/ as well. Skiplist would break on the first checkpoint, because
> it would create a new file in $conf/deliver.db.NEW, and then rename that
> over the symlink.
> That said - if you patched a new deliver.db location into the code, that
> would work fine!
We have duplicate suppression enabled, and we're a relatively busy
site, so our nightly cyr_expire run, which purges old entries from
deliver.db, triggers a _lot_ of write activity around that file. When
it was on our SAN, that activity was beginning to cause performance
problems (even in the wee hours of the morning).
I implemented Bron's suggestion of patching a new location for
deliver.db and put it on a Linux tmpfs. We've been running it in
production for about a month now, and we're happy with the results.
We moved proc at the same time as well (by mounting a tmpfs at
/var/lib/imap/proc, rather than symlinking the directory).
I submitted the patch to bugzilla. It adds a configuration option to
specify the location of deliver.db (if the option is omitted, the
current value -- config_dir -- is used).
Here is the bugzilla entry with the patch (against 2.3.13):
James E. Blair
Principal Email Systems Administrator
UC Berkeley - IST
More information about the Info-cyrus