# 案例 C：调度过慢-问题定位

![center](./student-guide/diagram/place-holder.png)

------------------------------------------------------------
  - 问题排查
    - 经确认，集群并无使用 tiflash，而通过过滤 “split”  pd leader 的日志，可以看到 split 时四副本的region 数量和监控显示的 extra-peer-region-count 数量近似，可以确定 extra-peer-region 是由于 split 操作产生的
    - 查看 PD -> Operator 监控面板下的相关调度产生与执行情况，发现相关的 remove 调度产生数量较少，而且执行时间较长

    - 由于调度受几个 scheduler limit 参数限制，查看其他调度产生与执行情况，发现其他类型的调度也存在较多异常：create 与 finish 数量不一致，存在较多的 timeout 情况

    - 查看 pd 服务器资源使用情况，发现 pd 的 CPU 使用较高，而通过 pd 和 tikv 的日志，查看调度出现 timeout 原因，发现是由于 pd 持有的 region epoch 版本不对，导致了下发给 tikv 的 operator 无法正确执行，表现为 add peer、remove peer 等操作处于超时状态
    - 通过 PD -> TiDB 和 Heartbeat 监控面板分析，PD CPU 使用较高的原因，是 PD 处理大量的 heartbeat 信息导致，通过观察 Heartbeat region event QPS 面板中 update_cache(save cache) 事件已经超过了 2k，而且 Region heartbeat report 面板中的数量和 TiKV Leader count 面板中 Leader 数量差距较大（集群未开启 Hibernate Region ）所以可以确定是 Heartbeat 导致的 PD CPU 使用较高，并出现了心跳更新瓶颈，从而导致了调度执行较慢