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
