-
Notifications
You must be signed in to change notification settings - Fork 503
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add a Tuning section to the documentation #624
Comments
@calmh i can draft a PR. The issue is rather ment for a discussion if you want to have this in the docs. |
I moved this over to the docs, as that's what it targets. There's a lot of things that make sense to document (and might already be documented), like progress updates. However I think unsafe tweaks should not be documented in a nice overview-like section as proposed: No amount of warning will stop people from still trying. That's why I'd not document fsync or other "not-to-be-named options there :) In general I believe in most cases knowing the knobs is a secondary problem: Most people never arrive at understanding what the limitation in their setup is. I'd consider a help article explaining how to diagnose typical problems more helpful. |
I would say that this is a good idea, but we should clearly distinguish between tuning purely for performance, and also tuning for reducing the resource usage, e.g. when using Syncthing on low-end hardware, etc. |
There are a few knobs we (or I) quite often recommend adjusting upwards or downwards for either very-small or very-large setups. I think we could have at least a couple of halfway general sections "to reduce resource usage at the cost of performance / features, lower and disable these things" and "to improve performance in large setups, increase these things and/or rate limit these other things". |
I think the following sections might make sense:
|
There are some things to consider which might positively affect syncthings performance. We should probably collect and curate this information in the documentation.
e.g safe options like putting the database on SSD storage or even unsafe ones with a proper warning like turning off fsync for initial sync.
IMHO it's better to have it in the documentation with proper warnings in place. People will always look for ways to speed things up and maybe we can steer those users away from questionable blog posts created years ago and instead point to the documentation.
The text was updated successfully, but these errors were encountered: