Re: Great Bridge re-runs benchmark with MySQL "tuned"
От | sasha@mysql.com |
---|---|
Тема | Re: Great Bridge re-runs benchmark with MySQL "tuned" |
Дата | |
Msg-id | 39A3C436.740D9DB6@mysql.com обсуждение исходный текст |
Ответ на | Great Bridge re-runs benchmark with MySQL "tuned" (Ned Lilly <ned@greatbridge.com>) |
Список | pgsql-general |
Michael Widenius wrote: > > Hi! > > >>>>> "Ned" == Ned Lilly <ned@greatbridge.com> writes: > > Ned> Folks, > Ned> We posted the following announcement on our website today, at > Ned> http://www.greatbridge.com/news/press.html. > > Ned> Please feel free to email me off-list with any questions. > > Ned> Thanks, > Ned> Ned > > Thanks for running a new test. The only big thing I still miss is a > benchmark with the 3.23 RPM; The select code in MySQL 3.23 is not that > much faster than 3.23 (except if you use GROUP BY or DISTINCT, which > is MUCH faster in 3.23), but using 3.23 would cancel the effect > of using RedHat 6.1 with a buggy LinuxThread library. There is another scaling issue involved when running Linux 2.2 kernel - the scheduler is overzealous to thwart fork bombs, and because of that, split the priority of a process after fork() or clone(). This, however, should have affected PostreSQL in a way similiar to MySQL. The fact that PostreSQL scales without any decline at all while other databases do not with performance dropping in the pattern characteristic of priority split issue suggests that there is something like a reading cached result or a similar optimization that PostreSQL was able to do on this particular test. It would be interesting to see what happens after you apply the following patch to the kernel: --- fork.c.orig Mon Sep 27 07:56:32 1999 +++ fork.c Thu May 25 16:10:48 2000 @@ -691,9 +691,11 @@ * more scheduling fairness. This is only important in the first * timeslice, on the long run the scheduling behaviour is unchanged. */ + p->counter = (current->counter + 1) >> 1; current->counter >>= 1; - p->counter = current->counter; + if (!current->counter) + current->need_resched = 1; /* * Ok, add it to the run-queues and make it * visible to the rest of the system. --- exit.c.orig Mon Sep 27 07:56:32 1999 +++ exit.c Thu May 25 16:13:31 2000 @@ -56,6 +56,9 @@ current->cmin_flt += p->min_flt + p->cmin_flt; current->cmaj_flt += p->maj_flt + p->cmaj_flt; current->cnswap += p->nswap + p->cnswap; + current->counter += p->counter; + if (current->counter >= current->priority*2) + current->counter = current->priority*2-1; free_task_struct(p); } else { printk("task releasing itself\n"); or just try 2.4 kernel > I think we will take a look at implementing a similar test as the > AS3AP test in our own test suite so that we can get a open source test > that we can use to benchmark databases under heavy load. > > We would REALLY prefer to have an open source benchmark that everyone > can download and test to verify results! > > By the way, what was the cache parameters you setup for PostgreSQL > when running the test ? I asked this before but never got an answer > for this (I would just like to setup PostgreSQL perfectly for our > benchmarks) Running the benchmark once with --log --log-update and sending us the logs will help us a lot increating an open source benchmark similar to the one you've run. -- Sasha Pachev +------------------------------------------------------------------+ | ____ __ _____ _____ ___ http://www.mysql.com | | /*/\*\/\*\ /*/ \*\ /*/ \*\ |*| Sasha Pachev | | /*/ /*/ /*/ \*\_ |*| |*||*| sasha@mysql.com | | /*/ /*/ /*/\*\/*/ \*\|*| |*||*| Provo, Utah, USA | | /*/ /*/ /*/\*\_/*/ \*\_/*/ |*|____ | | ^^^^^^^^^^^^/*/^^^^^^^^^^^\*\^^^^^^^^^^^ | | /*/ \*\ Developers Team | +------------------------------------------------------------------+
В списке pgsql-general по дате отправления: