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.

Sign up for GitHub

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

Jump to bottom

The unified pool cannot schedule kv_scan, raw_scan and analyze requests well #9188

Open
sticnarf opened this issue Dec 4, 2020 · 4 comments
Open

The unified pool cannot schedule kv_scan, raw_scan and analyze requests well #9188

sticnarf opened this issue Dec 4, 2020 · 4 comments
Assignees
@sticnarf
Labels
component/performance Component: Performance severity/moderate type/bug The issue is confirmed as a bug.

Comments

@sticnarf
Copy link
Contributor

sticnarf commented Dec 4, 2020

Bug Report

What version of TiKV are you using?

TiKV 4.0 or master

Steps to reproduce

Set TiKV to use the unified thread pool for both storage and coprocessor. Run a TP workload. Then, run large kv_scan requests.

What did you expect?

The unified thread pool should let the kv_scan request not affect TP workload.

What did happened?

It affects the performance of the TP workload now. Even if the priority of kv_scan is set to low, it can still affect TP performance.
@sticnarf sticnarf added type/bug The issue is confirmed as a bug. component/performance Component: Performance severity/moderate labels Dec 4, 2020
@sticnarf sticnarf self-assigned this Dec 4, 2020
@sticnarf
Copy link
Contributor Author

sticnarf commented Dec 4, 2020

Now analyze requests and kv_scan requests are not transformed into splittable coroutines. Then, it is not possible for yatp to schedule such a large request.

@sticnarf
Copy link
Contributor Author

sticnarf commented Dec 4, 2020

Typical affected cases:

  • TiDB analyze
  • Add index DDL backfilling
  • BR backup
  • TiSpark analysis

The first three use cases should have a low concurrency, so the severity should be not high.
In the last case, TiSpark may have a high concurrency, TP performance may be affected greatly even if the scan requests are marked low priority.

@BusyJay
Copy link
Member

BusyJay commented Dec 7, 2020

Should the change be rolled back?

@sticnarf
Copy link
Contributor Author

sticnarf commented Dec 7, 2020

Should the change be rolled back?

Oh. 4.0.9 is not released yet. I think we should not enable it by default now.

@sticnarf sticnarf mentioned this issue Dec 7, 2020
Merged
@sticnarf sticnarf mentioned this issue Jan 28, 2021
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@sticnarf sticnarf

Labels
component/performance Component: Performance severity/moderate type/bug The issue is confirmed as a bug.
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

storage: yield in kv scan to avoid occupying cpu resource for too long sticnarf/tikv
2 participants
@BusyJay @sticnarf