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