Greg Smith wrote:
Note that I've had some issues with the desktop Ubuntu giving slower
results in tests like this than the same kernel release using the
stock kernel parameters. Haven't had a chance yet to see how the
server Ubuntu kernel fits into that or exactly what the desktop one is
doing wrong yet. Could be worse--if you were running any 8.04 I expect
your pgbench results would be downright awful.
Ah interesting. Isn't it a scheduler problem, I thought CFQ was the
default for desktop ?
I doublechecked the 7.10 server on this box and it's really the deadline
one that is used:
cat /sys/block/sdb/queue/scheduler
noop anticipatory [deadline] cfq
Do you have some more pointers on the 8.04 issues you mentioned ?
(that's deemed to be the next upgrade from ops)
postgresql 8.2.9 with data and xlog as mentioned above
There are so many known performance issues in 8.2 that are improved in
8.3 that I'd suggest you really should be considering it for a new
install at this point.
Yes I'd definitely prefer to go 8.3 as well but there are a couple
reasons for now I have to suck it up:
- 8.2 is the one in the 7.10 repository.
- I need plr as well and 8.3-plr debian package does not exist yet.
(I know in both cases we could recompile and install it from there, but ...)
In general, you'll want to use a couple of clients per CPU core for
pgbench tests to get a true look at the scalability. Unfortunately,
the way the pgbench client runs means that it tends to top out at 20
or 30 thousand TPS on read-only tests no matter how many cores you
have around. But you may find operations where peak throughput comes
at closer to 32 clients here rather than just 8.
ok. Make sense.
As far as the rest of your results go, Luke's comment that you may
need more than one process to truly see the upper limit of your disk
performance is right on target. More useful commentary on that issue
I'd recomend is near the end of
http://www.commandprompt.com/blogs/joshua_drake/2008/04/is_that_performance_i_smell_ext2_vs_ext3_on_50_spindles_testing_for_postgresql/
Yeah I was looking at that url as well. Very useful.
Thanks for all the info Greg.
-- stephane