On Wed, Aug 16, 2017 at 8:01 AM, Qu Wenruo <quwenruo.btrfs@xxxxxxx> wrote: > BTW, when Fujitsu tested the postgresql workload on btrfs, the result is > quite interesting. > > For HDD, when number of clients is low, btrfs shows obvious performance > drop. > And the problem seems to be mandatory metadata COW, which leads to > superblock FUA updates. > And when number of clients grow, difference between btrfs and other fses > gets much smaller, the bottleneck is the HDD itself. > > While for SSD, when number of clients is low, btrfs is almost the same > performance as other fses, nodatacow/nodatasum only provides marginal > difference. > But when number of clients grows, btrfs falls far behind other fses. > The reason seems to be related to how postgresql commit its transaction, > which always fsync its journal sequentially without concurrency. I wonder to what degree fsync is used as a hammer for a problem that needs more granular indicators to solve, like fsadvise() and even extending it? But I'm also curious if the above behaviors you report, how it changes by combining SSD and HDD via either dm-cache or bcache? Do the worst aspects of SSD and HDD get muted in that case? Or do the worst aspects become even worse across the board? -- Chris Murphy -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
