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 handle read in large cluster #37724

Closed
you06 opened this issue Sep 8, 2022 · 0 comments · Fixed by #37725
Closed

Optimize handle read in large cluster #37724

you06 opened this issue Sep 8, 2022 · 0 comments · Fixed by #37725
Labels
type/enhancement The issue or PR belongs to an enhancement.

Comments

@you06
Copy link
Contributor

you06 commented Sep 8, 2022

Enhancement

Background

TiDB indexes data with global index, which lead to a problem that when data grows, some the required data may be sharded into many regions. One of those problem is when reading with indexlookup executor, the table scan may be divided into many coprocessor tasks.

bad-indexlookup

As the figure shows, the continuous index range may point to many discontinuous handle ranges in indexlookup executor. The default tidb_distsql_scan_concurrency is 15, with a big number of handle read tasks, the concurrency is not sufficient and the latency increases. I wrote a script to reproduce this issue.

Solution

Note we can know the entries in handle ranges because TiDB guarantees the consistency of index and data, which means we already know the size of coprocessor tasks when reading handles, and we can adjust the concurrency by increasing the extra concurrency for small tasks. Small tasks won't block other queries on TiKV side because they are extremely fast(mostly less than 1ms on TiKV side).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type/enhancement The issue or PR belongs to an enhancement.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant