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@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[Postgresql Jobs] [Postgresql Admin] [Postgresql Performance] [Linux Clusters] [PHP Home] [PHP on Windows] [Programming PHP] [Kernel Newbies] [PHP Classes] [Find Someone Nice] [PHP Books] [PHP Databases] [Postgresql & PHP] [Yosemite]