deliver.db in /dev/shm

[James E. Blair]

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:
>> Hello,
>> 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
> restart!
>
>> 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):

  https://bugzilla.andrew.cmu.edu/show_bug.cgi?id=3185

James E. Blair
Principal Email Systems Administrator
UC Berkeley - IST