<div dir="ltr">Hi Dave,<div><br></div><div>Thank you for your reply. I did some test today and described those as follows:</div><div><br></div><div>D<font color="#500050"><span style="font-size:14px">elete the existing test file , and redo the test : </span></font><span style="color:rgb(80,0,80);font-size:14px">fio -ioengine=libaio -bs=4k </span><span style="color:rgb(80,0,80);font-size:14px">-direct=1 -thread -rw=randwrite -size=50G -filename=/mnt/test -name="EBS </span><span style="color:rgb(80,0,80);font-size:14px">4KB randwrite test" -iodepth=64 -runtime=60</span></div><div><span style="color:rgb(80,0,80);font-size:14px">The iops resultes is 19k±</span><span style="color:rgb(80,0,80);font-size:14px">(per second)</span><span style="color:rgb(80,0,80);font-size:14px">;  I continue to fio this test file untill it was filled to the full. Then I did another test using the same test case, the results was 210k±(per second).(The results mentioned yesterday was </span><font color="#500050"><span style="font-size:14px">partial.  I used the same test file several times, </span></font><span style="font-size:14px">the results degraded because of the test file was not fill to the full</span><span style="color:rgb(80,0,80);font-size:14px">) </span></div><div><br></div><div><font color="#500050"><span style="font-size:14px">I try to remake the filesystem using the following command to increase the internal log size , inode size and agcount num:</span></font></div><div><font color="#500050"><span style="font-size:14px">mkfs.xfs /dev/hioa2 -f -n size=64k -i size=2048,align=1 -d agcount=2045 -l size=512m</span></font></div><div><font color="#500050"><span style="font-size:14px">but it has no help to the result.</span></font></div><div><font color="#500050"><span style="font-size:14px"><br></span></font></div><div><br></div><div>Any suggestion to deal with this problems ?<br></div><div>I very appreciate your feedback.</div><div><span style="color:rgb(80,0,80);font-size:14px">    </span><br></div><div><span style="color:rgb(80,0,80);font-size:14px">songbo</span></div><div><br></div><div>    </div><div><span style="color:rgb(80,0,80);font-size:14px">    </span></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-04-12 7:10 GMT+08:00 Dave Chinner <span dir="ltr"><<a href="mailto:david@fromorbit.com" target="_blank">david@fromorbit.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mon, Apr 11, 2016 at 10:14:06PM +0800, Songbo Wang wrote:<br>
> Hi xfsers:<br>
><br>
> I got some troubles on the performance of  xfs.<br>
> The environment is ,<br>
>      xfs version is 3.2.1,<br>
>      centos 7.1,<br>
>      kernel version:3.10.0-229.el7.x86_64.<br>
>      pcie-ssd card,<br>
>      mkfs: mkfs.xfs /dev/hioa2 -f -n size=64k -i size=512 -d agcount=40 -l<br>
> size=1024m.<br>
>      mount: mount /dev/hioa2 /mnt/  -t xfs -o<br>
> rw,noexec,nodev,noatime,nodiratime,nobarrier,discard,inode64,logbsize=256k,delaylog<br>
> I use the following command to test iops: fio -ioengine=libaio -bs=4k<br>
> -direct=1 -thread -rw=randwrite -size=50G -filename=/mnt/test -name="EBS<br>
> 4KB randwrite test" -iodepth=64 -runtime=60<br>
> The results is normal at the beginning which is about 210k±，but some<br>
> seconds later, the results down to 19k±.<br>
<br>
</span>Looks like the workload runs out of log space due to all the<br>
allocation transactions being logged, which then causes new<br>
transactions to start tail pushing the log to flush dirty metadata.<br>
This is needed to to make more space in the log for on incoming dio<br>
writes that require allocation transactions. This will block IO<br>
submission until there is space available in the log.<br>
<br>
Let's face it, all that test does is create a massively fragmented<br>
50GB file, so you're going to have a lot of metadata to log. Do the<br>
maths - if it runs at 200kiops for a few seconds, it's created a<br>
million extents.<br>
<br>
And it's doing random insert on the extent btree, so<br>
it's repeatedly dirtying the entire extent btree. This will trigger<br>
journal commits quite frequently as this is a large amount of<br>
metadata that is being dirtied. e.g. at 500 extent records per 4k<br>
block, a million extents will require 2000 leaf blocks to store them<br>
all. That's 80MB of metadata per million extents that this workload<br>
is generating and repeatedly dirtying.<br>
<br>
Then there's also other metadata, like the free space btrees, that<br>
is also being repeatedly dirtied, etc, so it would not be unexpected<br>
to see a workload like this on high IOPS devices allocating 100MB of<br>
metadata every few seconds and the amount being journalled steadily<br>
increasing until the file is fully populated.<br>
<span class=""><br>
> I did a senond test ,<br>
>      umount the /dev/hioa2,<br>
>      fio -ioengine=libaio -bs=4k -direct=1  -thread -rw=randwrite<br>
> -filename=/dev/hioa2  -name="EBS 8KB randwrite test" -iodepth=64 -runtime=60<br>
> The results was normal, the iops is about 210k± all the time.<br>
<br>
</span>That's not an equivalent test - it's being run direct to the block<br>
device, not to a file on the filesytem on the block device, and so<br>
you won't see artifacts taht are a result of creating worst case<br>
file fragmentation....<br>
<br>
Cheers,<br>
<br>
Dave.<br>
<span class="HOEnZb"><font color="#888888">--<br>
Dave Chinner<br>
<a href="mailto:david@fromorbit.com">david@fromorbit.com</a><br>
</font></span></blockquote></div><br></div>