Dynamically vary the number of important worker threads in glusterfs based on load

[manojtpillai]

The number of threads employed in many areas in gluster is decided by tuning options, which need to be manually set by an admin if the default is not suitable for a specific use-case. Examples include values for client.event-threads and server.event-threads. While this manual tuning might be acceptable for some use cases, it is not likely to be tenable in environments where there are hundreds of volumes served out by gluster.

Instead, it would be good for gluster to have the intelligence to dynamically adjust the size of most of the important thread pools based on what's best for the workload. A test of the intelligence of such a solution would be to be able to match or come very close to the best performance result obtained through manual tuning.

[Recently, there has been some work on allowing multiple fuse reader threads, and fuse reader thread pool is another important pool where the dynamic approach can be employed; see: https://fosdem.org/2018/schedule/event/optimizing_sds/]

[stale]

Thank you for your contributions.
Noticed that this issue is not having any activity in last ~6 months! We are marking this issue as stale because it has not had recent activity.
It will be closed in 2 weeks if no one responds with a comment here.

[stale]

Closing this issue as there was no update since my last update on issue. If this is an issue which is still valid, feel free to open it.