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 fro
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 include
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_set
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 t
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 f
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
ava
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 -> s
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 n
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
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.
http:
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 time,
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 mu
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 I
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 wa
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
id
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
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:
http://o
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:
http://oz
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:
http://ozlabs.org/~anton/linux/s
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 iden
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
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.
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
>> >> probl
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.htm
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 a
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
>> http://jeffr-
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
==>
cpu=8-mysql=5.0.32-gcc=3.4/oprofil
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 f
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 exc
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
> >>> http://ossipedia.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)
sni
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)
sni
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
==>
cpu=8-mysql=5.0.32-gcc=3.4/oprofil
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
==> cpu=8-mysql=5.0.32-gcc=3.4/oprofile-eu=2200-op=default-no
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 scalab
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:
http://www.mysqlperfor
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 8-c
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
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 to
44 matches
Mail list logo
