[doc] 4.2.3 SSD Tuning - read got improved but what happened to write?

[Martin-Weiss]

4.2.3 SSD Tuning

https://documentation.suse.com/ses/6/single-html/ses-tuning/#id-1.5.3.3.5.5

---

Could we add some details on how much performance improvement during read this tuning achieved in the described test cluster and how much performance loss was on the write side by changing these settings?

[dmbyte]

my particular setup experienced no loss. The document is pretty clear that each setting needs to be tested and measured in an iterative manner.

[Martin-Weiss]

Sure - so please add this information that "my particular setup experienced no loss" in read performance but....

[asettle]

The only thing I can really do here is add a note that says "this was tested on a particular setup and experienced no loss" but I would recommend highly against that. The implied audience for this guide should understand that, and that is how we produce all product documentation.

[Martin-Weiss]

The problem I see is "implied audience" and "understand". I do not expect that everyone will read the whole document and not everyone will re-read the whole document with every change. But yes - if there is a general and clear disclaimer that all changes will have positive and negative effects in the beginning and all the changes are not tested nor supported by SUSE we might be fine.. ;-)-

[asettle]

I think it's relatively well stated in the introduction that, "This guide is intended to assist the reader in understanding the what and how of tuning a SUSE Enterprise Storage cluster. There are topics that are beyond the scope of this guide, and it is expected that there are further tweaks that may be performed to an individual cluster in order to achieve optimum performance in a particular end user environment."

https://documentation.suse.com/ses/6/single-html/ses-tuning/#tuning-intro

This is suitable for this use case :)

[Martin-Weiss]

I do not read this as "clear enough".

IMO we have to clearly state "any change can have one performance optimization while at the same point in time is reduces performance somewhere else. And non of the changes are recommended nor tested by SUSE so you must test and verify youself"

I really foresee tuned clusters based on this guide having performance or stability issues and customers complaining because they did not see a big red warning flag.

[asettle]

I leave that up to @dmbyte to make that call.

[dmbyte]

Martin, if you have some different wording for the introductory paragraphs, feel free to suggest it.

[Martin-Weiss]

I believe we need a big read warning disclaimer in the beginning covering a few thoughts:

Warning: Do not tune at all if there is not a really really good reason to do so. Defaults are tested and used in most environments. Any change for tuning will have one positive and several unknown negative impacts. With every patch and update/upgrade reset to default, test and tune again as with code changes and improvements most often bottlenecks are reduced and performance is optimized, too.
In case tuning does not give more than 10% better performance for one single use-case - do not tune at all. Choose the right hardware from the beginning on instead of trying the squeeze the last 1% out of the current setup. Best tuning is to get better and faster hardware. In general end-users only realize performance improvements from a "usability point if view" if they are +~50% or more.
Adding more disks and servers to the cluster is most often the faster and cheaper way to improve performance (compared to the human testing effort).
In case of support issues you might have to reset the adjusted tuneable to defaults and see if the problem can be reproduced without these adjustments.

[asettle]

@ajaeger would you mind reviewing the above proposed statement from Martin? Would this be suitable to include at the beginning of the guide? (for Tuning Guide only)

[ajaeger]

Do we have other tuning guides to look at and see whether they have a similar wording. Anything that can inspire us?

Let me propose a rewrite of what Martin said for the first paragraph:

Important: SUSE Enterprise Storage comes with tested defaults that are applicable to the majority of our customers. Do not make additional tuning unless you have a really good reason to do and understand the implications. Tuning changes often have both positive and negative impacts.
Keep in mind that SUSE Enterprise Storage is under development, we will add performance improvements as well, so that after and update or upgrade, performance can look different.
Therefore, with every patch and update/upgrade, test and tune again against the default settings .

We strongly advise to first choose the right hardware and architecture for your needs.

Not sure about the rest - or whether we need all of it.

[asettle]

Do we have other tuning guides to look at and see whether they have a similar wording. Anything that can inspire us?

At a really quick glance, only SLES: https://documentation.suse.com/sles/15-SP1/single-html/SLES-tuning/
And SLED: https://documentation.suse.com/sled/15-SP1/single-html/SLED-tuning/#book-sle-tuning

Both appear to have a common introduction called "Basics": https://documentation.suse.com/sles/15-SP1/single-html/SLES-tuning/#part-tuning-basics

This is something we could implement. I think that would solve quite a few of @Martin-Weiss 's reported issues. The files look common enough, that I think we could implement straight away. What do you think @dmbyte?

[ajaeger]

Yes, we could use the "Basics" as basis ;)