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:

Previous
From: Rob Sargent
Date:
Subject: Re: Feature Request, aggregate functions distinct on
Next
From: Joel Reymont
Date:
Subject: Re: optimizing a cpu-heavy query