> 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. Using ktrace/strace may not actually be that helpful. cyrus read accesses most files via mmaped memory. The problem is that opening a file + mmaping it might be quick, but then when the process does a memory access to the mmapped region, the whole process is "put to sleep" waiting on the underlying page fault to finish doing the IO. That doesn't show up in strace/ktrace because it's just a memory access, not a system call. In general, tracing where IO bottlenecks are occuring can be quite tricky. 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
