Skip site navigation (1) Skip section navigation (2)

Re: Performance on Sun Fire X4150 x64 (dd, bonnie++, pgbench)

From: Stephane Bailliez <sbailliez(at)gmail(dot)com>
To: Greg Smith <gsmith(at)gregsmith(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Performance on Sun Fire X4150 x64 (dd, bonnie++, pgbench)
Date: 2008-07-22 06:46:08
Message-ID: 48858230.8050906@gmail.com (view raw or flat)
Thread:
Lists: pgsql-performance
Greg Smith wrote:
> CFQ/Deadline/AS are I/O scheduler choices.  What changed completely in 
> 2.6.23 is the kernel process scheduler. 
> http://people.redhat.com/mingo/cfs-scheduler/sched-design-CFS.txt 
> gives some info about the new one.
>
> While the switch to CFS has shown great improvements in terms of 
> desktop and many server workloads, what I discovered is that the 
> pgbench test program itself is really incompatible with it.  There's a 
> kernel patch that seems to fix the problem at 
> http://lkml.org/lkml/2008/5/27/58 but I don't think it's made it into 
> a release yet.
>
> This is not to say the kernel itself is unsuitable for running 
> PostgreSQL itself, but if you're using pgbench as the program to 
> confirm that I expect you'll be dissapointed with results under the 
> Ubuntu 8.04 kernel. It tops out at around 10,000 TPS running the 
> select-only test for me while older kernels did 3X that much.

ok, thanks for all the details. good to know.

> Stop and think about this for a minute.  You're going into production 
> with an older version having a set of known, impossible to work around 
> issues that if you hit them the response will be "upgrade to 8.3 to 
> fix that", which will require the major disruption to your application 
> of a database dump and reload at that point if that fix becomes 
> critical.  And you can't just do that now because of some packaging 
> issues?  I hope you can impress upon the other people involved how 
> incredibly short-sighted that is.

I understand what you're saying. However if I were to play devil's 
advocate, the existing one that I'm 'migrating' (read entirely changing 
schemas, 'migrating' data) is coming out from a 8.1.11 install. It is 
not a critical system. The source data is always available from another 
system and the postgresql system would be a 'client'. So if 8.2.x is so 
abysmal it should not even be considered for install compared to 8.1.x 
and that only 8.3.x is viable then ok that makes sense and I have to go 
the extra mile.

But message received loud and clear. Conveniently 8.3.3 is also 
available on backports so it does not cost much and pinning it will be 
and pinning it is right now. (don't think there will be any pb with plr, 
even though the original seems to be patched a bit, but that will be for 
later when I don't know what to do and that all is ready).

For the sake of completeness (even though irrelevant), here's the run 
with 32 clients on 8.3 same config as before (except max_fsm_pages at 
204800)

1 19 36292
100 1499 32127
200 2994 30679
300 4489 29673
400 5985 18627
500 7480 19714
600 8975 19437
700 10000 20271
800 12000 18038
900 13000 9842
1000 15000 5996
1200 18000 5404
1400 20000 3701
1600 23000 2877
1800 26000 2657
2000 29000 2612

cheers,

-- stephane

In response to

Responses

pgsql-performance by date

Next:From: Ɓukasz FilutDate: 2008-07-22 07:48:34
Subject: Re: Less rows -> better performance?
Previous:From: Greg SmithDate: 2008-07-22 05:24:54
Subject: Re: A guide/tutorial to performance monitoring and tuning

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group