max_subcompactions ignores max_background_jobs

[mdcallag]

Note: Please use Issues only for bug reports. For questions, discussions, feature requests, etc. post to dev group: https://groups.google.com/forum/#!forum/rocksdb or https://www.facebook.com/groups/rocksdb.dev

Expected behavior

I want max_background_jobs to limit the number of threads used for compactions, flushes and subcompactions.

Actual behavior

max_background_jobs sets the number of threads to use for background compactions and flushes. But these are ignored by subcompactions. With subcompactions, the number of threads per subcompaction is set by max_subcompactions and the total number of threads that can be running at any point is: max_background_jobs * max_subcompactions

(See here) for the code that creates new threads for compactions.

Steps to reproduce the behavior

[briantkim93]

Hey guys, I'm new to the project. How critical is this bug? Is it of a low priority enough for me to use it as my ramp up task into the project?

[ajkr]

Hi, you are welcome to give it a try in the sense that it shouldn't conflict with anyone else's efforts (Jay can correct this if I'm mistaken). I am a bit less sure about its suitability as a ramp-up task, though, as there are a couple tricky aspects we don't have answers to, despite knowing this problem for a long time. One is how to make this change without causing surprise to existing use cases since it will reduce maximum parallelism. Another is how to decide how many subcompactions to split a compaction into within the range [1, max_subcompactions]. The latter problem is difficult because splitting more would reduce parallelism available to other compactions (including ones that we might not know about yet at the time of splitting!).

@jay-zhuang may have ideas on the above based on our past discussions.

[briantkim93]

Thanks Andrew, any suggestions for a noob ramp up task?

[ajkr]

@briantkim93 Perhaps #7599 could be a good starter task?

[briantkim93]

Awesome, thanks @ajkr I'm going to work on it