cockroachdb / cockroachdb/cockroach
asim: specify aggregate CPU usage in gen_load
- Dominant language
- Go
- Stars
- 32.5k
- Forks
- 4.1k
- PR merge metrics
- PR metrics pending
Description
The `gen_load` command currently determines CPU impact on a per-request basis (both for "access" and "raft write", the former applying only at the leaseholder, the latter on all replicas).
[^1]: https://cockroachlabs.slack.com/archives/C048HDZJSAY/p1753098283963639?thread_ts=1752692126.154139&cid=C048HDZJSAY
Every now and then, we've mused[^1] about whether it'd be more ergonomic to specify the CPU impact in aggregate (rather than on a per-request level). We could do this, see [this comment](https://github.com/cockroachdb/cockroach/pull/153991#pullrequestreview-3262323323) for a very rough implementation plan.
This means instead of
```
gen_load rate=1000 rw_ratio=0.95 request_cpu_per_access=5000000 raft_cpu_per_write=500000
```
we could have
```
gen_load rate=1000 rw_ratio=0.95 access_cpu=5000000000 raft_cpu=5000000000
```
Note that `raft_cpu` applies on each replica, not just the leaseholder, the .5vcpus configured here would additionally need to be divided by the replication factor, of which there may be multiple across the keys hit by the workload. It's going to be messy to be getting this right. We'd basically have to solve the equation below, where T is the configured total CPU, and N_k is the number of accesses with replication factor R_k, for q:
```
T = sum_k N_k * R_k * q
q = 1/T sum_k N_k * R_k
```
All doable (caveat emptor) but is it useful?
Maybe we'll just print the aggregate CPU usage (before replication) incurred by this workload in the output of `gen_load` and call it a day.
Jira issue: CRDB-54720
Contributor guide
Research direction
Start at the gen_load command and review the rough implementation plan linked in pull request 153991. First resolve whether aggregate CPU should be configurable or only reported, then determine how replication factors affect raft_cpu; the issue is done when the intended behavior and output are clearly settled and implemented.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- cli, databases, distributed-systems
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100