cockroachdb / cockroachdb/cockroach

asim: specify aggregate CPU usage in gen_load

Open
#154,007 0 comments 0 reactions 0 assignees View on GitHub
A-kv-distribution C-enhancement T-kv
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.