Re: Poor performance of btrfs with Postgresql - Mailing list pgsql-general
From | Toby Corkindale |
---|---|
Subject | Re: Poor performance of btrfs with Postgresql |
Date | |
Msg-id | 4DB7AE5B.7050802@strategicdata.com.au Whole thread Raw |
In response to | Re: Poor performance of btrfs with Postgresql ("mark" <dvlhntr@gmail.com>) |
List | pgsql-general |
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
pgsql-general by date: