[Dovecot] Corrupted index cache file and high CPU usage

[hydra]

On Thu, Dec 22, 2011 at 3:49 PM, Stan Hoeppner <stan at hardwarefreak.com>wrote:

> On 12/22/2011 8:08 AM, hydra wrote:
> > Hello Timo, thank you for the reply. I was suspecting the same. However:
> > - the machine runs under Vmware,
> > - I've tried 3 different kernel versions,
> > - I've tried 3 different SCSI controllers.
> >
> > All same results.
>
> dmesg output?  Log errors?
>

Nothing there


> Is your EXT4 filesystem on a VMFS volume or an RDM (SAN LUN)?
>

VMFS


>
>
> > On Wed, Dec 21, 2011 at 6:16 PM, Timo Sirainen <tss at iki.fi> wrote:
> >
> >> On 21.12.2011, at 18.38, hydra wrote:
>
> >> That's a kernel process..
> >>
> >>> I suspect, that this is something to do with Dovecot, because after
> >>> deleting the dovecot.index.cache file, everything went back to normal.
> >> When
> >>> this happens, I cannot unmount the drive nor a system reboot works.
>
> System (host machine) reboot, or virtual machine reboot doesn't fix the
> problem?  FYI, Linux doesn't unmount drives, it unmounts filesystems.
>
>
After the virtual machine reboot, the CPU usage is normal again, but just
until doveadm is launched again (it was run from cron). Sorry for the
partition/drive terminology mess up.



> I'd say you may have a problem with your VMFS volume or RDM, or maybe
> just your EXT4 filesystem.  Have you run an fsck on it?  What result?
>

A normal system reboot wasn't possible, because the ext4 fs wasn't
unmounted (and it wasn't possible to unmount the fs nor run sync - both
locked up) and thus I had to reboot from the vSphere Client. After the
reboot, fsck placed the fs to a consistent state, however the problem
occurred the next morning, when doveadm from the cron was run again. So a
fsck didn't help.


> Or, as Timo suggests, could be a kernel bug.  Or an interaction of these
> low level layers causing a problem.  If you can't unmount a filesystem,
> that has nothing to do with Dovecot, and points to a much larger, more
> critical, problem.
>
> Do you have this problem when booting an older kernel?  Say 2.6.32?
>  2.6.37?
>
>
The oldest available kernel is 2.6.32 so I'm going to test it.

Thank you :)


> >> That's a kernel bug..
> >>
> >> I think you're thinking it the wrong way: Dovecot isn't causing your
> >> system to break. Your system is causing Dovecot to break. Faulty
> hardware
> >> or faulty kernel.
>
> --
> Stan
>
>