# PD And TSO Latency

Use this branch for StartTS waits, TSO RPC/wait spikes, slow transaction start,
or evidence that latency originates in PD.

## Workflow

1. Align query/transaction latency with TiDB-side TSO wait or TSO RPC duration.
2. Compare TiDB-observed TSO RPC duration with PD server-side TSO handling time.
3. If both rise together, inspect PD-side mechanisms on the same window:
   PD leader CPU/runtime pressure, etcd peer RTT, WAL fsync, clock-offset or
   logical-overflow logs, and Region/heartbeat load.
4. If client duration rises while PD handling stays stable, inspect the
   TiDB-to-PD network and TiDB-local scheduling/profiling overhead.
5. Check leader changes only when raft term, campaign/step-down logs, or lease
   evidence aligns with the incident.

## Interpretation

- A direct StartTS/TSO wait signal that accounts for a material share of the
  visible latency outranks generic SQL CPU, GC, or TopSQL classification.
- High PD CPU alone does not prove TSO is the customer-facing bottleneck.
- Etcd WAL or peer RTT evidence must be time-aligned with the TSO spike.
- A normal PD server handling duration narrows the boundary but does not by
  itself prove which network or TiDB-local mechanism is responsible.

TSO follower proxy, batching, RPC modes, PD follower handling, and PD
microservices have version-dependent compatibility. Do not recommend or combine
them without checking current official documentation for the target version.