Valid Benchmark Value & Methods

Valid Benchmark Value & Methods

[Dewangga]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello!

I'm new on XFS and curious about any tune/tweak regarding XFS
filesystem on any raid array, non-raid, ssd or non-ssd. But, is there
any valid value to determine about the performance? At least valid
benchmark result (eg. using fio with some parameters, or any method).

Then, about bsize, sectsz, etc, is there any wiki/guidelines how to
set them on a right way?

Regards,
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)

iQEcBAEBAgAGBQJVS0tWAAoJEF1+odKB6YIxjcUIAJeTF8Bg810/lwqo8RCiuyLI
UyAJJIkzSIdWk6JdGiPfYqWptCXJs7jPc66yKTJNVVdPQ0z0H5mBWDHb2qCe0/lO
lSsGhBinyVaGzssVWYJjSlpee0h1nievBdCOGiqMU/W5uz/ZGR1WkK9gnu344BKb
3Xpt30oG3l+qTrswfqGDbyeU9X4ruUfi4bKYp+pzjELpxpVggDud+hjTsF44z422
+cpoeiHP6SsI/Nj2RUcXY+lP9VwemjbeG6a3rWRvQU4uwJOioy/QgnAnajDmjFaV
GmmGYL5n35xy2IxE2b2MqWDcA+vvTYMf8P9CEEHoC2Rg+Iv9zx1HghBvjGiCGRM=
=1mdR
-----END PGP SIGNATURE-----

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

Re: Valid Benchmark Value & Methods

[Martin Steigerwald]

Am Donnerstag, 7. Mai 2015, 18:24:09 schrieb Dewangga:
> Hello!
> 
> I'm new on XFS and curious about any tune/tweak regarding XFS
> filesystem on any raid array, non-raid, ssd or non-ssd. But, is there
> any valid value to determine about the performance? At least valid
> benchmark result (eg. using fio with some parameters, or any method).
> 
> Then, about bsize, sectsz, etc, is there any wiki/guidelines how to
> set them on a right way?

Read and understand:

http://xfs.org/index.php/XFS_FAQ#Q:_I_want_to_tune_my_XFS_filesystems_for_.3Csomething.3E

then, if you want any concrete recommendation ask about your intended setup.

Thanks,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

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

Re: Valid Benchmark Value & Methods

[Martin Steigerwald]

Am Donnerstag, 7. Mai 2015, 18:24:09 schrieb Dewangga:
> Hello!
> 
> I'm new on XFS and curious about any tune/tweak regarding XFS
> filesystem on any raid array, non-raid, ssd or non-ssd. But, is there
> any valid value to determine about the performance? At least valid
> benchmark result (eg. using fio with some parameters, or any method).
> 
> Then, about bsize, sectsz, etc, is there any wiki/guidelines how to
> set them on a right way?

Ok, one additional thing:

Use recent kernel and userspace utilities.

Cause defaults are updated sometimes and with recent tools you get best out 
of box experience.

-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

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

Re: Valid Benchmark Value & Methods

[Dewangga]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello Martin,
Thanks for your reply, yes I've read that link, but another question,
is noatime,nodiratime,etc still valid for performance tuning guidance?
Even the default mount options only "rw,inode64,seclabel,attr2".

Is it still increase the performance if the additional mount options
added?

On 5/7/2015 18:49, Martin Steigerwald wrote:
> Am Donnerstag, 7. Mai 2015, 18:24:09 schrieb Dewangga:
>> Hello!
>> 
>> I'm new on XFS and curious about any tune/tweak regarding XFS 
>> filesystem on any raid array, non-raid, ssd or non-ssd. But, is
>> there any valid value to determine about the performance? At
>> least valid benchmark result (eg. using fio with some parameters,
>> or any method).
>> 
>> Then, about bsize, sectsz, etc, is there any wiki/guidelines how
>> to set them on a right way?
> 
> Ok, one additional thing:
> 
> Use recent kernel and userspace utilities.
> 
> Cause defaults are updated sometimes and with recent tools you get
> best out of box experience.
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (MingW32)

iQEcBAEBAgAGBQJVS1eBAAoJEF1+odKB6YIxyQwH/Am1bC+YhydmoWOknAMgjrEI
3mTmeUu0O/p90+DsXPS04zjht18XzsZKVTASVraPgPcrgzoqlHtHflK55++YIKp2
SLbFI2IexNLNbffyUgM7NCCpEjKZLkN8v4eNP2ylSgQqK4DTzwWPDypF16FX/rlc
2WuvQINR345i8rwjPryMbZAHiCem3ewYssx34jfH5NPh9CoRo1mnuFCEHzz9IG3L
4u0Z7zTKHZQPDaRzC3MVO5wOZNelnWXcP2TwiDJF3LgdEzWTinQGthEKy5ytSPPI
xRZvJnzUvXWt6JNuWCUjtIUV3ODhBctfkk200wvMUyBdQg7Zo+OiXXOyaA24GsU=
=wHBL
-----END PGP SIGNATURE-----

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

Re: Valid Benchmark Value & Methods

[Martin Steigerwald]

Am Donnerstag, 7. Mai 2015, 19:16:02 schrieb Dewangga:
> Hello Martin,
> Thanks for your reply, yes I've read that link, but another question,
> is noatime,nodiratime,etc still valid for performance tuning guidance?
> Even the default mount options only "rw,inode64,seclabel,attr2".
> 
> Is it still increase the performance if the additional mount options
> added?

noatime implies nodiratime as far as I know.

And yes, it can help for databases for example. I think official 
recommendation for MySQL and PostgreSQL is to use noatime. There is a post 
by Theodore T´so somewhere about make clean workload on Ext4 with noatime, 
relatime and strictatime handling and only noatime considerably reduced the 
amount of writes.

noatime is a generic tuning option which can help with other filesystems as 
well.

-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

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

Re: Valid Benchmark Value & Methods

[Dave Chinner]

On Thu, May 07, 2015 at 07:16:02PM +0700, Dewangga wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hello Martin,
> Thanks for your reply, yes I've read that link, but another question,
> is noatime,nodiratime,etc still valid for performance tuning guidance?

You may have read it, but I don't think it sunk in....

> Even the default mount options only "rw,inode64,seclabel,attr2".

Where's relatime(*)? That's been a default for a lot longer than
inode64...

$ grep "root " /proc/mounts
/dev/root / xfs rw,relatime,attr2,inode64,noquota 0 0
$

> Is it still increase the performance if the additional mount options
> added?

Depends on your workload, which is more critical to understand than
anything else. Why? because it's your workload that is going to
determine if twiddling a knob is going to have any effect on
performance. Once you understand the workload and what the
bottlenecks are, then you can look at what knobs the filesystem
provides to alleviate those bottlenecks.

IOWs, asking the question "how do I tune my filesystem for best
performance" is, fundamentally, the wrong way to go about obtaining
best filesystem performance.  The questions that need to be answered
are "what bottlenecks does my application have?" followed by "what
does the filesystem provide to alleviate those bottlenecks".

i.e. understand the problem you need to solve *before* you try to
solve it, otherwise you "solve" the wrong problem...

Cheers,

Dave.

(*) An example of exactly what I'm talking abou there. The default
option of relatime gets >95% of the benefit of noatime onmost
workloads compared to the old strictatime behaviour, but unlike
noatime it still retains atime updates. IOWs there's a pretty good
chance that noatime has little measurable impact on your
application's performance, but understanding and benchmarking
anything other than your application won't tell you this.

-- 
Dave Chinner
david@fromorbit.com

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

Re: Valid Benchmark Value & Methods

[Dewangga Bachrul Alam]

Hello Dave!



On 05/08/2015 05:55 AM, Dave Chinner wrote:
> On Thu, May 07, 2015 at 07:16:02PM +0700, Dewangga wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Hello Martin,
>> Thanks for your reply, yes I've read that link, but another question,
>> is noatime,nodiratime,etc still valid for performance tuning guidance?
> 
> You may have read it, but I don't think it sunk in....
> 
>> Even the default mount options only "rw,inode64,seclabel,attr2".
> 
> Where's relatime(*)? That's been a default for a lot longer than
> inode64...
> 
> $ grep "root " /proc/mounts
> /dev/root / xfs rw,relatime,attr2,inode64,noquota 0 0
> $
> 

I forgot write it, but relatime still exists on default mount options.

>> Is it still increase the performance if the additional mount options
>> added?
> 
> Depends on your workload, which is more critical to understand than
> anything else. Why? because it's your workload that is going to
> determine if twiddling a knob is going to have any effect on
> performance. Once you understand the workload and what the
> bottlenecks are, then you can look at what knobs the filesystem
> provides to alleviate those bottlenecks.
> 
> IOWs, asking the question "how do I tune my filesystem for best
> performance" is, fundamentally, the wrong way to go about obtaining
> best filesystem performance.  The questions that need to be answered
> are "what bottlenecks does my application have?" followed by "what
> does the filesystem provide to alleviate those bottlenecks".
> 
> i.e. understand the problem you need to solve *before* you try to
> solve it, otherwise you "solve" the wrong problem...
> 
> Cheers,
> 
> Dave.
> 
> (*) An example of exactly what I'm talking abou there. The default
> option of relatime gets >95% of the benefit of noatime onmost
> workloads compared to the old strictatime behaviour, but unlike
> noatime it still retains atime updates. IOWs there's a pretty good
> chance that noatime has little measurable impact on your
> application's performance, but understanding and benchmarking
> anything other than your application won't tell you this.
> 

Okay dave, got it. Standard optimize performance is add mount options
like noatime and nodiratime, any additional performance tune is depends
on the apps and the workloads.

Thanks anyway :)

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