> As expected, these are from locking operations. 0x8 is file descriptor,
> which, if I read lsof output correctly, points to config/socket/imap-0.lock
> (what would that be?) and 0x7 is F_SETLKW which reads as "set lock or wait
> for it to be released" in the manual page.
Yup, that's exactly the sort of thing I was suspecting -- the performance I was
seeing just didn't make sense.
imap-0.lock is in /var/imap/socket for me. I believe it's one of the lock files
created when cyrus is started, so it wouldn't make any sense for imapd to ever
be
spinning on it.
The delays I was seeing ocurred when multiple imapd's were writing to the spool
at
the same time. I do see a lot of this though:
fcntl(6, F_SETLKW, {type=F_UNLCK, whence=SEEK_SET, start=0, len=0}) = 0
It looks like the lock to open a file in the target mailbox. But again, very
low
actual throughput and still little or no iowait. However, adding a -c to the
strace, the top three syscalls are:
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
52.68 0.514720 1243 414 fdatasync
29.87 0.291830 846 345 fsync
4.19 0.040898 27 1519 fcntl
Makes me wonder why the fsync's are taking so long since the disk is performing
so
well. Anyone know if that's actually typical?
Also interesting is the errors column for the open() call on this strace:
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
1.07 0.019902 17 622 130 open
Why 130 errors? I assume if there's an error that the call is re-tried...
John
--
John Madden
UNIX Systems Engineer
Ivy Tech Community College of Indiana
[EMAIL PROTECTED]
----
Cyrus Home Page: http://asg.web.cmu.edu/cyrus
Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
