improving concurrency/performance

[John Madden]

> 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
jmadden at ivytech.edu