-
Notifications
You must be signed in to change notification settings - Fork 5.9k
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
topsql: use new cache policy for top-n SQL #25744
Conversation
@dragonly @breeswish PTAL |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Suggest adding a holistic description about the 2-round top N eviction algorithm in the code comments.
Rest LGTM.
We need to adjust back to maximum 200 statements if we switch the evict policy. |
Also do we need to merge with pingcap/tipb#233? |
Signed-off-by: crazycs <crazycs520@gmail.com>
Nice catch, already change
Ok, already update the latest tipb. |
util/topsql/reporter/reporter.go
Outdated
records = append(records, v) | ||
} | ||
var evicted []*dataPoints | ||
records, evicted = tsr.getTopNDataPoints(records) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it is fine to not to evict it here, since immediately after that the map will be dropped entirely. Maybe we can simply ignore them at the report time?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This evict is use to avoid report useless SQL/Plan. And since the data structure of evicted
is a slice, it's a little bit of trouble for ignore them at the report time, since we should traverse the slice for each SQL/Plan record.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about traversing the records and generate a "retain map" first, then iterate all records in the hash map and send records that only in the retain map?
Signed-off-by: crazycs <crazycs520@gmail.com>
Signed-off-by: crazycs <crazycs520@gmail.com>
…into new-top-sql-cache
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
@dragonly: Thanks for your review. The bot only counts approvals from reviewers and higher roles in list, but you're still welcome to leave your comments. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the ti-community-infra/tichi repository. |
util/topsql/reporter/reporter.go
Outdated
// When `reportDataChan` receives something, there could be ongoing `RegisterSQL` and `RegisterPlan` running, | ||
// who writes to the data structure that `data` contains. So we wait for a little while to ensure that | ||
// these writes are finished. | ||
time.Sleep(time.Millisecond * 100) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why don't we need this any more?
Signed-off-by: crazycs <crazycs520@gmail.com>
@tangenta: Thanks for your review. The bot only counts approvals from reviewers and higher roles in list, but you're still welcome to leave your comments. In response to this: Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the ti-community-infra/tichi repository. |
[REVIEW NOTIFICATION] This pull request has been approved by:
To complete the pull request process, please ask the reviewers in the list to review by filling The full list of commands accepted by this bot can be found here. Reviewer can indicate their review by submitting an approval review. |
/merge |
This pull request has been accepted and is ready to merge. Commit hash: 3809ae7
|
/merge |
This pull request has been accepted and is ready to merge. Commit hash: 0d12420
|
@crazycs520: Your PR was out of date, I have automatically updated it for you. At the same time I will also trigger all tests for you: /run-all-tests If the CI test fails, you just re-trigger the test that failed and the bot will merge the PR for you after the CI passes. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the ti-community-infra/tichi repository. |
What problem does this PR solve?
#24875 implement the TOP-SQL feature. But the cache policy was not very good. Here is an example:
suppose the config is:
At timestamp_1: the SQL and CPU time is:
At timestamp_2: the SQL and CPU time is:
At timestamp_3: the SQL and CPU time is:
As you can see, between timestamp_1 and timestamp_3, the total SQL and CPU time is:
So, between timestamp_1 and timestamp_3, the final TOP-2 SQL should be:
But before this PR, the final Top-2 SQL is:
In this PR, the final TOP-2 SQL is:
What is changed and how it works?
Reference: https://github.com/breeswish/topn-stores
This PR uses a new cache policy, which saves each Top-N SQL for each timestamp and calculate the final Top-N SQL between the report interval.
This PR also change the default value of
tidb_top_sql_max_statement_count
variable from 2000 to 200. Since 200 is big enough for one second.Related changes
pingcap/docs
/pingcap/docs-cn
:Check List
Tests
Side effects
In the default config:
In the best case, doesn't have too much kind of SQL, the memory usage enlarge 1X. The memory usage is 200*36K * 2 =
14MB.
In the worse case, each second has many different SQL digest, the memory will become 200 * 36K * 60 = 422MB.
Release note