On Tue, 2007-03-20 at 10:29 +0800, Zhang, Yanmin wrote:
> On Wed, 2007-03-14 at 16:33 -0700, Siddha, Suresh B wrote:
> > On Tue, Mar 13, 2007 at 05:08:59AM -0700, Nick Piggin wrote:
> > > I would agree that it points to MySQL scalability issues, however the
> > > fact that such large gains come
On Tue, 2007-03-20 at 10:29 +0800, Zhang, Yanmin wrote:
On Wed, 2007-03-14 at 16:33 -0700, Siddha, Suresh B wrote:
On Tue, Mar 13, 2007 at 05:08:59AM -0700, Nick Piggin wrote:
I would agree that it points to MySQL scalability issues, however the
fact that such large gains come from
On Wed, 2007-03-14 at 16:33 -0700, Siddha, Suresh B wrote:
> On Tue, Mar 13, 2007 at 05:08:59AM -0700, Nick Piggin wrote:
> > I would agree that it points to MySQL scalability issues, however the
> > fact that such large gains come from tcmalloc is still interesting.
>
> What glibc version are
On Wed, 2007-03-14 at 16:33 -0700, Siddha, Suresh B wrote:
On Tue, Mar 13, 2007 at 05:08:59AM -0700, Nick Piggin wrote:
I would agree that it points to MySQL scalability issues, however the
fact that such large gains come from tcmalloc is still interesting.
What glibc version are you,
On Tue, Mar 13, 2007 at 05:08:59AM -0700, Nick Piggin wrote:
> I would agree that it points to MySQL scalability issues, however the
> fact that such large gains come from tcmalloc is still interesting.
What glibc version are you, Anton and others are using?
Does that version has this fix
On Tue, Mar 13, 2007 at 05:08:59AM -0700, Nick Piggin wrote:
I would agree that it points to MySQL scalability issues, however the
fact that such large gains come from tcmalloc is still interesting.
What glibc version are you, Anton and others are using?
Does that version has this fix
On 3/13/07, Eric Dumazet <[EMAIL PROTECTED]> wrote:
Nish Aravamudan a écrit :
> On 3/12/07, Anton Blanchard <[EMAIL PROTECTED]> wrote:
>>
>> Hi Nick,
>>
>> > Anyway, I'll keep experimenting. If anyone from MySQL wants to help
>> look
>> > at this, send me a mail (eg. especially with the
Nish Aravamudan a écrit :
On 3/12/07, Anton Blanchard <[EMAIL PROTECTED]> wrote:
Hi Nick,
> Anyway, I'll keep experimenting. If anyone from MySQL wants to help
look
> at this, send me a mail (eg. especially with the sched_setscheduler
issue,
> you might be able to do something better).
I
On 3/12/07, Anton Blanchard <[EMAIL PROTECTED]> wrote:
Hi Nick,
> Anyway, I'll keep experimenting. If anyone from MySQL wants to help look
> at this, send me a mail (eg. especially with the sched_setscheduler issue,
> you might be able to do something better).
I took a look at this today and
On Tue, Mar 13, 2007 at 01:02:44PM +0100, Eric Dumazet wrote:
> On Tuesday 13 March 2007 12:42, Andrea Arcangeli wrote:
>
> > My wild guess is that they're allocating memory after taking
> > futexes. If they do, something like this will happen:
> >
> > taskA taskB taskC
>
Andrea Arcangeli wrote:
On Tue, Mar 13, 2007 at 10:12:19PM +1100, Nick Piggin wrote:
They'll be sleeping in futex_wait in the kernel, I think. One thread
will hold the critical mutex, some will be off doing their own thing,
but importantly there will be many sleeping for the mutex to become
On Tuesday 13 March 2007 12:42, Andrea Arcangeli wrote:
> My wild guess is that they're allocating memory after taking
> futexes. If they do, something like this will happen:
>
> taskAtaskB taskC
> user lock
> mmap_sem lock
> mmap sem ->
Eric Dumazet wrote:
On Tuesday 13 March 2007 12:12, Nick Piggin wrote:
I guess googlemalloc (tcmalloc?) isn't suitable for a general purpose
glibc allocator. But I wonder if there are other improvements that glibc
can do here?
I cooked a patch some time ago to speedup threaded apps and got
On Tue, Mar 13, 2007 at 10:12:19PM +1100, Nick Piggin wrote:
> They'll be sleeping in futex_wait in the kernel, I think. One thread
> will hold the critical mutex, some will be off doing their own thing,
> but importantly there will be many sleeping for the mutex to become
> available.
The
On Tuesday 13 March 2007 12:12, Nick Piggin wrote:
>
> I guess googlemalloc (tcmalloc?) isn't suitable for a general purpose
> glibc allocator. But I wonder if there are other improvements that glibc
> can do here?
I cooked a patch some time ago to speedup threaded apps and got no feedback.
Andrea Arcangeli wrote:
On Tue, Mar 13, 2007 at 09:37:54PM +1100, Nick Piggin wrote:
Well it wasn't iowait time. From Anton's analysis, I would probably
say it was time waiting for either the glibc malloc mutex or MySQL
heap mutex.
So it again makes little sense to me that this is idle
On Tue, Mar 13, 2007 at 09:37:54PM +1100, Nick Piggin wrote:
> Well it wasn't iowait time. From Anton's analysis, I would probably
> say it was time waiting for either the glibc malloc mutex or MySQL
> heap mutex.
So it again makes little sense to me that this is idle time, unless
some userland
Andrea Arcangeli wrote:
On Tue, Mar 13, 2007 at 09:06:14PM +1100, Nick Piggin wrote:
Well ignoring the HT issue, I was seeing lots of idle time simply
because userspace could not keep up enough load to the scheduler.
There simply were fewer runnable tasks than CPU cores.
When you said idle
On Tue, Mar 13, 2007 at 09:06:14PM +1100, Nick Piggin wrote:
> Well ignoring the HT issue, I was seeing lots of idle time simply
> because userspace could not keep up enough load to the scheduler.
> There simply were fewer runnable tasks than CPU cores.
When you said idle I thought idle and not
Andrea Arcangeli wrote:
On Tue, Mar 13, 2007 at 04:11:02PM +1100, Nick Piggin wrote:
Hi Anton,
Very cool. Yeah I had come to the conclusion that it wasn't a kernel
issue, and basically was afraid to look into userspace ;)
btw, regardless of what glibc is doing, still the cpu shouldn't go
On Tue, Mar 13, 2007 at 04:11:02PM +1100, Nick Piggin wrote:
> Hi Anton,
>
> Very cool. Yeah I had come to the conclusion that it wasn't a kernel
> issue, and basically was afraid to look into userspace ;)
btw, regardless of what glibc is doing, still the cpu shouldn't go
idle IMHO. Even if
On Tue, Mar 13, 2007 at 04:11:02PM +1100, Nick Piggin wrote:
Hi Anton,
Very cool. Yeah I had come to the conclusion that it wasn't a kernel
issue, and basically was afraid to look into userspace ;)
btw, regardless of what glibc is doing, still the cpu shouldn't go
idle IMHO. Even if we're
Andrea Arcangeli wrote:
On Tue, Mar 13, 2007 at 04:11:02PM +1100, Nick Piggin wrote:
Hi Anton,
Very cool. Yeah I had come to the conclusion that it wasn't a kernel
issue, and basically was afraid to look into userspace ;)
btw, regardless of what glibc is doing, still the cpu shouldn't go
On Tue, Mar 13, 2007 at 09:06:14PM +1100, Nick Piggin wrote:
Well ignoring the HT issue, I was seeing lots of idle time simply
because userspace could not keep up enough load to the scheduler.
There simply were fewer runnable tasks than CPU cores.
When you said idle I thought idle and not
Andrea Arcangeli wrote:
On Tue, Mar 13, 2007 at 09:06:14PM +1100, Nick Piggin wrote:
Well ignoring the HT issue, I was seeing lots of idle time simply
because userspace could not keep up enough load to the scheduler.
There simply were fewer runnable tasks than CPU cores.
When you said idle
On Tue, Mar 13, 2007 at 09:37:54PM +1100, Nick Piggin wrote:
Well it wasn't iowait time. From Anton's analysis, I would probably
say it was time waiting for either the glibc malloc mutex or MySQL
heap mutex.
So it again makes little sense to me that this is idle time, unless
some userland
Andrea Arcangeli wrote:
On Tue, Mar 13, 2007 at 09:37:54PM +1100, Nick Piggin wrote:
Well it wasn't iowait time. From Anton's analysis, I would probably
say it was time waiting for either the glibc malloc mutex or MySQL
heap mutex.
So it again makes little sense to me that this is idle
On Tuesday 13 March 2007 12:12, Nick Piggin wrote:
I guess googlemalloc (tcmalloc?) isn't suitable for a general purpose
glibc allocator. But I wonder if there are other improvements that glibc
can do here?
I cooked a patch some time ago to speedup threaded apps and got no feedback.
On Tue, Mar 13, 2007 at 10:12:19PM +1100, Nick Piggin wrote:
They'll be sleeping in futex_wait in the kernel, I think. One thread
will hold the critical mutex, some will be off doing their own thing,
but importantly there will be many sleeping for the mutex to become
available.
The initial
Eric Dumazet wrote:
On Tuesday 13 March 2007 12:12, Nick Piggin wrote:
I guess googlemalloc (tcmalloc?) isn't suitable for a general purpose
glibc allocator. But I wonder if there are other improvements that glibc
can do here?
I cooked a patch some time ago to speedup threaded apps and got
On Tuesday 13 March 2007 12:42, Andrea Arcangeli wrote:
My wild guess is that they're allocating memory after taking
futexes. If they do, something like this will happen:
taskAtaskB taskC
user lock
mmap_sem lock
mmap sem - schedule
Andrea Arcangeli wrote:
On Tue, Mar 13, 2007 at 10:12:19PM +1100, Nick Piggin wrote:
They'll be sleeping in futex_wait in the kernel, I think. One thread
will hold the critical mutex, some will be off doing their own thing,
but importantly there will be many sleeping for the mutex to become
On Tue, Mar 13, 2007 at 01:02:44PM +0100, Eric Dumazet wrote:
On Tuesday 13 March 2007 12:42, Andrea Arcangeli wrote:
My wild guess is that they're allocating memory after taking
futexes. If they do, something like this will happen:
taskA taskB taskC
user
On 3/12/07, Anton Blanchard [EMAIL PROTECTED] wrote:
Hi Nick,
Anyway, I'll keep experimenting. If anyone from MySQL wants to help look
at this, send me a mail (eg. especially with the sched_setscheduler issue,
you might be able to do something better).
I took a look at this today and
Nish Aravamudan a écrit :
On 3/12/07, Anton Blanchard [EMAIL PROTECTED] wrote:
Hi Nick,
Anyway, I'll keep experimenting. If anyone from MySQL wants to help
look
at this, send me a mail (eg. especially with the sched_setscheduler
issue,
you might be able to do something better).
I took
On 3/13/07, Eric Dumazet [EMAIL PROTECTED] wrote:
Nish Aravamudan a écrit :
On 3/12/07, Anton Blanchard [EMAIL PROTECTED] wrote:
Hi Nick,
Anyway, I'll keep experimenting. If anyone from MySQL wants to help
look
at this, send me a mail (eg. especially with the sched_setscheduler
issue,
Anton Blanchard a écrit :
Hi Nick,
Anyway, I'll keep experimenting. If anyone from MySQL wants to help look
at this, send me a mail (eg. especially with the sched_setscheduler issue,
you might be able to do something better).
I took a look at this today and figured Id document it:
Anton Blanchard wrote:
Hi Nick,
Anyway, I'll keep experimenting. If anyone from MySQL wants to help look
at this, send me a mail (eg. especially with the sched_setscheduler issue,
you might be able to do something better).
I took a look at this today and figured Id document it:
Hi Nick,
> Anyway, I'll keep experimenting. If anyone from MySQL wants to help look
> at this, send me a mail (eg. especially with the sched_setscheduler issue,
> you might be able to do something better).
I took a look at this today and figured Id document it:
Hi Nick,
Anyway, I'll keep experimenting. If anyone from MySQL wants to help look
at this, send me a mail (eg. especially with the sched_setscheduler issue,
you might be able to do something better).
I took a look at this today and figured Id document it:
Anton Blanchard wrote:
Hi Nick,
Anyway, I'll keep experimenting. If anyone from MySQL wants to help look
at this, send me a mail (eg. especially with the sched_setscheduler issue,
you might be able to do something better).
I took a look at this today and figured Id document it:
Anton Blanchard a écrit :
Hi Nick,
Anyway, I'll keep experimenting. If anyone from MySQL wants to help look
at this, send me a mail (eg. especially with the sched_setscheduler issue,
you might be able to do something better).
I took a look at this today and figured Id document it:
On Tue, 2007-02-27 at 20:05 +0100, Lorenzo Allegrucci wrote:
> On Tue, 2007-02-27 at 09:02 -0500, Rik van Riel wrote:
> > That still doesn't fix the potential Linux problem that this
> > benchmark identified.
> >
> > To clarify: I don't care as much about MySQL performance as
> > I care about
On Tue, 2007-02-27 at 20:05 +0100, Lorenzo Allegrucci wrote:
On Tue, 2007-02-27 at 09:02 -0500, Rik van Riel wrote:
That still doesn't fix the potential Linux problem that this
benchmark identified.
To clarify: I don't care as much about MySQL performance as
I care about identifying
On 2/27/07, Nish Aravamudan <[EMAIL PROTECTED]> wrote:
On 2/27/07, Bill Davidsen <[EMAIL PROTECTED]> wrote:
> Paulo Marques wrote:
> > Rik van Riel wrote:
> >> J.A. Magallón wrote:
> >>> [...]
> >>> Its the same to answer 4+4 queries than 8 at half the speed, isn't it ?
> >>
> >> That still
On 2/27/07, Nish Aravamudan [EMAIL PROTECTED] wrote:
On 2/27/07, Bill Davidsen [EMAIL PROTECTED] wrote:
Paulo Marques wrote:
Rik van Riel wrote:
J.A. Magallón wrote:
[...]
Its the same to answer 4+4 queries than 8 at half the speed, isn't it ?
That still doesn't fix the potential
On 2/27/07, Bill Davidsen <[EMAIL PROTECTED]> wrote:
Paulo Marques wrote:
> Rik van Riel wrote:
>> J.A. Magallón wrote:
>>> [...]
>>> Its the same to answer 4+4 queries than 8 at half the speed, isn't it ?
>>
>> That still doesn't fix the potential Linux problem that this
>> benchmark
On 2/27/07, Nick Piggin <[EMAIL PROTECTED]> wrote:
Nish Aravamudan wrote:
> On 2/26/07, Nick Piggin <[EMAIL PROTECTED]> wrote:
>
>> Rik van Riel wrote:
>> > Lorenzo Allegrucci wrote:
>> >
>> >> Hi lkml,
>> >>
>> >> according to the test below (sysbench) Linux seems to have scalability
>> >>
Nish Aravamudan wrote:
On 2/26/07, Nick Piggin <[EMAIL PROTECTED]> wrote:
Rik van Riel wrote:
> Lorenzo Allegrucci wrote:
>
>> Hi lkml,
>>
>> according to the test below (sysbench) Linux seems to have scalability
>> problems beyond 8 client threads:
>>
Paulo Marques wrote:
Rik van Riel wrote:
J.A. Magallón wrote:
[...]
Its the same to answer 4+4 queries than 8 at half the speed, isn't it ?
That still doesn't fix the potential Linux problem that this
benchmark identified.
To clarify: I don't care as much about MySQL performance as
I care
From: Robert Hancock <[EMAIL PROTECTED]>
Subject: Re: SMP performance degradation with sysbench
Date: Tue, 27 Feb 2007 18:20:25 -0600
Message-ID: <[EMAIL PROTECTED]>
> Hiro Yoshioka wrote:
> > Howdy,
> >
> > MySQL 5.0.26 had some scalability issues an
On 2/26/07, Nick Piggin <[EMAIL PROTECTED]> wrote:
Rik van Riel wrote:
> Lorenzo Allegrucci wrote:
>
>> Hi lkml,
>>
>> according to the test below (sysbench) Linux seems to have scalability
>> problems beyond 8 client threads:
>> http://jeffr-tech.livejournal.com/6268.html#cutid1
>>
Hiro Yoshioka wrote:
Howdy,
MySQL 5.0.26 had some scalability issues and it solved since 5.0.32
http://ossipedia.ipa.go.jp/capacity/EV0612260303/
(written in Japanese but you may read the graph. We compared
5.0.24 vs 5.0.32)
The following is oprofile data
==>
On 2/27/07, Paulo Marques <[EMAIL PROTECTED]> wrote:
Rik van Riel wrote:
> J.A. Magallón wrote:
>>[...]
>> Its the same to answer 4+4 queries than 8 at half the speed, isn't it ?
>
> That still doesn't fix the potential Linux problem that this
> benchmark identified.
>
> To clarify: I don't care
On Tue, 2007-02-27 at 09:02 -0500, Rik van Riel wrote:
> J.A. Magallón wrote:
> > On Mon, 26 Feb 2007 23:31:29 -0500, Rik van Riel <[EMAIL PROTECTED]> wrote:
> >
> >> Hiro Yoshioka wrote:
>
> >>> Another question. When the number of threads exceeds the number of
> >>> CPU cores, we may get a lot
Rik van Riel wrote:
J.A. Magallón wrote:
[...]
Its the same to answer 4+4 queries than 8 at half the speed, isn't it ?
That still doesn't fix the potential Linux problem that this
benchmark identified.
To clarify: I don't care as much about MySQL performance as
I care about identifying and
J.A. Magallón wrote:
On Mon, 26 Feb 2007 23:31:29 -0500, Rik van Riel <[EMAIL PROTECTED]> wrote:
Hiro Yoshioka wrote:
Another question. When the number of threads exceeds the number of
CPU cores, we may get a lot of idle time. Then a workaround of
MySQL is that do not creat threads which
On Mon, 26 Feb 2007 23:31:29 -0500, Rik van Riel <[EMAIL PROTECTED]> wrote:
> Hiro Yoshioka wrote:
> > Hi,
> >
> > From: Rik van Riel <[EMAIL PROTECTED]>
> >> Hiro Yoshioka wrote:
> >>> Howdy,
> >>>
> >>> MySQL 5.0.26 had some scalability issues and it solved since 5.0.32
> >>>
On Mon, 26 Feb 2007 23:31:29 -0500, Rik van Riel [EMAIL PROTECTED] wrote:
Hiro Yoshioka wrote:
Hi,
From: Rik van Riel [EMAIL PROTECTED]
Hiro Yoshioka wrote:
Howdy,
MySQL 5.0.26 had some scalability issues and it solved since 5.0.32
J.A. Magallón wrote:
On Mon, 26 Feb 2007 23:31:29 -0500, Rik van Riel [EMAIL PROTECTED] wrote:
Hiro Yoshioka wrote:
Another question. When the number of threads exceeds the number of
CPU cores, we may get a lot of idle time. Then a workaround of
MySQL is that do not creat threads which
Rik van Riel wrote:
J.A. Magallón wrote:
[...]
Its the same to answer 4+4 queries than 8 at half the speed, isn't it ?
That still doesn't fix the potential Linux problem that this
benchmark identified.
To clarify: I don't care as much about MySQL performance as
I care about identifying and
On Tue, 2007-02-27 at 09:02 -0500, Rik van Riel wrote:
J.A. Magallón wrote:
On Mon, 26 Feb 2007 23:31:29 -0500, Rik van Riel [EMAIL PROTECTED] wrote:
Hiro Yoshioka wrote:
Another question. When the number of threads exceeds the number of
CPU cores, we may get a lot of idle time. Then
On 2/27/07, Paulo Marques [EMAIL PROTECTED] wrote:
Rik van Riel wrote:
J.A. Magallón wrote:
[...]
Its the same to answer 4+4 queries than 8 at half the speed, isn't it ?
That still doesn't fix the potential Linux problem that this
benchmark identified.
To clarify: I don't care as much
Hiro Yoshioka wrote:
Howdy,
MySQL 5.0.26 had some scalability issues and it solved since 5.0.32
http://ossipedia.ipa.go.jp/capacity/EV0612260303/
(written in Japanese but you may read the graph. We compared
5.0.24 vs 5.0.32)
The following is oprofile data
==
On 2/26/07, Nick Piggin [EMAIL PROTECTED] wrote:
Rik van Riel wrote:
Lorenzo Allegrucci wrote:
Hi lkml,
according to the test below (sysbench) Linux seems to have scalability
problems beyond 8 client threads:
http://jeffr-tech.livejournal.com/6268.html#cutid1
From: Robert Hancock [EMAIL PROTECTED]
Subject: Re: SMP performance degradation with sysbench
Date: Tue, 27 Feb 2007 18:20:25 -0600
Message-ID: [EMAIL PROTECTED]
Hiro Yoshioka wrote:
Howdy,
MySQL 5.0.26 had some scalability issues and it solved since 5.0.32
http://ossipedia.ipa.go.jp
Paulo Marques wrote:
Rik van Riel wrote:
J.A. Magallón wrote:
[...]
Its the same to answer 4+4 queries than 8 at half the speed, isn't it ?
That still doesn't fix the potential Linux problem that this
benchmark identified.
To clarify: I don't care as much about MySQL performance as
I care
Nish Aravamudan wrote:
On 2/26/07, Nick Piggin [EMAIL PROTECTED] wrote:
Rik van Riel wrote:
Lorenzo Allegrucci wrote:
Hi lkml,
according to the test below (sysbench) Linux seems to have scalability
problems beyond 8 client threads:
http://jeffr-tech.livejournal.com/6268.html#cutid1
On 2/27/07, Nick Piggin [EMAIL PROTECTED] wrote:
Nish Aravamudan wrote:
On 2/26/07, Nick Piggin [EMAIL PROTECTED] wrote:
Rik van Riel wrote:
Lorenzo Allegrucci wrote:
Hi lkml,
according to the test below (sysbench) Linux seems to have scalability
problems beyond 8 client threads:
On 2/27/07, Bill Davidsen [EMAIL PROTECTED] wrote:
Paulo Marques wrote:
Rik van Riel wrote:
J.A. Magallón wrote:
[...]
Its the same to answer 4+4 queries than 8 at half the speed, isn't it ?
That still doesn't fix the potential Linux problem that this
benchmark identified.
To clarify: I
Hiro Yoshioka wrote:
Hi,
From: Rik van Riel <[EMAIL PROTECTED]>
Hiro Yoshioka wrote:
Howdy,
MySQL 5.0.26 had some scalability issues and it solved since 5.0.32
http://ossipedia.ipa.go.jp/capacity/EV0612260303/
(written in Japanese but you may read the graph. We compared
5.0.24 vs 5.0.32)
Hi,
From: Rik van Riel <[EMAIL PROTECTED]>
> Hiro Yoshioka wrote:
> > Howdy,
> >
> > MySQL 5.0.26 had some scalability issues and it solved since 5.0.32
> > http://ossipedia.ipa.go.jp/capacity/EV0612260303/
> > (written in Japanese but you may read the graph. We compared
> > 5.0.24 vs 5.0.32)
Hiro Yoshioka wrote:
Howdy,
MySQL 5.0.26 had some scalability issues and it solved since 5.0.32
http://ossipedia.ipa.go.jp/capacity/EV0612260303/
(written in Japanese but you may read the graph. We compared
5.0.24 vs 5.0.32)
The following is oprofile data
==>
Howdy,
MySQL 5.0.26 had some scalability issues and it solved since 5.0.32
http://ossipedia.ipa.go.jp/capacity/EV0612260303/
(written in Japanese but you may read the graph. We compared
5.0.24 vs 5.0.32)
The following is oprofile data
==>
On Mon, Feb 26, 2007 at 04:04:01PM -0600, Pete Harlan wrote:
> On Tue, Feb 27, 2007 at 12:36:04AM +1100, Nick Piggin wrote:
> > I found a couple of interesting issues so far. Firstly, the MySQL
> > version that I'm using (5.0.26-Max) is making lots of calls to
>
> FYI, MySQL fixed some
On Tue, Feb 27, 2007 at 12:36:04AM +1100, Nick Piggin wrote:
> I found a couple of interesting issues so far. Firstly, the MySQL
> version that I'm using (5.0.26-Max) is making lots of calls to
FYI, MySQL fixed some scalability problems in version 5.0.30, as
mentioned here:
Nick Piggin wrote:
Rik van Riel wrote:
Lorenzo Allegrucci wrote:
Hi lkml,
according to the test below (sysbench) Linux seems to have scalability
problems beyond 8 client threads:
http://jeffr-tech.livejournal.com/6268.html#cutid1
http://jeffr-tech.livejournal.com/5705.html
Hardware is an
Rik van Riel wrote:
Lorenzo Allegrucci wrote:
Hi lkml,
according to the test below (sysbench) Linux seems to have scalability
problems beyond 8 client threads:
http://jeffr-tech.livejournal.com/6268.html#cutid1
http://jeffr-tech.livejournal.com/5705.html
Hardware is an 8-core amd64 system and
Rik van Riel wrote:
Lorenzo Allegrucci wrote:
Hi lkml,
according to the test below (sysbench) Linux seems to have scalability
problems beyond 8 client threads:
http://jeffr-tech.livejournal.com/6268.html#cutid1
http://jeffr-tech.livejournal.com/5705.html
Hardware is an 8-core amd64 system and
Nick Piggin wrote:
Rik van Riel wrote:
Lorenzo Allegrucci wrote:
Hi lkml,
according to the test below (sysbench) Linux seems to have scalability
problems beyond 8 client threads:
http://jeffr-tech.livejournal.com/6268.html#cutid1
http://jeffr-tech.livejournal.com/5705.html
Hardware is an
On Tue, Feb 27, 2007 at 12:36:04AM +1100, Nick Piggin wrote:
I found a couple of interesting issues so far. Firstly, the MySQL
version that I'm using (5.0.26-Max) is making lots of calls to
FYI, MySQL fixed some scalability problems in version 5.0.30, as
mentioned here:
On Mon, Feb 26, 2007 at 04:04:01PM -0600, Pete Harlan wrote:
On Tue, Feb 27, 2007 at 12:36:04AM +1100, Nick Piggin wrote:
I found a couple of interesting issues so far. Firstly, the MySQL
version that I'm using (5.0.26-Max) is making lots of calls to
FYI, MySQL fixed some scalability
Howdy,
MySQL 5.0.26 had some scalability issues and it solved since 5.0.32
http://ossipedia.ipa.go.jp/capacity/EV0612260303/
(written in Japanese but you may read the graph. We compared
5.0.24 vs 5.0.32)
The following is oprofile data
==
Hiro Yoshioka wrote:
Howdy,
MySQL 5.0.26 had some scalability issues and it solved since 5.0.32
http://ossipedia.ipa.go.jp/capacity/EV0612260303/
(written in Japanese but you may read the graph. We compared
5.0.24 vs 5.0.32)
The following is oprofile data
==
Hi,
From: Rik van Riel [EMAIL PROTECTED]
Hiro Yoshioka wrote:
Howdy,
MySQL 5.0.26 had some scalability issues and it solved since 5.0.32
http://ossipedia.ipa.go.jp/capacity/EV0612260303/
(written in Japanese but you may read the graph. We compared
5.0.24 vs 5.0.32)
snip
MySQL
Hiro Yoshioka wrote:
Hi,
From: Rik van Riel [EMAIL PROTECTED]
Hiro Yoshioka wrote:
Howdy,
MySQL 5.0.26 had some scalability issues and it solved since 5.0.32
http://ossipedia.ipa.go.jp/capacity/EV0612260303/
(written in Japanese but you may read the graph. We compared
5.0.24 vs 5.0.32)
snip
Lorenzo Allegrucci wrote:
Hi lkml,
according to the test below (sysbench) Linux seems to have scalability
problems beyond 8 client threads:
http://jeffr-tech.livejournal.com/6268.html#cutid1
http://jeffr-tech.livejournal.com/5705.html
Hardware is an 8-core amd64 system and jeffr seems willing
Lorenzo Allegrucci wrote:
Hi lkml,
according to the test below (sysbench) Linux seems to have scalability
problems beyond 8 client threads:
http://jeffr-tech.livejournal.com/6268.html#cutid1
http://jeffr-tech.livejournal.com/5705.html
Hardware is an 8-core amd64 system and jeffr seems willing
88 matches
Mail list logo
