painful mupdate syncs between front-ends and database server

[Wesley Craig]

On 19 Oct 2009, at 17:37, Michael Bacon wrote:
> --On October 19, 2009 2:13:03 PM -0700 Andrew Morgan <morgan at orst.edu>
> wrote:
>> What is causing a (re)sync of the frontends?  Normally this should  
>> only
>> happen when you start Cyrus on a frontend, right?
>
> I am not entirely sure.  I think what may be happening is that the  
> slave
> mupdate requests get some kind of timeout, and end up  
> disconnecting.  As
> soon as they reconnect, they want to re-sync.  I've upped the
> "mupdate_retry_timeout" to 10 minutes, so most of the time, they'll  
> only
> timeout once, then the next retry will be successful.  This solved a
> constant re-sync issue we had early on, but apparently hasn't  
> solved the
> problem entirely.

How are your frontend mupdate processes authenticating to your  
mupdate master?  And what version of Kerberos are you using  
(anticipating the answer to your first question)?  I suspect that  
you're getting a GSSAPI expired context.

> The front-ends go into a sync cycle,
> which ties up the MUPDATE server while they download the database  
> (which
> can take up over two minutes).  This causes a similar halt on  
> anything that
> was responding to a mupdate "kick" on the clients, which appears to  
> stop up
> a decent amount of inbound mail.

lmtpd on your proxies is talking directly to the mupdate master?   
It's possible for lmtpd on your proxies to only check the local  
mailboxes.db.

:wes