Comments (13)
my particular setup experienced no loss. The document is pretty clear that each setting needs to be tested and measured in an iterative manner.
from doc-ses.
Yes, we could use the "Basics" as basis ;)
from doc-ses.
Sure - so please add this information that "my particular setup experienced no loss" in read performance but....
from doc-ses.
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.
from doc-ses.
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.. ;-)-
from doc-ses.
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 :)
from doc-ses.
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.
from doc-ses.
I leave that up to @dmbyte to make that call.
from doc-ses.
Martin, if you have some different wording for the introductory paragraphs, feel free to suggest it.
from doc-ses.
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.
from doc-ses.
@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)
from doc-ses.
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.
from doc-ses.
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?
from doc-ses.
Related Issues (20)
- [doc] 10.3 Upgrading the MON, MGR, and OSD nodes - add bluestore_fsck_quick_fix_on_mount information HOT 2
- [doc] 6.8.7 Changing configuration options when copying or cloning images
- Document deploying services via Dasboard
- Fix external links HOT 1
- [doc] Issue in "Creating RBD images" HOT 1
- [doc] Issue in "Upgrade from SUSE Enterprise Storage 7 to 7.1" HOT 5
- [doc] Issue in "SSL for RGW in 7.1" - got an unexpected keyword argument 'rgw_frontend_ssl_key' HOT 3
- [doc] Add general section for offline OSD/service management and/or troubleshooting section
- [doc] Issue in "Removing nodes" HOT 3
- [doc] Issue in "10.1.2 Backing Up cluster configuration and data"
- Expired SSL certificates and how to renew them HOT 7
- [doc] Issue in "Replacing OSDs" HOT 1
- Hardware coniguration of SES documentation is slighly different from upstream. HOT 1
- [doc] 10.2 Upgrading the Salt Master - registry authentication not a list! HOT 1
- [doc] 16.7.2 Configuring the Prometheus Alertmanager for SNMP
- ceph mds deactivate fs_name:rank is an invalid command. HOT 4
- [doc] 16 Monitoring and alerting - Custom Grafana Certificates
- [doc] 3.5 Listing configured container images HOT 1
- [doc] 13.3 Removing nodes HOT 4
- [doc] 10.4 Enabling the Object Gateway management front-end HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from doc-ses.