>> 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@xxxxxxxxxxx ---- Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
