sql: grow stacks for better performance (~3.00% cpu or more) #130663
Labels
C-performance
Perf of queries or internals. Solution not expected to change functional behavior.
o-perf-efficiency
Related to performance efficiency
P-2
Issues/test failures with a fix SLA of 3 months
T-sql-queries
SQL Queries Team
Is your feature request related to a problem? Please describe.
I ran1
sysbench
soltp_read_only
against a small table distributed across an three-node n2-standard-4 roachprod GCE cluster, via:Under this workload (90+% average CPU utilization), we spend around 7%-10% of the time accounted for in CPU profiles growing stacks (the Go stack starts at 2kb).
Describe the solution you'd like
We already know that we often exceed the default Go stack size, and in a few places have worked around it by pre-growing stacks early, for example:
/pkg/rpc/context.go#L1671-L1678
and
/pkg/sql/internal.go#L250-L254
A uniting theme between the different "flames" in the screenshot above is that they are in DistSQL processing, and likely all bypass these two calls to
growstack.Grow
.Addressing this would likely be rewarded with a noticeable performance improvement on this and other DistSQL-heavy workloads.
Describe alternatives you've considered
Additional context
One interesting alternative, at least for a prototype/exploration, is changing our go fork's default stack size.
Jira issue: CRDB-42173
Footnotes
see internal doc for full steps. ↩
The text was updated successfully, but these errors were encountered: