On 17/10/2008, at 11:37 AM, MARK CALLAGHAN wrote:
> Which patch do you want?
> 1) SMP fix
> 2) configurable number of background IO threads
> 3) configurable background IO rate limit
> 4) disable Innodb malloc heap in mem/mem0pool.c
>
> For 1 -- Percona just repoted a performance regression in the Google
> code. Percona uses the Yasufumi version of faster rw-mutex that The
> Yasufumi version doesn't have that problem.
Ok good to know.
It's so much better when these things are discussed in the open
though, so that there aren't pockets of knowledge that get lost ;-)
> For 2 -- Percona uses the Yasufumi version.
I know, but all the Yasufumi patches are in their unstable build (and
so I've put them in the -Sail build for OurDelta).
They'll have had very limited exposure to the real world.
Apart from performance, how stable would you say they are?
> For 3 -- Percona has their own change or uses the Yasufumi version.
As above..
> From the description of the Percona version, the Google version might
> be more general, but I have not looked at their code. The Google
> version is in the 5.0-map launchpad branch that I publish.
Ok, how would you rate the world-readyness of that one?
> For 4 -- this is trivia to port.
>
> You might want to try to use 3.
> You should use 4.
> I think that 1 and 2 from the Google patch are redundant with
> existing Percona patches.
Ok so we need to do some mix&matching then, that's ok - thanks for the
insights!
> The regression for 1 occurs when there are many concurrent
> connections doing updates.
> We just started to look at it today.
Cool.
Apart from most of it being trivial, the individual patches still need
to go into the ourdelta tree.
And, in some cases they do need to be ported to 5.1.
Cheers,
Arjen.
--
Arjen Lentz, Director @ Open Query (http://openquery.com.au/)
Training and Expertise for MySQL in Australia and New Zealand
On 17/10/2008, at 11:37 AM, MARK CALLAGHAN wrote:
> Which patch do you want?
> 1) SMP fix
> 2) configurable number of background IO threads
> 3) configurable background IO rate limit
> 4) disable Innodb malloc heap in mem/mem0pool.c
>
> For 1 -- Percona just repoted a performance regression in the Google
> code. Percona uses the Yasufumi version of faster rw-mutex that The
> Yasufumi version doesn't have that problem.
Ok good to know.
It's so much better when these things are discussed in the open
though, so that there aren't pockets of knowledge that get lost ;-)
> For 2 -- Percona uses the Yasufumi version.
I know, but all the Yasufumi patches are in their unstable build (and
so I've put them in the -Sail build for OurDelta).
They'll have had very limited exposure to the real world.
Apart from performance, how stable would you say they are?
> For 3 -- Percona has their own change or uses the Yasufumi version.
As above..
> From the description of the Percona version, the Google version might
> be more general, but I have not looked at their code. The Google
> version is in the 5.0-map launchpad branch that I publish.
Ok, how would you rate the world-readyness of that one?
Link for ref: https:/ /code.launchpad .net/~mdcallag
> For 4 -- this is trivia to port.
>
> You might want to try to use 3.
> You should use 4.
> I think that 1 and 2 from the Google patch are redundant with
> existing Percona patches.
Ok so we need to do some mix&matching then, that's ok - thanks for the
insights!
> The regression for 1 occurs when there are many concurrent
> connections doing updates.
> We just started to look at it today.
Cool.
Apart from most of it being trivial, the individual patches still need
to go into the ourdelta tree.
And, in some cases they do need to be ported to 5.1.
Cheers, openquery. com.au/)
Arjen.
--
Arjen Lentz, Director @ Open Query (http://
Training and Expertise for MySQL in Australia and New Zealand
OurDelta: free enhanced builds for MySQL @ http:// ourdelta. org/