public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Wang Shilong <wshilong@ddn.com>
Cc: "linux-xfs@vger.kernel.org" <linux-xfs@vger.kernel.org>, xfs@oss.sgi.com
Subject: Re: Bad Metadata performances for XFS?
Date: Tue, 5 Jul 2016 08:52:26 +1000	[thread overview]
Message-ID: <20160704225226.GD27480@dastard> (raw)
In-Reply-To: <3ED34739A4E85E4F894367D57617CDEF9ED9518B@LAX-EX-MB2.datadirect.datadirectnet.com>

[xfs@oss.sgi.com is where you'll find the XFS developers]

On Mon, Jul 04, 2016 at 05:32:40AM +0000, Wang Shilong wrote:
> Hello Guys,
> 
>       I happened run some benchmarks for XFS, and found some intresting to share here:
> Kernel version:
> [root@localhost shm]# uname -r
> 4.7.0-rc5+
> 
> [root@localhost shm]# cat /proc/cpuinfo  | grep Intel
> vendor_id	: GenuineIntel
> model name	: Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz
> 
> dd 16GB to /dev/shm/data to use memory backend storage to benchmark metadata performaces.
> 
> Benchmark tool is mdtest, you can download it from 
> https://sourceforge.net/projects/mdtest/
> 
> Steps to run benchmark
> #mkfs.xfs /dev/shm/data
> #mount /dev/shm/data /mnt/test
> #mdtest -d /mnt/test -n 2000000
> 
> 1 tasks, 2000000 files/directories
> 
> SUMMARY: (of 1 iterations)
>    Operation                      Max            Min           Mean        Std Dev
>    ---------                      ---            ---           ----        -------
>    Directory creation:      24724.717      24724.717      24724.717          0.000
>    Directory stat    :    1156009.290    1156009.290    1156009.290          0.000
>    Directory removal :     103496.353     103496.353     103496.353          0.000
>    File creation     :      23094.444      23094.444      23094.444          0.000
>    File stat         :    1158704.969    1158704.969    1158704.969          0.000
>    File read         :     752731.595     752731.595     752731.595          0.000
>    File removal      :     105481.766     105481.766     105481.766          0.000
>    Tree creation     :       2229.827       2229.827       2229.827          0.000
>    Tree removal      :          1.275          1.275          1.275          0.000
> 
> -- finished at 07/04/2016 12:54:26 --
> 
> IOPS for file creation is only 2.3W, however compare to Ext4 with same testing.
>   Operation                      Max            Min           Mean        Std Dev
>    ---------                      ---            ---           ----        -------
>    Directory creation:      65875.462      65875.462      65875.462          0.000
>    Directory stat    :    1060115.356    1060115.356    1060115.356          0.000
>    Directory removal :     109955.606     109955.606     109955.606          0.000
>    File creation     :     114898.425     114898.425     114898.425          0.000
>    File stat         :    1046223.044    1046223.044    1046223.044          0.000
>    File read         :     699663.339     699663.339     699663.339          0.000
>    File removal      :     152320.304     152320.304     152320.304          0.000
>    Tree creation     :      19065.018      19065.018      19065.018          0.000
>    Tree removal      :          1.269          1.269          1.269          0.000
> 
> IOPS of file creation is more than 11W!!!
> 
> I understand Ext4 use Hash index tree and XFS use B+ tree for directroy, so i test Btrfs
> for this case.
>   ---------                      ---            ---           ----        -------
>    Directory creation:      99312.866      99312.866      99312.866          0.000
>    Directory stat    :    1116205.199    1116205.199    1116205.199          0.000
>    Directory removal :      66441.011      66441.011      66441.011          0.000
>    File creation     :      91282.930      91282.930      91282.930          0.000
>    File stat         :    1117636.580    1117636.580    1117636.580          0.000
>    File read         :     754964.332     754964.332     754964.332          0.000
>    File removal      :      69708.657      69708.657      69708.657          0.000
>    Tree creation     :      29746.837      29746.837      29746.837          0.000
>    Tree removal      :          1.289          1.289          1.289          0.000
> 
> Even Btrfs, it got about 9W....
> 
> Hmm..Maybe this is because too many files under single directory?(200W won't be too much i guess)
> I reduce number of files for XFS to 50W.
> 1 tasks, 500000 files/directories
> 
> SUMMARY: (of 1 iterations)
>    Operation                      Max            Min           Mean        Std Dev
>    ---------                      ---            ---           ----        -------
>    Directory creation:      53021.632      53021.632      53021.632          0.000
>    Directory stat    :    1187581.191    1187581.191    1187581.191          0.000
>    Directory removal :     108112.695     108112.695     108112.695          0.000
>    File creation     :      51654.911      51654.911      51654.911          0.000
>    File stat         :    1180447.310    1180447.310    1180447.310          0.000
>    File read         :     755391.001     755391.001     755391.001          0.000
>    File removal      :     108415.353     108415.353     108415.353          0.000
>    Tree creation     :       2129.088       2129.088       2129.088          0.000
>    Tree removal      :          5.272          5.272          5.272          0.000
> 
> -- finished at 07/04/2016 12:59:17 --
> 
> So performances go up from 2.3W to 5.1W, but still very slow compared to others...
> 
> 
> PS: mkfs options for Btrfs is: mkfs.btrfs -m single -d single -f
>        mkfs options for XFS is: mkfs.xfs -f
>        mkfs options for Ext4 is: mkfs.ext4 -i 2048(to generate enough inodes for testing)
> 
> Best Regards,
> Shilong
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

       reply	other threads:[~2016-07-04 22:52 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <3ED34739A4E85E4F894367D57617CDEF9ED9518B@LAX-EX-MB2.datadirect.datadirectnet.com>
2016-07-04 22:52 ` Dave Chinner [this message]
2016-07-05  0:18   ` Bad Metadata performances for XFS? Dave Chinner
2016-07-05  1:43     ` Wang Shilong
2016-07-05  7:29       ` Dave Chinner
2016-07-05 20:34       ` Chris Murphy
2016-07-06 11:49         ` Roger Willcocks
2016-07-06 23:05           ` Dave Chinner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160704225226.GD27480@dastard \
    --to=david@fromorbit.com \
    --cc=linux-xfs@vger.kernel.org \
    --cc=wshilong@ddn.com \
    --cc=xfs@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox