All of lore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.