Re: Great Bridge re-runs benchmark with MySQL "tuned" - Mailing list 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                  |
+------------------------------------------------------------------+