On 22/04/11 12:39, mark wrote:
(Tested on Ubuntu Server - Maverick - Kernel 2.6.35-28)
Don't take this the wrong way - I applaud you asking for feedback. BTW ->
Have you seen Greg Smiths PG 9.0 high performance book ? it's got some
chapters dedicated to benchmarking.
I do have the book, actually; I wasn't referring to it for these quick
tests though.
Do you have battery backed write cache and a 'real' hardware raid card?
> Not sure why your testing with raid 0, but that is just me.
In production, yes. On a development machine, no. (Also hence the raid-0
-- this machine doesn't need to be highly reliable, and am more
interested in higher performance.)
You also did not provide enough other details for it to be of interest to
many other people as a good data point. If you left all else at the defaults
then might just mention that.
Did you play with readahead ?
No, but that's a good suggestion.
Have you? How much difference has it made?
[snip]
How was the raid configured ? did you do stripe/block alignment ? might not
make a noticeable difference but if one is serious maybe it is a good habit
to get into. I haven't done as much tuning work as I should with xfs but a
primer can be found at :
http://oss.sgi.com/projects/xfs/training/xfs_slides_04_mkfs.pdf
Linux software RAID; stripe/blocks were aligned correctly for lvm and at
least ext4; unsure about XFS, and I've blown that away by now so can't
check. :/
Getting benches with pg 9 would also be interested because of the changes to
pgbench between 8.4 and 9.0, although at only about 230 tps I don't know how
much a difference you will see, since the changes only really show up when
you can sustain at a much higher tps rate.
Well, closer to 2400 TPS actually, including the runs with barriers
disabled.
I'll re-run the tests in May - by then ubuntu server will be out, and
11.04 comes with a newer kernel that supposedly improves btrfs
performance a bit (and ext4 slightly), and I'll also use PG 9.0
Knowing the PG config, would also be interesting, but with so few disks and
OS, xlogs, and data all being on the same disks .... well yeah it's not a
superdome, but still would be worth noting on your blog for posterity sake.
Yeah; I know it's not a supercomputer setup, but I found it interesting
to note that btrfs was such a poor contender -- that was the main point
of my results. Also it's interesting to note that disabling barriers
provides such a massive increase in performance.
(But with serious caveats if you are to do so safely)
Right now I wish I had a lot of time to dig into different XFS setups on
some of our production matching gear - but other projects have me too busy
and I am having trouble getting our QA people loan me gear for it.
Heck I haven't tested ext4 at all to speak of - so shame on me for that.
It seems worthwhile - it consistently ran slightly faster than XFS.
To loosely quote someone else I saw posting to a different thread a while
back "I would walk through fire for a 10% performance gain". IMO through
proper testing and benchmarking you can make sure you are not giving up 10%
(or more) performance where you don't have to - no matter what hardware you
are running.
I'm more worried about giving up 80% of my performance, as demonstrated
by using sub-optimal filesystems, or sub-optimal options to the optimal
filesystems!
Toby
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
