On Oct 4, 2007, at 2:41 PM, Vincent Fox wrote: > We spent some time talking to Ken & Co. at CMU on the phone > about what happens in very high loads but haven't come to a > "fix" for what happened to us. There may not be one. I can and > will describe all the nitty-gritty of that post-mortem in a post in a > day or two. One of the things Rob Banz recently did here was to move the data/ config/proc directory from a "real" fs to tmpfs. This reduces the disk IO from Cyrus process creation/management. So the way we do stuff here is that each Cyrus backend has its own ZFS pool. That zpool is divided up into four file systems: /ms1/data /ms1/mail /ms1/meta /ms1/sieve "ms1" in this case is the name of the zpool... named after the server which owns it. Additionally, we have /ms1/data/config/proc mounted as a tmpfs file system. The info in that dir does not need to persist across reboots, and every time a new Cyrus process is launched, a file (pid number) is written there and is updated with state info. This produces unnecessary disk IO, so it's better of being a in-memory filesystem, which tmpfs is. The relevant areas of our imapd.conf looks like so: configdirectory: /ms1/data/config defaultpartition: ms1 metapartition-ms1: /ms1/meta partition-ms1: /ms1/mail sievedir: /ms1/sieve /dale -- Dale Ghent Specialist, Storage and UNIX Systems UMBC - Office of Information Technology ECS 201 - x51705 ---- 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
