Kris Kennaway wrote:
On Sun, Feb 25, 2007 at 09:00:32AM +0200, Petri Helenius wrote:
Kris Kennaway wrote:
This shows the graph of MySQL transactions/second performed by a
multi-threaded client workload against a local MySQL database with
varying numbers of client threads, with identical
On Sun, Feb 25, 2007 at 10:41:17AM +0200, Petri Helenius wrote:
> Kris Kennaway wrote:
> >On Sun, Feb 25, 2007 at 09:00:32AM +0200, Petri Helenius wrote:
> >
> >>Kris Kennaway wrote:
> >>
> >>>This shows the graph of MySQL transactions/second performed by a
> >>>multi-threaded client workload
With this great progress, it would be even greater if there would be way
to run virtualization (Xen) when 7.0 hits the street.
Pete
___
freebsd-performance@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-performance
To uns
Kris Kennaway wrote:
How does that compare to 6.2-RELEASE performance?
>>> Much better. Fixing filedesc locking was key.
>>>
>>>
>> If there is extra cycles on the same hardware, a performance comparison
>> graph would be great.
>
> See the links in my posting ;)
I think he mea
On Sun, Feb 25, 2007 at 11:08:20AM +0100, Ivan Voras wrote:
> Kris Kennaway wrote:
>
> How does that compare to 6.2-RELEASE performance?
>
> >>> Much better. Fixing filedesc locking was key.
> >>>
> >>>
> >> If there is extra cycles on the same hardware, a performance comparison
Kris Kennaway writes:
Actually it will help the DB side, when you have multiple simultaneous
transactions - that's the point :)
A little confused.
Does this mean FreeBSD will split the threads into multiple CPUs?
Or you meant the DB will do better because the load from other programs will
be
Francisco Reyes wrote:
A little confused.
Does this mean FreeBSD will split the threads into multiple CPUs?
The point in threading is that different threads can execute
simultaneously on multiple CPU's.
Pete
___
freebsd-performance@freebsd.org ma
Petri Helenius writes:
The point in threading is that different threads can execute
simultaneously on multiple CPU's.
What combination of FreeBSD+Mysql will have multiple threads run by
different CPUs?
In the few SMP FreeBSD + Mysql setups (mysql 4.X) that I have at work I only
see mysql i
Francisco Reyes wrote:
Petri Helenius writes:
The point in threading is that different threads can execute
simultaneously on multiple CPU's.
What combination of FreeBSD+Mysql will have multiple threads run by
different CPUs?
In the few SMP FreeBSD + Mysql setups (mysql 4.X) that I have at
Francisco Reyes wrote:
> What combination of FreeBSD+Mysql will have multiple threads run by
> different CPUs?
>
> In the few SMP FreeBSD + Mysql setups (mysql 4.X) that I have at work
> I only see mysql in one cpu as reported by top.
I just did the tests highlighted on the thread:
Progress on sc
On Sun, Feb 25, 2007 at 11:16:54AM -0500, Francisco Reyes wrote:
> Kris Kennaway writes:
>
> >Actually it will help the DB side, when you have multiple simultaneous
> >transactions - that's the point :)
>
> A little confused.
> Does this mean FreeBSD will split the threads into multiple CPUs?
Ye
Hi, Kris,
On Sat, Feb 24, 2007 at 04:55:08PM -0500, Kris Kennaway wrote:
> Now that the goals of the SMPng project are complete, for the past
> year or more several of us have been working hard on profiling FreeBSD
> in various multiprocessor workloads, and looking for performance
> bottlenecks to
On Sun, Feb 25, 2007 at 08:22:39PM +0100, Jeremie Le Hen wrote:
> Hi, Kris,
>
> On Sat, Feb 24, 2007 at 04:55:08PM -0500, Kris Kennaway wrote:
> > Now that the goals of the SMPng project are complete, for the past
> > year or more several of us have been working hard on profiling FreeBSD
> > in va
Kris Kennaway wrote:
> 6.2 and 7.0 CVS sources (which are graphed on Jeff's blog and my
> webpage linked there) are unlikely to differ much: as I said, filedesc
> locking was key to fixing performance here. I'm sure we'll be
> promoting this improvement heavily when 7.0 enters release cycle, to
>
On Sun, Feb 25, 2007 at 09:15:40PM +0100, Ivan Voras wrote:
> Kris Kennaway wrote:
>
> > 6.2 and 7.0 CVS sources (which are graphed on Jeff's blog and my
> > webpage linked there) are unlikely to differ much: as I said, filedesc
> > locking was key to fixing performance here. I'm sure we'll be
>
Francisco Reyes wrote:
What combination of FreeBSD+Mysql will have multiple threads run by
different CPUs?
In the few SMP FreeBSD + Mysql setups (mysql 4.X) that I have at work
I only see mysql in one cpu as reported by top.
We tested FreeBSD 6.2 and Mysql 5.0 I'd say the main requirement will
Kris Kennaway wrote:
I'm saying that the 7.0-CVS sources, which are graphed, are unlikely
to differ significantly from 6.2-CVS, i.e. they do not show good
scaling on this benchmark because of the problems with filedesc
locking in CVS.
Could you give a link to the 7.0-CVS graph?
Pete
_
On Sun, Feb 25, 2007 at 10:26:18PM +0200, Petri Helenius wrote:
> Kris Kennaway wrote:
> >
> >I'm saying that the 7.0-CVS sources, which are graphed, are unlikely
> >to differ significantly from 6.2-CVS, i.e. they do not show good
> >scaling on this benchmark because of the problems with filedesc
>
Kris Kennaway wrote:
> I'm saying that the 7.0-CVS sources, which are graphed, are unlikely
> to differ significantly from 6.2-CVS, i.e. they do not show good
> scaling on this benchmark because of the problems with filedesc
> locking in CVS.
Ok, got it, but the second question is: where is it?
G
If so, then your task is the following:
Make SYSV semaphores less dumb about process wakeups. Currently
whenever the semaphore state changes, all processes sleeping on the
semaphore are woken, even if we only have released enough resources
for one waiting process to claim. i.e. there is a thunde
20 matches
Mail list logo
