On Thursday 05 October 2006 03:52, Jerry Bell wrote:
> I expected the 2950 to be a bit closer to the 1.8Ghz opteron discussed
> here:
> http://article.gmane.org/gmane.os.freebsd.performance/1137/match=mysql
Well he used several patches [1] from the current + ULE scheduler, which seems
to give you
On Wednesday 10 May 2006 04:38, Scott Long wrote:
>
> Were you testing on SMP, and if so, was Hyperthreading enabled?
>
I tested it on 3 amd64 machines, so no hyperthreading possible.
The library preload hack was tested on:
1 * dualcore amd X2
4 * dualcore opteron
Hacked mysqld that used TSC w
On Tuesday 09 May 2006 20:35, Julian Elischer wrote:
> Sven Petai wrote:
>
> are there any patches that take the gettimeofday() calls and replace
> them with something that is cheap
> such as only doing every 10th one and just returning the last value ++ 1
> uSec for the other o
On Tuesday 09 May 2006 03:42, Kris Kennaway wrote:
> On Tue, May 09, 2006 at 03:34:59AM +0300, Sven Petai wrote:
> > > Hmm, with this patch mysql 4.1 seems to crash at startup. I haven't
> > > yet had time to investigate. Is anyone else seeing this?
> >
> >
> Hmm, with this patch mysql 4.1 seems to crash at startup. I haven't
> yet had time to investigate. Is anyone else seeing this?
>
Seems to run fine here with 4.1.18 on amd64, but doesn't seem to make much
difference though.
I ran the tests again on the 8 core machine with and without rwatsons
On Sunday 07 May 2006 22:16, you wrote:
> On Sun, May 07, 2006 at 10:00:41PM +0300, Sven Petai wrote:
> > The results in my mail were mean values over 2 runs,
> > only once did I see really huge (more than 10%) differences between
> > several subsequent runs with same se
> Anyhow, what I'm getting at is this: make sure when you measure MySQL
> performance, you do a series of runs, discard the first few, and then take
> an average of the remainder, and watch out for outliers.
The results in my mail were mean values over 2 runs,
only once did I see really huge (more
hi
I performed tests on a 4 * dualcore 2Ghz opteron system (so 8 cores in total).
In general with 10 parallel smacker threads the performance seems to go up
with your patch by ~44% and with 100 parallel threads it goes down ~25%
Here's a graph of select smack performance with your patch:
http://
On Saturday 08 April 2006 13:32, David Xu wrote:
> On Saturday 08 April 2006 17:44, Michael Vince wrote:
> > I have also tried putting my Perl under libthr for a single thread log
> > analyzer and to my surprise it even could process logs faster.
>
> I don't know why, but I only know I did some mic
On Wednesday 05 April 2006 21:52, Mike Silbersack wrote:
> If you're willing to spend more time looking at this, I suggest that you
> run truss or ktrace on the super-smack processes. I did a small amount of
> mysql vs postgres vs firebird benchmarking two years ago for a class
> project, and not
On Wednesday 05 April 2006 08:31, David Xu wrote:
>
> Can you disable log-bin option in my.cnf to see if it is a FS bottleneck
> when you are running update-smack ? please run Linux and FreeBSD
> with same hardware and my.cnf configuration, thanks.
> I know this is not very right, but it can be us
hi
Before I begin, let me just say that I'm probably aware most of the threads
about mysql performance in various fbsd lists over last couple of years, so
please let's not consentrate on the usual points made over and over again
like how filesystems are mounted under linux, how fast time() is o
12 matches
Mail list logo
