# [FAQ] TSO 延迟长尾随 GC 频率上升

## Key Words

 TSO, CPU, PD, GC, hibernet region.

## Description

用户监控显示资源充足的情况下，每次 GC 时出现较多慢查询，从监控排查发现期间所有 TiDB 获取 TSO 都出现了高延迟的长尾。

## Root Cause

- 主要问题：PD CPU 核数不足，用户用的 4 核，而 PD [官方推荐](https://docs.pingcap.com/zh/tidb/stable/hardware-and-software-requirements#%E7%94%9F%E4%BA%A7%E7%8E%AF%E5%A2%83) 生产坏境 CPU 核数在 8 +。周期性 GC 时，唤醒 hibernet region, 导致 PD 心跳压力突增，导致了瞬间压力。监控未捕捉到瞬间压力，就可能导致在 PD CPU 监控中看不到资源真实使用情况。

- 热点统计部分(code path 在心跳路径上)存在内存分配的问题，过多的 malloc 导致了 go runtime meomry GC 工作 ，PD 机器在 4 core 下，runtime gc 导致 goroutine 的在调度上受到了影响，导致了 tso 延迟上升。相关 issue:[pd#5692](https://github.com/tikv/pd/issues/5692)

## Diagnostic Steps

- 观察 duration 长尾出现时间与 GC 是否完全匹配
- 观察造成长尾的原因，确认是出现在获取 TSO 上，且所有 TiDB 获取 TSO 都出现了长尾（这里如果不明显的话，需要调整监控的公式到 1 或多个 9 才能看到）
- 观察 PD 侧 CPU 使用情况，问题点是否有明显抖动（瞬间压力可能没有）。
- 如果监控中 PD 的 CPU 未出现抖动， 且 PD 本身的核数少于 8， 基本可以确认 CPU 因瞬间高压未捕捉到，一般直接扩容可以解决。
- 如果用户需要进一步证据，需要获取 PD 的 trace 进一步观察，可以获取抖动期间和正常期间的 trace, 进行进一步对比分析。

## Resolution

可通过以下两种方式解决：

- 升级到 6.5.0+， 绕开热点统计的 issue （如果关键原因是核数不足，升级还是无法从根本上解决问题）.

- 增加 PD 的 CPU 核数至 8+。

## Affected Versions

All