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

storage: tick only raft groups which are not quiesced #26910

Merged
merged 1 commit into from
Jun 26, 2018

Conversation

spencerkimball
Copy link
Member

Previously we were ticking every replica, regardless of whether
or not it was part of a quiesced range, at each tick interval.
For 10,000 ranges this was noticeable. Each Replica.tick()
operation enqueues on a scheduler queue, is serviced by a
goroutine which calls time.Now(), and acquires several mutexes
before discovering it's quiesced and exiting.

We happen to have a carefully maintained map of unquiesced
replicas, which this change uses instead of all of the store's
replicas, when populating the rangeIDs slice used to enqueue
Raft ticks.

Release note (performance improvement): less CPU utilization
with many ranges.

Previously we were ticking every replica, regardless of whether
or not it was part of a quiesced range, at each tick interval.
For 10,000 ranges this was noticeable. Each `Replica.tick()`
operation enqueues on a scheduler queue, is serviced by a
goroutine which calls `time.Now()`, and acquires several mutexes
before discovering it's quiesced and exiting.

We happen to have a carefully maintained map of unquiesced
replicas, which this change uses instead of all of the store's
replicas, when populating the `rangeIDs` slice used to enqueue
Raft ticks.

Release note (performance improvement): less CPU utilization
with many ranges.
@spencerkimball spencerkimball requested review from bdarnell and a team June 21, 2018 22:22
@cockroach-teamcity
Copy link
Member

This change is Reviewable

@petermattis
Copy link
Collaborator

FYI, @bdarnell previously made this change (he introduced the unquiescedReplicas map), but had to revert it due to bugs in maintenance of that map. I think those bugs have been fixed, but @bdarnell would know for certain.


Review status: :shipit: complete! 0 of 0 LGTMs obtained


Comments from Reviewable

@bdarnell
Copy link
Contributor

:lgtm:

Yes, this reverts #26291. I didn't find any other bugs in the use of this map so it's time to give this another shot.


Review status: :shipit: complete! 0 of 0 LGTMs obtained (and 1 stale)


Comments from Reviewable

@nvanbenschoten
Copy link
Member

@bdarnell why do you expect this to work now? Is the theory that #26257 wasn't caused by #24956, but instead likely by #26297?

@bdarnell
Copy link
Contributor

I believe #26257 was caused by #24956 and fixed by #26297.

@nvanbenschoten
Copy link
Member

Ok, I'll merge this for Spencer then while he's out.

bors r=bdarnell

craig bot pushed a commit that referenced this pull request Jun 26, 2018
26910: storage: tick only raft groups which are not quiesced r=bdarnell a=spencerkimball

Previously we were ticking every replica, regardless of whether
or not it was part of a quiesced range, at each tick interval.
For 10,000 ranges this was noticeable. Each `Replica.tick()`
operation enqueues on a scheduler queue, is serviced by a
goroutine which calls `time.Now()`, and acquires several mutexes
before discovering it's quiesced and exiting.

We happen to have a carefully maintained map of unquiesced
replicas, which this change uses instead of all of the store's
replicas, when populating the `rangeIDs` slice used to enqueue
Raft ticks.

Release note (performance improvement): less CPU utilization
with many ranges.

Co-authored-by: Spencer Kimball <[email protected]>
@craig
Copy link
Contributor

craig bot commented Jun 26, 2018

Build succeeded

@craig craig bot merged commit 296629c into cockroachdb:master Jun 26, 2018
@spencerkimball spencerkimball deleted the tick-unquiesced-only branch October 22, 2018 01:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants