Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
30811: workload: give each kvOp a separate sql.Conn r=nvanbenschoten a=nvanbenschoten In #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` (#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 places in `workload` that could use the same kind of change. Before this change, `kv100 --concurrency=400` in the configuration discussed in #26178 topped out at around 80,000 qps. After this change, it tops out at around 250,000 qps. Release note: None Co-authored-by: Nathan VanBenschoten <nvanbenschoten@gmail.com>
- Loading branch information