Search Postgresql Archives

Re: Poor performance of btrfs with Postgresql

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux