mupdate cpu, thread timeouts

[John Madden]

>> Jul  1 15:16:51 imap mupdate[18204]: Thread timed out waiting for
>> listener_lock
>> Jul  1 15:16:51 imap mupdate[18204]: Worker thread finished, for a
>> total
>> of 2 (2 spare)
>> Jul  1 15:16:52 imap mupdate[18206]: New worker thread started, for a
>> total of 3
>> Jul  1 15:16:52 imap mupdate[18206]: New worker thread started, for a
>> total of 4
>> Jul  1 15:16:52 imap mupdate[18206]: New worker thread started, for a
>> total of 5
>
> are not interesting.  I might say spurious.  They reflect that the
> mupdate on this machine starts 5 worker threads, and needs none.  These:

Oh, I only threw in the "new worker thread" messages for completeness. 
I'm concerned about the listener_lock timeouts.  mupdate is consuming an 
entire cpu at that these points in time so I assume it's a cpu usage 
thing.  (Also odd is that despite being multi-threaded, it never lands 
on the machine's second cpu.)

>> Jul  1 15:16:54 imap mupdate[18203]: unready for connections
>> Jul  1 15:16:54 imap mupdate[18203]: synchronizing mailbox list with
>> master mupdate server
>
> are the interesting messages.  It says to me that the connection to
> the mupdate master is being lost.  However, there ought to be an
> error message to that effect, which I don't see.  What's happening on
> the mupdate master?

On both the frontend and master, mupdate consumes 100% of the cpu for a 
few minutes.  I agree, it seems like the update is failing and then 
restarting.  How do I prevent that?  It went on like this for a few 
hours twice yesterday, then cleared itself up and it hasn't happened 
since.

We have been in the process of adding about 100,000 more users over the 
last few days (so 500k mailboxes).  Is it possible for a frontend to get 
out of sync with the master to the point where catch-up periods like 
this become necessary?  I thought each mailbox creation was synchronous 
across the murder so I'm thinking not, but the timing is interesting.

Can I do anything with the prefork parameter for mupdate to spread 
things out on more cpu's or increase concurrency?

>> Also during this time, mailbox changes (CREATE/etc)
>> are delayed or timeout.
>
> That's normal, as the mupdate master blocks changes while a frontend
> is synchronizing.

Ah.  Makes sense.

John




-- 
John Madden
Sr UNIX Systems Engineer
Ivy Tech Community College of Indiana
jmadden at ivytech.edu