Re: Poor performance of btrfs with Postgresql
От | Toby Corkindale |
---|---|
Тема | Re: Poor performance of btrfs with Postgresql |
Дата | |
Msg-id | 4DAFE39A.8090203@strategicdata.com.au обсуждение исходный текст |
Ответ на | Re: Poor performance of btrfs with Postgresql (Merlin Moncure <mmoncure@gmail.com>) |
Список | pgsql-general |
On 21/04/11 17:28, Merlin Moncure wrote: > On Thu, Apr 21, 2011 at 2:22 AM, Toby Corkindale > <toby.corkindale@strategicdata.com.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
В списке pgsql-general по дате отправления: