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

Optimize the performance of bidirectional synchronous update table of _drainer_repl_mark #903

Merged
merged 11 commits into from
Feb 24, 2020

Conversation

freemindLi
Copy link
Contributor

@freemindLi freemindLi commented Feb 17, 2020

What problem does this PR solve?

1.Optimize the performance of bidirectional synchronous update table of _drainer_repl_mark

What is changed and how it works?

The number of channel related records in the mark table is initialized according to the number of worker "count. During synchronization, each syncer operates one piece of data, which will not cause multithreading to update one record, resulting in synchronization performance bottleneck of mark table.

Check List

Tests

  • Unit test
  • Integration test
  • Manual test (add detailed scripts or steps below)
  • No code

Code changes

  • Has exported function/method change
  • Has exported variable/fields change
  • Has interface methods change
  • Has persistent data change

Side effects

  • Possible performance regression
  • Increased code complexity
  • Breaking backward compatibility

Related changes

  • Need to cherry-pick to the release branch
  • Need to update the documentation
  • Need to update the tidb-ansible repository
  • Need to be included in the release note

@freemindLi
Copy link
Contributor Author

/run-all-tests

1 similar comment
@freemindLi
Copy link
Contributor Author

/run-all-tests

drainer/loopbacksync/loopbacksync.go Show resolved Hide resolved
pkg/loader/executor.go Outdated Show resolved Hide resolved
pkg/loader/executor.go Outdated Show resolved Hide resolved
@freemindLi
Copy link
Contributor Author

/run-all-tests

@WangXiangUSTC
Copy link
Contributor

LGTM, @july2993 PTAL

Copy link
Contributor

@july2993 july2993 left a comment

Choose a reason for hiding this comment

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

Is there any test result

pkg/loader/executor.go Show resolved Hide resolved
drainer/loopbacksync/loopbacksync.go Outdated Show resolved Hide resolved
@freemindLi
Copy link
Contributor Author

/run-all-tests

Copy link
Contributor

@july2993 july2993 left a comment

Choose a reason for hiding this comment

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

rest LGTM

var args []interface{}
sql := fmt.Sprintf("update %s set %s=%s+1 where %s=? and %s=? limit 1;", loopbacksync.MarkTableName, loopbacksync.Val, loopbacksync.Val, loopbacksync.ID, loopbacksync.ChannelID)
args = append(args, e.addIndex(), e.info.ChannelID)
_, err1 := tx.autoRollbackExec(sql, args...)
Copy link
Contributor

Choose a reason for hiding this comment

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

maybe we can check the affect rows to make sure we do update some row?

for id := 0; id < e.workerCount; id++ {
args = append(args, id, e.info.ChannelID, status, channel)
}
tx, err := e.begin()
Copy link
Contributor

Choose a reason for hiding this comment

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

in e.begin() it will updateMark it's confusing doing this.
suggest writing a func to accepte a *sql.DB directly to initMarkTable

@sre-bot
Copy link

sre-bot commented Feb 24, 2020

/run-all-tests

@july2993 july2993 closed this Feb 24, 2020
@july2993 july2993 reopened this Feb 24, 2020
@july2993 july2993 merged commit 6faf114 into pingcap:master Feb 24, 2020
@sre-bot
Copy link

sre-bot commented Feb 24, 2020

cherry pick to release-3.0 in PR #909

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.

4 participants