<div dir="ltr">Hi Dave,<div>   </div><div>Thank you for your suggestion,  and very appreciate for your reply!</div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-04-13 5:31 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 Tue, Apr 12, 2016 at 10:07:45PM +0800, Songbo Wang wrote:<br>
> Hi Dave,<br>
><br>
> Thank you for your reply. I did some test today and described those as<br>
> follows:<br>
><br>
> Delete the existing test file , and redo the test : fio -ioengine=libaio<br>
> -bs=4k -direct=1 -thread -rw=randwrite -size=50G -filename=/mnt/test<br>
> -name="EBS 4KB randwrite test" -iodepth=64 -runtime=60<br>
</span>> The iops resultes is 19ką(per second);  I continue to fio this test file<br>
<span class="">> untill it was filled to the full. Then I did another test using the same<br>
</span>> test case, the results was 210ką(per second).(The results mentioned<br>
<br>
Yup, that's when the workload goes from allocation bound to being an<br>
overwrite workload when there is no allocation occurring.<br>
<br>
Perhaps you should preallocate the file using the fallocate=posix<br>
option. This will move the initial overhead to IO completion, so<br>
won't block submission, and the file will not end up a fragmented<br>
mess as the written areas will merge back into large single extents<br>
as more of the file is written.<br>
<span class=""><br>
> yesterday was partial.  I used the same test file several times, the<br>
> results degraded because of the test file was not fill to the full)<br>
><br>
> I try to remake the filesystem using the following command to increase the<br>
> internal log size , inode size and agcount num:<br>
> mkfs.xfs /dev/hioa2 -f -n size=64k -i size=2048,align=1 -d agcount=2045 -l<br>
> size=512m<br>
> but it has no help to the result.<br>
<br>
</span>Of course it won't. Turning random knobs without knowing what they<br>
do will not solve the problem. Indeed, if you're workload is<br>
performance limited because it is running out of log space, then<br>
*reducing the log size* will not solve the issue.<br>
<br>
Users who tweaking knobs without understanding what they do or how<br>
they affect the application is the leading cause of filesystem<br>
performance and reliability issues on XFS. Just don't do it - all<br>
you'll do is cause something to go wrong when you can least afford<br>
it to happen.<br>
<div class="HOEnZb"><div class="h5"><br>
Cheers,<br>
<br>
Dave.<br>
--<br>
Dave Chinner<br>
<a href="mailto:david@fromorbit.com">david@fromorbit.com</a><br>
</div></div></blockquote></div><br></div>