tikv / tikv/pd

enhancement: make /regions/count lock-free or low-contention at large region scale

Open
#10,769 1 comment 0 reactions 0 assignees View on GitHub
contribution type/enhancement
Dominant language
Go
Stars
1.2k
Forks
783
Avg merge
5d 21h
Merged PRs (30d)
36

Description

## Enhancement Task

### Problem
`/regions/count` is wired to `regionsHandler.GetRegionCount` in `server/api/region.go:238-241`, which calls `rc.GetTotalRegionCount()`. That in turn goes through `pkg/core/region.go:2109-2112`.

### Why this is slow
`GetTotalRegionCount()` currently takes `r.t.RLock()` on the hot region tree. At 100M scale, that lock competes with the same tree that is being updated by region-heartbeat writers (`CheckAndPutRegion`, subtree updates, and removals in `pkg/core/region.go:1095-1112` and `1257-1285`). The lookup is logically O(1), but the shared lock makes it a poor high-frequency polling endpoint under heavy churn.

### Goal
Return region count without contending on the region-tree lock, or at least reduce contention enough that the endpoint stays cheap under 100M-region churn.

### Possible directions
- Keep an atomic/cached total region counter updated on insert/delete.
- Expose a lock-free read path for the count.
- Keep the current value eventually consistent if that is acceptable for this informational API.

### Evidence
- Handler: `server/api/region.go:238-241`.
- Count implementation: `pkg/core/region.go:2109-2112`.
- Hot write path: `pkg/core/region.go:1095-1112`, `1257-1285`.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.