Received: from localhost (unknown [200.46.204.184])
	by developer.postgresql.org (Postfix) with ESMTP id 1CE872E0042
	for <pgsql-performance-postgresql.org@developer.postgresql.org>;
	Thu, 17 Apr 2008 21:35:25 -0300 (ADT)
Received: from developer.postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.184]) (amavisd-maia, port 10024)
	with ESMTP id 05496-07
	for <pgsql-performance-postgresql.org@developer.postgresql.org>;
	Thu, 17 Apr 2008 21:35:14 -0300 (ADT)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.5
Received: from bifrost.lang.hm (mail.lang.hm [64.81.33.126])
	by developer.postgresql.org (Postfix) with ESMTP id 1DEBF2E0037
	for <pgsql-performance@postgresql.org>;
	Thu, 17 Apr 2008 21:35:21 -0300 (ADT)
Received: from asgard.lang.hm (asgard.lang.hm [10.0.0.100])
	by bifrost.lang.hm (8.13.4/8.13.4/Debian-3) with ESMTP id
	m3I0ZHOT008821; Thu, 17 Apr 2008 17:35:17 -0700
Date: Thu, 17 Apr 2008 17:41:39 -0700 (PDT)
From: david@lang.hm
X-X-Sender: dlang@asgard
To: Greg Smith <gsmith@gregsmith.com>
cc: pgsql-performance@postgresql.org
Subject: Re: Strange behavior: pgbench and new Linux kernels
In-Reply-To: <Pine.GSO.4.64.0804172002010.15803@westnet.com>
Message-ID: <alpine.DEB.1.10.0804171740250.18186@asgard>
References: <Pine.GSO.4.64.0804170230180.26917@westnet.com>
	<fd145f7d0804171009h7658d3bbqf099b5c0e9235268@mail.gmail.com>
	<Pine.LNX.4.64.0804171840180.20402@aragorn.flymine.org>
	<Pine.GSO.4.64.0804172002010.15803@westnet.com>
User-Agent: Alpine 1.10 (DEB 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200804/256
X-Sequence-Number: 29749

On Thu, 17 Apr 2008, Greg Smith wrote:

> On Thu, 17 Apr 2008, Matthew wrote:
>
>> The last message in the thread says that 2.6.25-rc6 has the problem nailed. 
>> That was a month ago. So I guess, upgrade to 2.6.25, which was released 
>> today.
>
> Ah, even more support for me to distrust everything I read.  The change has 
> flattened out things, so now the pgbench results are awful everywhere. On 
> this benchmark 2.6.25 is the worst kernel yet:
>
> -bash-3.00$ pgbench -S -c 4 -t 10000 pgbench | grep excluding
> tps = 8619.710649 (excluding connections establishing)
> tps = 8664.321235 (excluding connections establishing)
> tps = 8671.973915 (excluding connections establishing)
> (was 18388 in 2.6.9 and 16621 in 2.6.23-3)
>
> -bash-3.00$ pgbench -S -c 8 -t 10000 pgbench | grep excluding
> tps = 9011.728765 (excluding connections establishing)
> tps = 9039.441796 (excluding connections establishing)
> tps = 9206.574000 (excluding connections establishing)
> (was 15760 in 2.6.9 and 15551 in 2.6.23-3)
>
> -bash-3.00$ pgbench -S -c 16 -t 10000 pgbench | grep excluding
> tps = 7063.710786 (excluding connections establishing)
> tps = 6956.266777 (excluding connections establishing)
> tps = 7120.971600 (excluding connections establishing)
> (was 14148 in 2.6.9 and 7311 in 2.6.23-3)
>
> -bash-3.00$ pgbench -S -c 32 -t 10000 pgbench | grep excluding
> tps = 7006.311636 (excluding connections establishing)
> tps = 6971.305909 (excluding connections establishing)
> tps = 7002.820583 (excluding connections establishing)
> (was 13647 in 2.6.9 and 7141 in 2.6.23-3)
>
> This is what happens when the kernel developers are using results from a 
> MySQL tool to optimize things I guess.  It seems I have a lot of work ahead 
> of me here to nail down and report what's going on here.

report this to the kernel list so that they know, and be ready to test 
fixes. the kernel developers base sucess or failure on the results of 
tests. if the only people providing test results are MySQL people, how 
would they know there is a problem?

David Lang