Performance issues with Cyrus v2.1.12 on Solaris 5.8
m.rourke at unsw.edu.au
Tue May 6 23:28:18 EDT 2003
There seem to be two source of delay that I am seeing:
- unfortunate placement of all the seen files in a single directory
(fixed by --enable-fulldirhash)
- seen file is replaced on every mailbox access (i.e. a new file is
created and a rename occurs)
The later seems unfortunate. Rename is not a cheap operation compared to
rewriting. The truss results are now:
(everything else less than 0.01s)
The fdsync occurs just before the rename, and is also costly (and
The old seen_local.c code avoided recreating the file every time, but
the newer seen_db.c (using cyrusdb_flat) doesn't.
Because of this behaviour my IMAP read benchmarks are still 10% slower
on Cyrus 2.1.12 compared to Cyrus 1.6.24, despite the faster authentication.
Changing seen_db to db3 may help - but this shouldn't be necessary. Are
you saying I can use skiplist for this file too? Are there tools that
help the conversion?
Rob Siemborski wrote:
>On Tue, 6 May 2003, Michael Rourke wrote:
>>Following your advice, I used truss, and examined the duration of the
>>system calls occurring during the SELECT "INBOX" command. Averaging over
>>the 370 sessions that occurred in two minutes these are the top average
>>system call execution times:
>I was more hoping for actual truss output, but with times like this that
>probably wouldn't have been terribly enlightening.
>>The slow renames are typically:
>>rename <configdir>/user/t/<user>.seen.NEW <configdir>/user/t/<user>.seen
>I take it your seen DB is still a flat file? You should seriously
>consider converting both it and your mailbox list to skiplist. This
>removes the need to rewrite the entire file for each update.
>>As all my test user names (all 9999 of them) start with the letter "t",
>>the contention for the directory <configdir>/user/t is the most obvious
>>problem. With the old Cyrus version the .seen files were in <partition>.
>>--enable-fulldirhash should help with this problem.... but this will
>>make upgrading interesting as things like sieve and subs_db files will
>>need rehashing... and complicates the ability to roll-back too.
>Its not as interesting as you might expect. rehash can handle both
>upgrading and reverting.
>Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456
>Research Systems Programmer * /usr/contributed Gatekeeper
Michael Rourke, Network Services Developer, +61 2 9385 1137
Enterprise IT Infrastructure Unit, University of New South Wales
More information about the Info-cyrus