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

raftstore: move get_region_approximate_size to split check worker #9081

Merged
merged 28 commits into from
Dec 4, 2020
Merged

raftstore: move get_region_approximate_size to split check worker #9081

merged 28 commits into from
Dec 4, 2020

Conversation

sleepymole
Copy link
Member

@sleepymole sleepymole commented Nov 20, 2020

What problem does this PR solve?

When peer's approximate size or keys is none,region heartbeat need to directly read rocksdb to get size and keys. It will affect other region's heartbeat. This PR move get_region_approximate_size and get_region_approximate_keys to split worker's thread so that most regions' heartbeat will go smoothly.

What is changed and how it works?

What's Changed:

Add a new task type GetRegionApproximateSizeAndKeys to split checker. For this task, split check worker will read rocksdb to get size and keys, and execute an callback.

Check List

Tests

  • Unit test
  • Integration test

Release note

  • No release note.

@sleepymole sleepymole changed the title move get_region_approximate_size to split check worker raftstore: move get_region_approximate_size to split check worker Nov 20, 2020
@Little-Wallace Little-Wallace added sig/raft Component: Raft, RaftStore, etc. component/pd-client Component: pd status/WIP labels Nov 20, 2020
Copy link
Contributor

@Little-Wallace Little-Wallace left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@ti-srebot
Copy link
Contributor

@Little-Wallace, Thanks for your review. The bot only counts LGTMs from Reviewers and higher roles, but you're still welcome to leave your comments. See the corresponding SIG page for more information. Related SIGs: raft(slack),scheduling(slack).

Comment on lines 2133 to 2151
// Roughly estimate the size and keys and then let split checker to update it.
self.fsm.peer.approximate_size =
self.fsm.peer.approximate_size.map(|x| x / new_region_count);
self.fsm.peer.approximate_keys =
self.fsm.peer.approximate_keys.map(|x| x / new_region_count);
if let Err(e) = self.ctx.split_check_scheduler.schedule(
SplitCheckTask::GetRegionApproximateSizeAndKeys {
region: self.fsm.peer.region().clone(),
pending_tasks: Arc::new(AtomicU64::new(1)),
cb: Box::new(move |_, _| {}),
},
) {
error!(
"failed to schedule split check task";
"region_id" => self.fsm.region_id(),
"peer_id" => self.fsm.peer_id(),
"err" => ?e,
);
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If it's not leader, this task is very wasteful and the approximate_size & approximate_key are no need to be updated.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And I think self.fsm.peer.heartbeat_pd should be called here if it's a leader.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If it's not leader, this task is very wasteful and the approximate_size & approximate_key are no need to be updated.

Oh, I didn't notice here in the last update. I will add some check later.

And I think self.fsm.peer.heartbeat_pd should be called here if it's a leader.

heartbeat_pd is called a few lines before here.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@gengliqi I have updated. PTAL.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we can move these codes to the upper if is_leader.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have updated again. Please have a look.

Comment on lines 2101 to 2102
// It's not correct anymore, so set it to None to let split checker update it.
self.fsm.peer.approximate_size = None;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmmm, I think we should remove these lines?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is for non-leader peers. As the previous comment says, the size is not correct anymore.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we use the estimated size for non-leader peers but not to update it size immediately, I don't know whether there are
potential risks?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If self.fsm.peer.approximate_size is none, the latter estimated_size is always none.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is no potential risk because the approximate_size and approximate_keys are meaningful only on the leader.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should it be meaningful if a follower becomes a leader?

If self.fsm.peer.approximate_size is none, the latter estimated_size is always none.

Sorry, I make a mistake here.

Comment on lines +363 to +370
let _ = self.router.send(
region.get_id(),
CasualMessage::RegionApproximateSize { size },
);
let _ = self.router.send(
region.get_id(),
CasualMessage::RegionApproximateKeys { keys },
);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These data may be sent to a different peer instead of the expected one in rare circumstances. I find it is the same as the original code of RegionApproximateSize/Keys, which also has this problem. It seems that the side effect is little but it's risky. I will file an issue for that.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds like a potential risk. Please let me know what caused it to happen when you are free.

@ti-srebot
Copy link
Contributor

@gengliqi, Thanks for your review. The bot only counts LGTMs from Reviewers and higher roles, but you're still welcome to leave your comments. See the corresponding SIG page for more information. Related SIG: scheduling(slack).

@gengliqi gengliqi added the sig/raft Component: Raft, RaftStore, etc. label Dec 4, 2020
@gengliqi
Copy link
Member

gengliqi commented Dec 4, 2020

/lgtm

@ti-srebot ti-srebot added status/LGT2 Indicates that a PR has LGTM 2. and removed status/LGT1 Indicates that a PR has LGTM 1. labels Dec 4, 2020
@gengliqi
Copy link
Member

gengliqi commented Dec 4, 2020

/merge

@ti-srebot ti-srebot added the status/can-merge Indicates a PR has been approved by a committer. label Dec 4, 2020
@ti-srebot
Copy link
Contributor

/run-all-tests

@ti-srebot ti-srebot merged commit e8e008d into tikv:master Dec 4, 2020
ti-srebot pushed a commit to ti-srebot/tikv that referenced this pull request Dec 4, 2020
@ti-srebot
Copy link
Contributor

cherry pick to release-4.0 in PR #9185

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component/pd-client Component: pd needs-cherry-pick-release-4.0 Type: Need cherry pick to release 4.0 sig/raft Component: Raft, RaftStore, etc. status/can-merge Indicates a PR has been approved by a committer. status/LGT2 Indicates that a PR has LGTM 2.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants