dovecot - Mar 2009 - High load/corrupted indexes after moving mailboxes?

Hello,

we're experiencing an odd issue after combining two vDisks used for mail
storage into one big new LVM. We've done this in the past successfully and
didn't experience a lot of problems. We
stopped all services (dovecot/postfix) to ensure that mailbox contents
(Maildir)
will not be changed, rsynch'ed the mail to the new disks and restarted
everything.

When we restarted dovecot, we noticed a huge spike in load (average load
in top and
high cpu iowait) and isolated dovecot as the issue. At some point, the
average load
crept up to over 100 and crashed the server twice. However, over time the
average
load and cpu wait times went down slightly. I have noticed a spike in load
after moving
user's mail storage, but not like this. It almost looks like everyone is
either
re-indexing or re-caching their mail?

Any help would be appreciated. We're on dovecot 0.99.

-Pat

On Wed, 2009-03-11 at 19:15 -0400, Patrick A. Treptau
wrote:
> Hello,
> 
> we're experiencing an odd issue after combining two vDisks used for
mail
> storage into one big new LVM. We've done this in the past successfully
and
> didn't experience a lot of problems. We
> stopped all services (dovecot/postfix) to ensure that mailbox contents
> (Maildir)
> will not be changed, rsynch'ed the mail to the new disks and restarted
> everything.
> 
> When we restarted dovecot, we noticed a huge spike in load (average load
> in top and
> high cpu iowait) and isolated dovecot as the issue. At some point, the
> average load
> crept up to over 100 and crashed the server twice. However, over time the
> average
> load and cpu wait times went down slightly. I have noticed a spike in load
> after moving
> user's mail storage, but not like this. It almost looks like everyone
is
> either
> re-indexing or re-caching their mail?
> 
> Any help would be appreciated. We're on dovecot 0.99.
I don't say this lightly - upgrade.  Personally I HATE that answer, I'm
a "If it ain't broke don't fix it" person, but I've seen
so many
improvements to the backend and indexing systems this looks like it's an
appropriate answer for you.

Rick

on 3-11-2009 4:15 PM Patrick A. Treptau spake the
following:
> Hello,
> 
> we're experiencing an odd issue after combining two vDisks used for
mail
> storage into one big new LVM. We've done this in the past successfully
and
> didn't experience a lot of problems. We
> stopped all services (dovecot/postfix) to ensure that mailbox contents
> (Maildir)
> will not be changed, rsynch'ed the mail to the new disks and restarted
> everything.
> 
> When we restarted dovecot, we noticed a huge spike in load (average load
> in top and
> high cpu iowait) and isolated dovecot as the issue. At some point, the
> average load
> crept up to over 100 and crashed the server twice. However, over time the
> average
> load and cpu wait times went down slightly. I have noticed a spike in load
> after moving
> user's mail storage, but not like this. It almost looks like everyone
is
> either
> re-indexing or re-caching their mail?
> 
> Any help would be appreciated. We're on dovecot 0.99.
> 
> -Pat
> 
> 
> 
> 
I would seriously consider upgrading 0.99. Although it was a HUGE improvement
over UWimap, the newer versions run circles around it. Even a move to one of
the 1.0 stables will show major improvements, 1.1 even more, and I am sure the
new 1.2 base in beta will do it again.

I know that it is what came with your distro, but it is not the best choice
for a big mail user. I think that the biggest reason that many of the older
distros haven't pushed an upgrade is the config file changes that came in
the
newer versions, not because 0.99 is better.

-- 
MailScanner is like deodorant...
You hope everybody uses it, and
you notice quickly if they don't!!!!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 258 bytes
Desc: OpenPGP digital signature
URL:
<http://dovecot.org/pipermail/dovecot/attachments/20090312/1f8cfb23/attachment-0002.bin>