Upgrading from 2.2 to 2.4 (slow cyr_expire)

Jay Sekora jsekora at csail.mit.edu
Thu Oct 16 16:48:25 EDT 2014


Hi.  I recently tried to upgrade/migrate our Cyrus deployment from
2.2.13 (on Debian) to 2.4.17 (on Ubuntu 14.04).  In our environment,
user mailboxes (about 3TB of them) are on iSCSI volumes; everything else
is on local disk (which I rsync'ed).

I ran into some delays to do with the storage backend configuration, so
I didn't actually get to the point of starting imapd on the new server
until disturbingly close to the end of our announced downtime window.

When I did, I saw that imapd wasn't responding and cyr_expire was
running.  I was expecting that, but eyeballing what it was doing via
strace suggested that it would have taken *over twenty hours* to walk
all the mailboxes.  (I'm guessing that cyr_expire was doing, perhaps as
a side effect, the "full re-parse of all messages, which may take a
while" mentioned under "Upgrading from 2.4.3" at
http://cyrusimap.org/docs/cyrus-imapd/2.4.17/install-upgrade.php.)  So
we announced that we were backing out of the upgrade.

However, as I was getting ready to back out, I killed the cyr_expire by
hand, and at that point imapd started responding and I was able to log
in and see my own mail (which I know cyr_expire hadn't gotten to).  It
was a little slow to initially show my my mail, which suggests that
maybe Cyrus was running cyr_expire or its equivalent after I
authenticated and before showing my my inbox, but that led me to wonder
whether it might be safe (when we repeat the migration) to kill the
cyr_expire on initial startup so that Cyrus will start talking IMAP
right away, and run it in the background.

In case it matters, we have a bunch of emeritus users who occasionally
check their mail at our site but don't use it on a day-to-day basis, and
a bunch of users who forward their mail elsewhere and leave a copy on
our IMAP server as a backup, and a lot of our heavy users are
sophisticated enough not to leave all their mail in their inboxes so
when we open the floodgates a very large fraction of that ~3TB is not
going to be looked at immediately.

Jay




More information about the Info-cyrus mailing list