Sorry, I'm resurrecting an old thread: Bron Gondwana <brong@xxxxxxxxxxx> 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 ---- Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
