On Fri, 30 Oct 2009, Michael Bacon wrote:
> On all systems in the murder, we'll see instances where the mupdate
> process goes into a spin where, in truss, it's an endless repeat of
> fcntl, stat, fstat, fcntl, thousands of times over. These execute
> extremely quickly, but I do wonder if we'r
On Fri, Oct 30, 2009 at 03:24:25PM -0400, Michael Bacon wrote:
> I haven't had the guts to roll the patched, CVS version into
> production as our primary mupdate server, but I did put it in on a
> test machine in replica mode. My measurement was on a clean server
> (no pre-existing mailboxes.db),
--On October 20, 2009 12:13:05 PM +0200 Cyril Servant
wrote:
> Hello,
>
> Here we had a similar situation : more than a million mailboxes, and
> each MUPDATE sync was very long (when it succeeded). Now, we
> bypass the problem : we get rid of the MUPDATE (and the skiplist
> mailboxes.db). We
--On October 19, 2009 9:37:57 PM -0400 Wesley Craig wrote:
> 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.
I apologize for not responding sooner here. I've had my head down in the
code and doing some tests, including playing with Bron's patch here.
I haven't had the guts to roll the patched, CVS version into production as
our primary mupdate server, but I did put it in on a test machine in
replica
Hello,
2009/10/19 Michael Bacon :
> Hello, list,
>
> Today we're enjoying our first full work day of independence from the old
> monolithic cyrus server installed in 1999 (Sun 6800 -- it's had new CPU
> boards since then, but that's it), and on our new shiny cluster of T5220's
> that are mostly ha
On Mon, 19 Oct 2009 16:38 -0400, "Michael Bacon" wrote:
> When we spec'ed out our servers, we didn't put much I/O capacity into the
> front-end servers -- just a pair of mirrored 10k disks doing the OS, the
> logging, the mailboxes.db, and all the webmail action going on in another
> solaris
On 19 Oct 2009, at 17:37, Michael Bacon wrote:
> --On October 19, 2009 2:13:03 PM -0700 Andrew Morgan
> 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 happe
On Mon, 19 Oct 2009, Michael Bacon wrote:
> --On October 19, 2009 2:13:03 PM -0700 Andrew Morgan 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 t
On Monday 19 October 2009 @ 16:38, Michael Bacon wrote:
>
> I say mostly because while most of the times the thing handles our
> 80,000 users and 14,000+ simultaneous connections like a champ,
> some of the time, we get some extreme pain, mostly due to syncs
> between the MUPDATE master and the fr
--On October 19, 2009 2:13:03 PM -0700 Andrew Morgan
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 t
On Mon, 19 Oct 2009, Michael Bacon wrote:
> Hello, list,
>
> Today we're enjoying our first full work day of independence from the old
> monolithic cyrus server installed in 1999 (Sun 6800 -- it's had new CPU
> boards since then, but that's it), and on our new shiny cluster of T5220's
> that are m
On 19/10/09 16:38 -0400, Michael Bacon wrote:
>I say mostly because while most of the times the thing handles our 80,000
>users and 14,000+ simultaneous connections like a champ, some of the time,
>we get some extreme pain, mostly due to syncs between the MUPDATE master
>and the front-end server
13 matches
Mail list logo
