> About 30% of all I/O is to mailboxes.db, most of which is read. I > haven't personally deployed a split-meta configuration, but I > understand the meta files are similarly heavy I/O concentrators. That sounds odd. Given the size and "hotness" of mailboxes.db, and in most cases the size of mailboxes.db compared to the memory your machine has, basically the OS should end up caching the entire thing in memory. If it has to keep going back to disk to get parts of it, it suggests something is wrong with the OS caching eviction policy. I wonder if it's worth setting up a separate process that just mmaps the whole file and then uses mlock() to keep the pages in memory, that should mean it removes all read IO for mailboxes.db. Rob ---- 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