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

server, schedule: limiter record operator count group by store #1051

Closed
wants to merge 5 commits into from

Conversation

Connor1996
Copy link
Member

@Connor1996 Connor1996 commented May 7, 2018

limiter records operator count grouping by store

@Connor1996 Connor1996 changed the title server, schedule: limiter record count group by store server, schedule: limiter record operator count group by store May 7, 2018
@Connor1996 Connor1996 requested review from disksing and nolouch May 7, 2018 09:53
@siddontang
Copy link
Contributor

please add a description of the PR.

@@ -520,7 +518,7 @@ func (c *coordinator) removeOperator(op *schedule.Operator) {
func (c *coordinator) removeOperatorLocked(op *schedule.Operator) {
regionID := op.RegionID()
delete(c.operators, regionID)
c.limiter.UpdateCounts(c.operators)
c.limiter.RemoveOperator(op)
Copy link
Contributor

@nolouch nolouch May 8, 2018

Choose a reason for hiding this comment

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

refer to #874, we meet some not synchronized cases so change to updatecounts.

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 noticed that. But now we have a background goroutine to check all operators, all path will reach RemoveOperator() or AddOperator(). it's unlikely not synchronized.

Copy link
Contributor

Choose a reason for hiding this comment

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

I vote for update limiter using all operators too.

} else {
c.addOperators(op...)
}
if ops := s.Schedule(c.cluster, opInfluence); ops != nil {
Copy link
Contributor

Choose a reason for hiding this comment

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

ops != nil -> len(ops) > 0.

}

operatorCounter.WithLabelValues(op.Desc(), "create").Inc()
return true
log.Warnf("add operator %v on nonexistent region %d", op, regionID)
Copy link
Contributor

Choose a reason for hiding this comment

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

nonexistent -> absent?

@@ -36,6 +36,7 @@ type OperatorStep interface {
fmt.Stringer
IsFinish(region *core.RegionInfo) bool
Influence(opInfluence OpInfluence, region *core.RegionInfo)
InvolvedStores(region *core.RegionInfo) []uint64
Copy link
Contributor

Choose a reason for hiding this comment

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

How about AffectStores?

Copy link
Contributor

Choose a reason for hiding this comment

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

It's kind weird to have a region parameter here. I think you can add a OriginLeader field to operators that need original leader id to return affect stores.

@@ -520,7 +518,7 @@ func (c *coordinator) removeOperator(op *schedule.Operator) {
func (c *coordinator) removeOperatorLocked(op *schedule.Operator) {
regionID := op.RegionID()
delete(c.operators, regionID)
c.limiter.UpdateCounts(c.operators)
c.limiter.RemoveOperator(op)
Copy link
Contributor

Choose a reason for hiding this comment

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

I vote for update limiter using all operators too.

@Connor1996
Copy link
Member Author

@disksing @nolouch PTAL

@Connor1996 Connor1996 closed this Aug 14, 2018
@Connor1996 Connor1996 deleted the store-limiter branch August 14, 2018 05:46
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.

4 participants