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

sql,*: tracking issue for sql overheads #88777

Open
ajwerner opened this issue Sep 27, 2022 · 1 comment
Open

sql,*: tracking issue for sql overheads #88777

ajwerner opened this issue Sep 27, 2022 · 1 comment
Labels
C-bug Code not up to spec/doc, specs & docs deemed correct. Solution expected to change code/behavior. C-performance Perf of queries or internals. Solution not expected to change functional behavior. E-quick-win Likely to be a quick win for someone experienced. T-sql-queries SQL Queries Team

Comments

@ajwerner
Copy link
Contributor

ajwerner commented Sep 27, 2022

Describe the problem

Here is a profile
captured over a single-node run of kv95. The profile captures over 15 minutes of samples. This profile contains no networking for distributed KV execution,
and, thus is not a great representation of the overheads our network stack adds. Nevertheless, it provides
an interesting lens to look examine the cockroach process.

Note also that KV95 represents just about the worst case in terms of amortizing overheads. Many of the things which show up here would pale in comparison to planning and execution overheads of more complex queries. Nevertheless, it's valuable to understand the sources of overheads in simple workloads.

Note that the syscalls represent something like 5% of the CPU time.

category percent
syscall: write 4.55%
syscall: read 0.86%
VFS.sync 0.1%

kvserver grabs about 22.17% of the CPU time.

Below find a list of interesting SQL stack traces that add up to around 35% of all of the CPU time.

Screen Shot 2022-09-26 at 7 56 11 PM

Screen Shot 2022-09-26 at 7 58 58 PM

Screen Shot 2022-09-26 at 8 10 04 PM

Screen Shot 2022-09-26 at 8 03 53 PM

Screen Shot 2022-09-27 at 9 01 34 AM

Additional context

Note that this does not explore other overheads like grpc, because we don't send any requests in this single-node workload.

Jira issue: CRDB-19988

@ajwerner ajwerner added the C-bug Code not up to spec/doc, specs & docs deemed correct. Solution expected to change code/behavior. label Sep 27, 2022
@blathers-crl blathers-crl bot added the T-sql-queries SQL Queries Team label Sep 27, 2022
@rytaft
Copy link
Collaborator

rytaft commented Sep 27, 2022

@mgartner mgartner added the E-quick-win Likely to be a quick win for someone experienced. label Jan 19, 2023
@mgartner mgartner moved this to Backlog (DO NOT ADD NEW ISSUES) in SQL Queries Jul 24, 2023
@lunevalex lunevalex added the C-performance Perf of queries or internals. Solution not expected to change functional behavior. label Aug 31, 2023
@mgartner mgartner moved this from Backlog (DO NOT ADD NEW ISSUES) to New Backlog in SQL Queries Oct 31, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-bug Code not up to spec/doc, specs & docs deemed correct. Solution expected to change code/behavior. C-performance Perf of queries or internals. Solution not expected to change functional behavior. E-quick-win Likely to be a quick win for someone experienced. T-sql-queries SQL Queries Team
Projects
Status: Backlog
Development

No branches or pull requests

4 participants