Skip to contentSkip to conversation

Valid Benchmark Value & Methods

DISCUSSION Dewangga 3 participants 7 messages May 7, 2015 – May 8, 2015

lore
Share & tools
lore

Dewangga

author
#0 lore raw

-----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
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs

#1 lore raw

Am Donnerstag, 7. Mai 2015, 18:24:09 schrieb Dewangga:

Quoted 9 lines

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,

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

_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
#2 lore raw
In reply to Dewangga

Am Donnerstag, 7. Mai 2015, 18:24:09 schrieb Dewangga:

Quoted 9 lines

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.

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

_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
author
#3 lore raw

-----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?

Quoted 12 lines · Martin Steigerwald

Am Donnerstag, 7. Mai 2015, 18:24:09 schrieb Dewangga:

Quoted 10 lines

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?

Quoted 7 lines

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
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs

#4 lore raw

Am Donnerstag, 7. Mai 2015, 19:16:02 schrieb Dewangga:

Quoted 7 lines

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.

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

_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
#5 lore raw
In reply to Dewangga
Quoted 6 lines · 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?

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

Quoted 1 line

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
$
Quoted 2 lines

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.

Signature · 7 lines
Dave Chinner
[email protected]

_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
#6 lore raw

Hello Dave!

Quoted 10 lines · Dave Chinner
Quoted 6 lines · 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?

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

Quoted 9 lines
Quoted 1 line

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.

Quoted 23 lines
Quoted 2 lines

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.

Quoted 8 lines

(*) 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
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs