Re: Poor performance of btrfs with Postgresql

On 21/04/11 17:28, Merlin Moncure wrote:
> On Thu, Apr 21, 2011 at 2:22 AM, Toby Corkindale
>   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