[Dovecot] Load spikes on NFS server, multiple index updaters.

[Jorgen Lundman]

Timo Sirainen wrote:
> Are these old files, or why don't they contain the ,S=1234 in filename? 
> That would help a lot when recaculating Maildir++ quota.

Ah legacy reasons :) We used to use UFS (with quotas) inside zvol on the 
zfs server. But this panics, and has performance issues.

We changed to plain zfs (without quotas) and enabled 
soft-quotas/Maildir++.  So yes, some mails are so old that they do not 
contain ,S=1234.  All new mail does:

-rw-------   1 5091     mail    1676 Aug 26 12:31 
1251257478.M554367P15043.vmx05.unix,S=1676,W=1711
-rw-------   1 5091     mail    1674 Aug 26 12:33 
1251257579.M948723P22818.vmx04.unix,S=1674,W=1709


> But Maildir++ quota is supposed to work without locks.. :)

Sure, but 20 processes all scanning the same directory, over 12 servers, 
is unpleasant. :)


> Do you need Maildir++ quota at all? With v1.2 you could use dict quota 
> with file backend. It'll use dovecot.index.cache when recalculating 
> quota, although it doesn't do that unless the quota is lost for some 
> reason (so about never).

We only needed a temporary solution. Long term, we have already tested 
ZFS's user-quota, and this is where we will go. Getting enough momentum 
to get the process started (management...) is what has been frustrating. 
Would you say this trouble is soft-quotas scanning, and not just generic 
index rebuild?

The reason I ask is that; if it is related to quotas, that gives me 
yet-another reason to move to zfs quotas (and the trouble will go away). 
If it is normal index rebuilding, it will still happen even after using 
ZFS quotas.

Thanks for your reply though,

Lund

-- 
Jorgen Lundman       | <lundman at lundman.net>
Unix Administrator   | +81 (0)3 -5456-2687 ext 1017 (work)
Shibuya-ku, Tokyo    | +81 (0)90-5578-8500          (cell)
Japan                | +81 (0)3 -3375-1767          (home)