successful create but unsuccessful subscribe
morgan at orst.edu
Wed Dec 19 16:45:36 EST 2012
On Wed, 19 Dec 2012, Frank Elsner wrote:
> On Wed, 19 Dec 2012 10:10:43 -0800 (PST) Andrew Morgan wrote:
> [ ... ]
>> I don't know why, but we have always operated with prefork=1 here. As far
>> as I can tell, it never runs more than 1 mupdate process. That single
>> mupdate process has 15 connections in total from our 3 frontend servers.
>> There doesn't seem to be a need for it to spawn additional mupdate
>> processes. Now that I look closer, I see that mupdate is threaded...
>> We have 3 frontends and 3 backends. Each backend has about 20,000 users
>> on it.
>> Here is my cyrus.conf entry on the mupdate master:
>> mupdate cmd="/usr/local/cyrus/bin/mupdate -m" listen="3905" proto="tcp4" prefork=1
>> and on the frontends:
>> mupdate cmd="/usr/local/cyrus/bin/mupdate" listen="3905" proto="tcp4" prefork=1
>> Hmm, there is no manpage for mupdate either! Digging around in the source
>> code shows that there are configuration options for mupdate in imapd.conf,
>> such as:
>> mupdate_workers_max: 50
>> The maximum number of mupdate worker threads (overall)
>> mupdate_workers_maxspare: 10
>> The maximum number of idle mupdate worker threads
>> mupdate_workers_minspare: 2
>> The minimum number of idle mupdate worker threads
>> mupdate_workers_start: 5
>> The number of mupdate worker threads to start
> Ok, sounds good. On the mupdate master we already have the mupdate_* settings.
> Shall we put mupdate_* settings into the imapd.conf on the frontends too?
I have never set those on either mupdate master or frontends, although I
have the defaults in imapd.conf commented out. At least here with our
systems, the defaults seem to be working well.
How would I know if I am reaching mupdate_workers_max? Is that logged?
More information about the Info-cyrus