I'd probably use imtest to connect, get the PID of the server process that I'm connected to, and then attach to that process with ktrace (or whatever) with timestamps enabled. Then I'd select the mailbox -- this is assuming that mutt is only issuing a select when it says "Selecting INBOX". Obviously it could be doing any number of things. You can get positive confirmation of which command is taking a long time by enabling telemetry, of course. That will tell you what kind of operation is blocking, FWIW. What you do thereafter really depends on what you find. :wes On 26 Sep 2008, at 09:44, Gary Mills wrote: > We have a moderately sized Cyrus installation with 2 TB of storage > and a few thousand simultaneous IMAP sessions. When one of the > backup processes is running during the day, there's a noticable > slowdown in IMAP client performance. When I start my `mutt' mail > reader, it pauses for several seconds at `Selecting INBOX'. That > behavior disappears when the backup finishes. > > Where's the first place to look for this problem? I/O statistics > show a higher read bandwidth while the backup is running, but writes > still dominate. The backup would typically read all of the files in > a single Cyrus partition. ---- 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
