>> From the earlier discussion on this topic, it sounds to me like you are >> simply pushing your available hardware too hard without further tuning. >> You mentioned using ATA-over-Ethernet storage for your mail spool. Have >> you considered putting your configdirectory files on a local hard drive >> instead of on the ATA-over-Ethernet storage? There is a *lot* of >> contention for the files in the config directory, so maybe it would be >> better to move them onto a drive separate from the mail spool. > > The machine actually doesn't have any local disks (it's booted via pxe > and the root partition is also on AoE). The directories /var/spool/imap > and /var/lib/imap are each on its own LVM logical volume. As long as both logical volumes reside on the same storage, I don't think it makes much difference on how many lv's and filesystems you spread those directories. Whenever I hear about such issues I first remember those old database gurus calling for spindles, spindles and spindles (which also meant paths in the older days when shared, intelligent storage with large caches and all that nice virtual disk stuff was rare). My still limited experience with shared storage (in my case HP EVA3000) gave me the following rules for running cyrus-imapd: 1) Try to put different kind of data (spool, meta databases) on independant storage (which means independant paths, disks, SAN controllers). For the small things like cyrus databases, putting them on separate local attached SCSI/SATA disks seems a very good idea. From what I know about AoE I think it will always suffer latency problems compared to FC or SCSI, simply because ethernet cards are not exactly designed for that kind of task. 2) If you have any kind of shared storage, make sure that a sinlge system can not bring performance down, because it will slow down other machines and also block threads/processes on the single machine. In our case with HP EVA3000 it's very important to limit FC/SCSI queuedepth, because one Linux server can otherwise saturate the EVA controllers I/O and others systems will extremly slow down accessing disks. We do that with the option "ql2xmaxqdepth=16" on the Qlogic FC adapters. It simply sets the value which can be found in /sys/block/sd?/device/queue_depth. 3) Always test performance. Never trust on simple raw speed tests, never think hardware RAID, vdisk controllers, whatever alway performs better than doing it in software. Sorry it doesn't help you much, I just tried to share some of my experiences. Simon > > I mounted /var/lib/imap/proc as a memory-based filesystem (using tmpfs), > because of the contant writes to this directory, and yesterday I tried > moving deliver.db to that directory, and creating a symlink, but it > didn't improve the situation a lot. > >> After running iostat on my cyrus partition (both config and mail spool >> are >> kept on a SAN), I'm wondering if I should separate them out as well. >> This >> sounds related to the new metapartition and metapartition_files options >> that were added in v2.3.x. >> >> Does anyone have any recommendations or guidance on this topic? > > Yes, people, please share :) > > > Thanks for the suggestions, > Andre > > ---- > 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 > ---- 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
