Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
workload: give each kvOp a separate sql.Conn
In cockroachdb#26178, we saw that throughput hit a cliff while running `kv` at high concurrency levels. We spent a while debugging the issue, but nothing stood out in the `cockroach` process. Eventually I installed pprof http handlers in `workload` (cockroachdb#30810). The CPU and heap profiles looked fine but the mutex profile revealed that **99.94%** of mutex contention was in `sql.(*Rows).Next`. It turns out that this method manipulates a lock that's scoped to the same degree as its prepared statement. Since `readStmt` was prepared on the `sql.DB`, all kvOps were contending on the same lock in `sql.(*Rows).Next`. The fix is to give each `kvOp` its own `sql.Conn` and prepare the statement with a connection-level scope. There are probably other areas in `workload` that could use the same kind of change. Before this change, `kv100 --concurrency=400` in the configuration discussed in cockroachdb#26178 topped out at around 80,000 qps. After this change, it tops out at around 250,000 qps. Release note: None
- Loading branch information