From: | Toby Corkindale <toby(dot)corkindale(at)strategicdata(dot)com(dot)au> |
---|---|
To: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
Cc: | luv-main <luv-main(at)luv(dot)asn(dot)au>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Poor performance of btrfs with Postgresql |
Date: | 2011-04-21 07:58:18 |
Message-ID: | 4DAFE39A.8090203@strategicdata.com.au |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 21/04/11 17:28, Merlin Moncure wrote:
> On Thu, Apr 21, 2011 at 2:22 AM, Toby Corkindale
> <toby(dot)corkindale(at)strategicdata(dot)com(dot)au> wrote:
>> I've done some testing of PostgreSQL on different filesystems, and with
>> different filesystem mount options.
>>
>> I found that xfs and ext4 both performed similarly, with ext4 just a few
>> percent faster; and I found that adjusting the mount options only gave small
>> improvements, except for the barrier options. (Which come with a hefty
>> warning)
>>
>> I also tested btrfs, and was disappointed to see it performed *dreadfully* -
>> even with the recommended options for database loads.
>>
>> Best TPS I could get out of ext4 on the test machine was 2392 TPS, but btrfs
>> gave me just 69! This is appalling performance. (And that was with nodatacow
>> and noatime set)
>>
>> I'm curious to know if anyone can spot anything wrong with my testing?
>> I note that the speed improvement from datacow to nodatacow was only small -
>> can I be sure it was taking effect? (Although cat /proc/mounts reported it
>> had)
>>
>> The details of how I was running the test, and all the results, are here:
>> http://blog.dryft.net/2011/04/effects-of-filesystems-and-mount.html
>>
>> I wouldn't run btrfs in production systems at the moment anyway, but I am
>> curious about the current performance.
>> (Tested on Ubuntu Server - Maverick - Kernel 2.6.35-28)
>
> your nobarrier options are not interesting -- hardware sync is not
> being flushed. the real numbers are in the 230 range. not sure why
> brtfs is doing so badly -- maybe try comparing on single disk volume
> vs raid 0?
Note that some documentation recommends disabling barriers IFF you have
battery-backed write-cache hardware, which is often true on higher-end
hardware.. thus the measured performance is interesting to know.
Quoted from the "mount" man page:
Write barriers enforce proper on-disk ordering of journal commits,
making volatile disk write caches safe to use, at some performance
penalty. If your disks are battery-backed in one way or
another, disabling barriers may safely improve performance.
Cheers,
Toby
From | Date | Subject | |
---|---|---|---|
Next Message | Henry C. | 2011-04-21 10:16:04 | Re: Poor performance of btrfs with Postgresql |
Previous Message | Merlin Moncure | 2011-04-21 07:28:10 | Re: Poor performance of btrfs with Postgresql |