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

statistics: ease the impact of stats feedback on cluster (#15503) #18772

Merged
merged 3 commits into from
Jul 27, 2020

Conversation

ti-srebot
Copy link
Contributor

cherry-pick #15503 to release-4.0


What problem does this PR solve?

Fix #17478

Problem Summary:

Statistics feedback would impose periodical read/write burden on the database. Each TiDB would dump the feedbacks collected on this instance into TiKV every 10 mins, and the stats owner TiDB instance would read the feedbacks dumped every 15 seconds. If the stats owner TiDB finds there are new feedbacks from TiKV, it would merge the feedbacks with statistics in cache, then dump all these updated statistics into TiKV. This dump operation is pretty heavy if there are bunches of feedbacks on bunches of columns/indexes, since it can be treated as a light-weight ANALYZE on a lot of tables.

What is changed and how it works?

What's Changed:

First, reduce the amount of feedbacks generated on each TiDB by:

  • decreasing default MaxQueryFeedbackCount;
  • discarding feedbacks which have too small error rate, or too small scanned row count;
  • discarding feedbacks which have overlapped ranges on the same index/column;

Second, merge multiple insert/update/delete statements of dumping statistics into single ones, to reduce the unnecessary function call stacks and RPCs.

How it Works:

Obviously, the first change can flow-control the statistics feedback mechanism fundamentally, but we may lose some stats accuracy incurred by feedback theoretically. The second change combines several small transactions into a big one, since we have controlled the amount of feedbacks using the first change, I guess this bigger transaction is supposed not to be a problem. However, the bigger transaction should have higher chances of write conflict, and it makes code harder to read, so I haven't made up my mind to keep it or not actually.

Related changes

  • Need to cherry-pick to the release branch: if this PR is experimentally effective, we should apply it in release branches.

Check List

Tests

Side effects

  • Performance regression
    • Possible stats accurateness lose may cause potential query performance regression.

Release note

  • Ease the impact of stats feedback on cluster

Signed-off-by: ti-srebot <ti-srebot@pingcap.com>
@ti-srebot
Copy link
Contributor Author

/run-all-tests

@qw4990
Copy link
Contributor

qw4990 commented Jul 24, 2020

/run-all-tests

Copy link
Contributor

@lzmhhh123 lzmhhh123 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 ti-srebot added the status/LGT1 Indicates that a PR has LGTM 1. label Jul 27, 2020
Copy link
Contributor

@qw4990 qw4990 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 ti-srebot added status/LGT2 Indicates that a PR has LGTM 2. and removed status/LGT1 Indicates that a PR has LGTM 1. labels Jul 27, 2020
@eurekaka
Copy link
Contributor

/merge

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

/run-all-tests

@ti-srebot
Copy link
Contributor Author

@ti-srebot merge failed.

@eurekaka
Copy link
Contributor

/merge

@ti-srebot
Copy link
Contributor Author

/run-all-tests

@ti-srebot
Copy link
Contributor Author

@ti-srebot merge failed.

@eurekaka
Copy link
Contributor

/run-common-test

@eurekaka eurekaka merged commit b59b532 into pingcap:release-4.0 Jul 27, 2020
@eurekaka eurekaka deleted the release-4.0-a99fdc098cb3 branch July 27, 2020 06:36
@imtbkcat imtbkcat modified the milestones: v4.0.4, v4.0.5 Jul 28, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component/config component/statistics epic/query-feedback-GA sig/execution SIG execution status/can-merge Indicates a PR has been approved by a committer. status/LGT2 Indicates that a PR has LGTM 2. type/enhancement The issue or PR belongs to an enhancement. type/4.0-cherry-pick
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants