Skip to content
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

Remove max concurrent compaction limit #10102

Merged
merged 2 commits into from
Jul 18, 2018
Merged

Remove max concurrent compaction limit #10102

merged 2 commits into from
Jul 18, 2018

Conversation

e-dard
Copy link
Contributor

@e-dard e-dard commented Jul 18, 2018

This PR removes the maximum default limit of 4 concurrent compactions, introduced in #9204.

The idea in #9204 was to reduce IO utilisation on large systems with many cores,
and high write load. Often on these systems, disks were not scaled
appropriately to to the write volume, and while the write path could
keep up, compactions would saturate disks.

Further, in #9225 work was also done to reduce IO saturation by limiting the
compaction throughput. To some extent, both #9204 and #9225 work towards
solving the same problem.

We have recently begun to notice larger clusters suffering from
a buildup of un-compacted TSM data, because compactions are not keeping up. This is usually because they have scaled up the box for a higher write load, but the limit of 4 concurrent compactions has stayed in place. While users can
manually override the setting, it seems more user friendly if we remove
the limit by default, and set it manually in cases where compactions are
causing too much IO on larger boxes.

e-dard added 2 commits July 18, 2018 17:26
PR #9204 introduced a maximum default concurrent compaction limit of 4.
The idea was to reduce IO utilisation on large systems with many cores,
and high write load. Often on these systems, disks were not scaled
appropriately to to the write volume, and while the write path could
keep up, compactions would saturate disks.

In #9225 work was done to reduce IO saturation by limiting the
compaction throughput. To some extent, both #9204 and #9225 work towards
solving the same problem.

We have recently begun to notice larger clusters to suffer from
situations where compactions are not keeping up because they have been
scaled up, but the limit of 4 has stayed in place. While users can
manually override the setting, it seems more user friendly if we remove
the limit by default, and set it manually in cases where compactions are
causing too much IO on large boxes.
@e-dard e-dard added this to the 1.6.1 milestone Jul 18, 2018
@ghost ghost assigned e-dard Jul 18, 2018
@ghost ghost added the review label Jul 18, 2018
@e-dard e-dard merged commit 792886d into master Jul 18, 2018
@ghost ghost removed the review label Jul 18, 2018
@e-dard e-dard deleted the er-remove-comp-limit branch July 18, 2018 17:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants