sql,*: tracking issue for sql overheads #88777
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
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.
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.
(*sql.connExecutor).transitionsStateApplyWrapper
7.7%
(*memo.Memo).IsStale
5.43%
(*sql.DistSQLPhysicalPlanner).setupFlows
4.34%
(*sql.planner).makeOptimizerPlan
2.32%
(*sql.connExecutor).recordStatementSummary
(*sql.connExecutor).addActiveQuery
(*sql.connExecutor).updateTxnRewindPosMaybe
1.27%
(*sql.DistSQLPhysicalPlanner).createPhysPlan
1.25% return from
(*sql.DistSQLPlanner).PlanAndRunAll
1.01%
(*sql.instrumentationHelper).SetIndexRecommendations
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
The text was updated successfully, but these errors were encountered: