Yes.. .it's not currently possible :)
I think it should be.
Say the IO on your C* is at 60% utilization.
If you do a repair, this would require 120% utilization obviously not
possible, so now your app is down / offline until the repair finishes.
If you could throttle repair separately this woul
On Mon, Oct 19, 2015 at 9:30 AM, Kevin Burton wrote:
> I think the point I was trying to make is that on highly loaded boxes,
> repair should take lower priority than normal compactions.
>
You can manually do this by changing the thread priority of compaction
threads which you somhow identify a
I think the point I was trying to make is that on highly loaded boxes,
repair should take lower priority than normal compactions.
Having a throttle on *both* doesn't solve the problem.
So I need a
setcompactionthroughput
and a
setrepairthroughput
and total througput would be the sum of both.
The validation compaction part of repair is susceptible to the compaction
throttling knob `nodetool getcompactionthroughput`
/ `nodetool setcompactionthroughput` and you can use that to tune down the
resources that are being used by repair.
Check out this post by driftx on advanced repair techniqu
I'm doing a big nodetool repair right now and I'm pretty sure the added
overhead is impacting our performance.
Shouldn't you be able to throttle repair so that normal compactions can use
most of the resources?
--
We’re hiring if you know of any awesome Java Devops or Linux Operations
Engineers!
