From 7ffd85c121b20d64def3957ed57def471371a911 Mon Sep 17 00:00:00 2001 From: KASSADAR Date: Fri, 22 May 2020 16:56:21 +0800 Subject: [PATCH 01/11] Create troubleshooting-cpu.md --- troubleshooting-cpu.md | 104 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 104 insertions(+) create mode 100644 troubleshooting-cpu.md diff --git a/troubleshooting-cpu.md b/troubleshooting-cpu.md new file mode 100644 index 000000000000..02321069e8c3 --- /dev/null +++ b/troubleshooting-cpu.md @@ -0,0 +1,104 @@ +## 常见原因 + +### TiDB 执行计划不对导致延迟增高 + +查询计划不稳定，偶尔执行计划走到错误的索引，导致查询延迟增加。 + +* 如果慢日志中输出了执行计划，可以直接查看执行计划。用 `select tidb_decode_plan('xxx...')` 的 SQL 语句可以解析出具体的执行计划。 +* 慢日志中 SQL 执行时间 `Scan Keys` 数目较大。 +* SQL 执行时间相比于其他数据库(例如 MySQL)有较大差距。可以对比其他数据库执行计划，例如 `Join Order` 是否不同 + +**解决方案：** + +* 更新统计信息 + * 手动 analyze table，配合 crontab 定期 analyze，维持统计信息准确度 + * 自动 auto analyze，调低 analyze ratio 阈值，提高收集频次，并设置运行时间窗口 + * set global tidb_auto_analyze_ratio=0.2; + * set global tidb_auto_analyze_start_time='00:00 +0800'; + * set global tidb_auto_analyze_end_time='06:00 +0800'; +* 绑定执行计划 + * 修改业务 SQL ，使用 use index 固定使用列上的索引 + * 3.0 版本下，业务可以不用修改 SQL，使用 create binding 创建 force index 的绑定 SQL + * 4.0 版本支持 SQL Plan Management，可以避免执行计划不稳定导致的性能下降 +### +### PD 服务响应异常 + +PD TSO wait duration 异常升高。wait duration 代表从开始等待 pd 返回，到等待结束的时间。 + +* 磁盘问题，PD 所在的节点 I/O 被打满，排查是否有其他 I/O 高的组件与 PD 混部以及盘的健康情况，可通过监控 grafana -> disk performance -> latency 和 load 等指标进行验证，必要时可以使用 fio 工具对盘进行检测，见案例 [case-292](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case292.md) +* PD 之间网络问题，PD 日志中有 `"lost the TCP streaming connection"`，排查 PD 之间网络是否有问题，可通过监控 grafana -> PD -> etcd 的 round trip 来验证，见案例 [case-177](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case177.md) +* 系统 load 高，日志中能看到 `"server is likely overloaded"`，见案例 [case-214](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case214.md) +* 选不出 leader，PD 日志中有 `"lease is not expired"`，见 issues [https://github.com/etcd-io/etcd/issues/10355](https://github.com/etcd-io/etcd/issues/10355) v3.0.x 版本和 v2.1.19 版本已 fix 该问题，见案例 [case-875](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case875.md) +* 选举慢，region 加载时间长，从 PD 日志中 `grep "regions cost"`（例如日志中可能是 load 460927 regions cost 11.77099s）, 如果出现秒级，则说明较慢，v3.0 版本可开启 region storage（设置 `use-region-storage` 为 true），该特性能极大缩短加载 region 的时间，见案例 [case-429](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case429.md) +* TiDB -> PD 网络问题，排查网络相关情况。通过监控 grafana -> blackbox_exporter -> ping latency 确定 TiDB 到 PD leader 的网络是否正常 +* PD 报 `FATAL` 错误，日志中有 `"range failed to find revision pair"`，3.0.8 已经 fix 改问题，见 PR [https://github.com/pingcap/pd/pull/2040](https://github.com/pingcap/pd/pull/2040) 详情请参考案例 [case-947](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case947.md) +* 使用 /api/v1/regions 接口时 region 数量过多可能会导致 PD OOM，v3.0.8 版本修复，见 [https://github.com/pingcap/pd/pull/1986](https://github.com/pingcap/pd/pull/1986) +* 滚动升级的时候 PD OOM，gRPC 消息大小没限制，监控可看到 TCP InSegs 较大，v3.0.6 版本修复，见 [https://github.com/pingcap/pd/pull/1952](https://github.com/pingcap/pd/pull/1952) 详情请参考案例 [case-852](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case852.md) +* PD panic，报 bug +* 其他原因，通过 `curl http://127.0.0.1:2379/debug/pprof/goroutine?debug=2` 抓 goroutine，报 bug +### +### TiKV 服务响应异常 + +KV Cmd Duration 异常升高。KV Cmd Duration 是 TiDB 发送请求给 TiKV 到收到回复的延迟。 + +*  gRPC duration，请求在 TiKV 端的总耗时。通过对比 TiKV 的 gRPC duration 以及 TiDB 中的 KV duration 可以发现潜在的网络问题。比如 gRPC duration 很短但是 TiDB 的 KV duration 显示很长，说明 TiDB 和 TiKV 之间网络延迟可能很高，或者 TiDB 和 TiKV 之间的网卡带宽打满了。 +* TiKV 重启了导致重新选举 + * TiKV `panic` 之后又被 systemd 重新拉起正常运行，可以通过查看 TiKV 的日志来确认是否有 `panic`，这种情况属于非预期，需要报 bug + * 被第三者 `stop/kill`，被 systemd 重新拉起。查看 `dmesg` 和 `TiKV log` 确认原因 + * TiKV 发生 OOM 导致重启了 + * 动态调整 `THP` 导致 hung 住，见案例 [case-500](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case500.md) +* 查看监控：grafana -> TiKV-details -> errors 面板 `server is busy` 看到 TiKV RocksDB 出现 write stall 导致发生重新选举 +* TiKV 发生网络隔离导致重新选举 +* `block-cache` 配置太大导致 OOM，在监控 grafana -> TiKV-details 选中对应的 instance 之后查看 RocksDB 的 `block cache size` 监控来确认是否是该问题。同时请检查 `[storage.block-cache] capacity = # "1GB"` 参数是否设置合理，默认情况下 TiKV 的 `block-cache` 设置为机器总内存的 `45%`;在 container 部署的时候需要显式指定该参数，因为 TiKV 获取的是物理机的内存，可能会超出 container 的内存限制。 +* coprocessor 收到大量大查询，返回的数据量太大，gRPC 发送速度跟不上 coprocessor 往外吐数据的速度导致 OOM。可以通过检查监控： grafana -> TiKV-details -> coprocessor overview 的 `response size` 是否超过 `network outbound` 流量来确认是否属于这种情况。 +### +### TiKV 单线程瓶颈 + +TiKV 中存在一些单线程线程，可能会成为瓶颈。 + +* 单个 TiKV region 过多导致单个 gRPC 线程成为瓶颈（查看 grafana -> TiKV-details -> `Thread CPU/gRPC CPU Per Thread` 监控），v3.x 以上版本可以开启 `hibernate region` 特性来解决，见案例 [case-612](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case612.md)。 +* v3.0 之前版本 raftstore 单线程或者 apply 单线程到达瓶颈（grafana -> TiKV-details -> `Thread CPU/raft store CPU 和 Async apply CPU` 超过 `80%`），可以选择扩容 TiKV（v2.x 版本）实例或者升级到多线程模型的 v3.x 版本，见案例 [case-517](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case517.md)。 +### +### CPU load 升高 + +CPU 资源使用到达瓶颈 + +* 热点问题，转 …… +* 整体负载高，排查 TiDB 的 slow_query 和 expensive_query。对运行的 query 进行优化，缺索引的加索引，可以做 batch 的做 batch 改造。另一个方案是对集群进行扩容。 +## 其它原因 + +### 集群维护 + +通常大多数的线上集群有 3 或 5 个 PD 节点，如果维护的主机上有 PD 组件，需要具体考虑节点是 leader 还是 follower，关闭 follower 对集群运行没有任何影响，关闭 leader 需要先切换，并在切换时有 3 s 左右的性能抖动。 + +### 少数派副本离线 + +TiDB 集群默认配置为 3 副本，每一个 Region 都会在集群中保存 3 份，它们之间通过 Raft 协议来选举 Leader 并同步数据。Raft 协议可以保证在数量小于副本数（注意，不是节点数）一半的节点挂掉或者隔离的情况下，仍然能够提供服务，并且不丢失任何数据。 对于 3 副本集群，挂掉一个节点除了可能会导致性能有抖动之外，可用性和正确性理论上不会受影响 + +### 新增索引 + +由于创建索引在扫表回填索引的时候会消耗大量资源，甚至与一些频繁更新的字段会发生冲突导致正常业务受到影响。大表创建索引的过程往往会持续很长时间，所以要尽可能地平衡执行时间和集群性能之间的关系。 + +**参数调整：** + +目前主要使用 `tidb_ddl_reorg_worker_cnt` 和 `tidb_ddl_reorg_batch_size` 这两个参数来动态调整索引创建速度，通常来说它们的值越小对系统影响越小，但是执行时间越长。 + +一般情况下，先将值保持为默认的 4 和 256 ，观察集群资源使用情况和响应速度，再逐渐调大 `tidb_ddl_reorg_worker_cnt` 参数来增加并发，观察监控如果系统没有发生明显的抖动，再逐渐调大 `tidb_ddl_reorg_batch_size` 参数，但如果索引涉及的列更新很频繁的话就会造成大量冲突造成失败重试。 + +另外还可以通过调整参数 `tidb_ddl_reorg_priority` 为 PRIORITY_HIGH 来让创建索引的任务保持高优先级来提升速度，但在通用 OLTP 系统上，一般建议保持默认。 + +### GC 压力大 + +TiDB 的事务的实现采用了 MVCC（多版本并发控制）机制，当新写入的数据覆盖旧的数据时，旧的数据不会被替换掉，而是与新写入的数据同时保留，并以时间戳来区分版本。GC 的任务便是清理不再需要的旧数据。 + +* Resolve Locks 阶段在 TiKV 一侧会产生大量的 scan_lock 请求，可以在 gRPC 相关的 metrics 中观察到。scan_lock 请求会对全部的 Region 调用。 +* Delete Ranges 阶段会往 TiKV 发送少量的 unsafe_destroy_range 请求，也可能没有。可以在 gRPC 相关的 metrics 中和 GC 分类下的 GC tasks 中观察到。 +* Do GC 阶段，默认每台 TiKV 会自动扫描本机上的 leader Region 并对每一个 leader 进行 GC，这一活动可以在 GC 分类下的 GC tasks 中观察到。 + + + + + + + + From e6eb610dbf0930d44b4bd4574e9e7f735a8dfcc2 Mon Sep 17 00:00:00 2001 From: KASSADAR Date: Sat, 23 May 2020 19:35:50 +0800 Subject: [PATCH 02/11] Update troubleshoot-cpu-issues.md --- troubleshoot-cpu-issues.md | 122 +++++++++++++++++++++++++++++++++++++ 1 file changed, 122 insertions(+) diff --git a/troubleshoot-cpu-issues.md b/troubleshoot-cpu-issues.md index e69de29bb2d1..b027d2262148 100644 --- a/troubleshoot-cpu-issues.md +++ b/troubleshoot-cpu-issues.md @@ -0,0 +1,122 @@ +--- +title: CPU 占用较多、读写延时增加、抖动 +summary: 介绍读写延时增加、抖动时的排查思路，可能的原因和解决方法。 +category: troubleshoot-cpu-issues +--- +# CPU 占用较多、读写延时增加、抖动 +本文档介绍读写延时增加、抖动时的排查思路，可能的原因和解决方法。 + +## 常见原因 + +### TiDB 执行计划不对导致延迟增高 + +查询计划不稳定，偶尔执行计划走到错误的索引，导致查询延迟增加。 + +**现象：** + +* 如果慢日志中输出了执行计划，可以直接查看执行计划。用 `select tidb_decode_plan('xxx...')` 的 SQL 语句可以解析出具体的执行计划。 +* 监控中的 key 扫描异常升高；慢日志中 SQL 执行时间 `Scan Keys` 数目较大。 +* SQL 执行时间相比于其他数据库(例如 MySQL)有较大差距。可以对比其他数据库执行计划，例如 `Join Order` 是否不同。 + +**可能的原因：** +* 统计信息不准确 + +**解决方案：** + +* 更新统计信息 + * 手动 analyze table，配合 crontab 定期 analyze，维持统计信息准确度 + * 自动 auto analyze，调低 analyze ratio 阈值，提高收集频次，并设置运行时间窗口 + * set global tidb_auto_analyze_ratio=0.2; + * set global tidb_auto_analyze_start_time='00:00 +0800'; + * set global tidb_auto_analyze_end_time='06:00 +0800'; +* 绑定执行计划 + * 修改业务 SQL ，使用 use index 固定使用列上的索引 + * 3.0 版本下，业务可以不用修改 SQL，使用 create binding 创建 force index 的绑定 SQL + * 4.0 版本支持 SQL Plan Management，可以避免执行计划不稳定导致的性能下降 + +### PD 异常 + +**现象：** + +监控中 PD TSO wait duration 异常升高。wait duration 代表从开始等待 pd 返回，到等待结束的时间。 + +**可能的原因：** + +* 磁盘问题，PD 所在的节点 I/O 被打满，排查是否有其他 I/O 高的组件与 PD 混部以及盘的健康情况，可通过监控 grafana -> disk performance -> latency 和 load 等指标进行验证，必要时可以使用 fio 工具对盘进行检测，见案例 [case-292](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case292.md) +* PD 之间网络问题，PD 日志中有 `"lost the TCP streaming connection"`，排查 PD 之间网络是否有问题，可通过监控 grafana -> PD -> etcd 的 round trip 来验证，见案例 [case-177](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case177.md) +* 系统 load 高，日志中能看到 `"server is likely overloaded"`，见案例 [case-214](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case214.md) +* 选不出 leader，PD 日志中有 `"lease is not expired"`，见 issues [https://github.com/etcd-io/etcd/issues/10355](https://github.com/etcd-io/etcd/issues/10355) v3.0.x 版本和 v2.1.19 版本已 fix 该问题，见案例 [case-875](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case875.md) +* 选举慢，region 加载时间长，从 PD 日志中 `grep "regions cost"`（例如日志中可能是 load 460927 regions cost 11.77099s）, 如果出现秒级，则说明较慢，v3.0 版本可开启 region storage（设置 `use-region-storage` 为 true），该特性能极大缩短加载 region 的时间，见案例 [case-429](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case429.md) +* TiDB -> PD 网络问题，排查网络相关情况。通过监控 grafana -> blackbox_exporter -> ping latency 确定 TiDB 到 PD leader 的网络是否正常 +* PD 报 `FATAL` 错误，日志中有 `"range failed to find revision pair"`，3.0.8 已经 fix 改问题，见 PR [https://github.com/pingcap/pd/pull/2040](https://github.com/pingcap/pd/pull/2040) 详情请参考案例 [case-947](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case947.md) +* 使用 /api/v1/regions 接口时 region 数量过多可能会导致 PD OOM，v3.0.8 版本修复，见 [https://github.com/pingcap/pd/pull/1986](https://github.com/pingcap/pd/pull/1986) +* 滚动升级的时候 PD OOM，gRPC 消息大小没限制，监控可看到 TCP InSegs 较大，v3.0.6 版本修复，见 [https://github.com/pingcap/pd/pull/1952](https://github.com/pingcap/pd/pull/1952) 详情请参考案例 [case-852](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case852.md) +* PD panic，报 bug +* 其他原因，通过 `curl http://127.0.0.1:2379/debug/pprof/goroutine?debug=2` 抓 goroutine，报 bug + +### TiKV 异常 + +**现象：** + +监控中 KV Cmd Duration 异常升高。KV Cmd Duration 是 TiDB 发送请求给 TiKV 到收到回复的延迟。 + +**可能的原因：** + +* 查看 gRPC duration，gRPC duration 是请求在 TiKV 端的总耗时。通过对比 TiKV 的 gRPC duration 以及 TiDB 中的 KV duration 可以发现潜在的网络问题。比如 gRPC duration 很短但是 TiDB 的 KV duration 显示很长，说明 TiDB 和 TiKV 之间网络延迟可能很高，或者 TiDB 和 TiKV 之间的网卡带宽打满了。 +* TiKV 重启了导致重新选举 + * TiKV `panic` 之后又被 systemd 重新拉起正常运行，可以通过查看 TiKV 的日志来确认是否有 `panic`，这种情况属于非预期，需要报 bug + * 被第三者 `stop/kill`，被 systemd 重新拉起。查看 `dmesg` 和 `TiKV log` 确认原因 + * TiKV 发生 OOM 导致重启了 + * 动态调整 `THP` 导致 hung 住，见案例 [case-500](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case500.md) +* 查看监控：grafana -> TiKV-details -> errors 面板 `server is busy` 看到 TiKV RocksDB 出现 write stall 导致发生重新选举 +* TiKV 发生网络隔离导致重新选举 +* `block-cache` 配置太大导致 OOM，在监控 grafana -> TiKV-details 选中对应的 instance 之后查看 RocksDB 的 `block cache size` 监控来确认是否是该问题。同时请检查 `[storage.block-cache] capacity = # "1GB"` 参数是否设置合理，默认情况下 TiKV 的 `block-cache` 设置为机器总内存的 `45%`;在 container 部署的时候需要显式指定该参数，因为 TiKV 获取的是物理机的内存，可能会超出 container 的内存限制。 +* coprocessor 收到大量大查询，返回的数据量太大，gRPC 发送速度跟不上 coprocessor 往外吐数据的速度导致 OOM。可以通过检查监控： grafana -> TiKV-details -> coprocessor overview 的 `response size` 是否超过 `network outbound` 流量来确认是否属于这种情况。 + +### TiKV 单线程瓶颈 + +TiKV 中存在一些单线程线程，可能会成为瓶颈。 + +* 单个 TiKV region 过多导致单个 gRPC 线程成为瓶颈（查看 grafana -> TiKV-details -> `Thread CPU/gRPC CPU Per Thread` 监控），v3.x 以上版本可以开启 `hibernate region` 特性来解决，见案例 [case-612](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case612.md)。 +* v3.0 之前版本 raftstore 单线程或者 apply 单线程到达瓶颈（grafana -> TiKV-details -> `Thread CPU/raft store CPU 和 Async apply CPU` 超过 `80%`），可以选择扩容 TiKV（v2.x 版本）实例或者升级到多线程模型的 v3.x 版本，见案例 [case-517](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case517.md)。 + +### CPU Load 升高 + +**现象：** + +CPU 资源使用到达瓶颈 + +**可能的原因：** + +* 热点问题 +* 整体负载高，排查 TiDB 的 slow_query 和 expensive_query。对运行的 query 进行优化，缺索引的加索引，可以做 batch 的做 batch 改造。另一个方案是对集群进行扩容。 + +## 其它原因 + +### 集群维护 + +通常大多数的线上集群有 3 或 5 个 PD 节点，如果维护的主机上有 PD 组件，需要具体考虑节点是 leader 还是 follower，关闭 follower 对集群运行没有任何影响，关闭 leader 需要先切换，并在切换时有 3 s 左右的性能抖动。 + +### 少数派副本离线 + +TiDB 集群默认配置为 3 副本，每一个 Region 都会在集群中保存 3 份，它们之间通过 Raft 协议来选举 Leader 并同步数据。Raft 协议可以保证在数量小于副本数（注意，不是节点数）一半的节点挂掉或者隔离的情况下，仍然能够提供服务，并且不丢失任何数据。 对于 3 副本集群，挂掉一个节点除了可能会导致性能有抖动之外，可用性和正确性理论上不会受影响 + +### 新增索引 + +由于创建索引在扫表回填索引的时候会消耗大量资源，甚至与一些频繁更新的字段会发生冲突导致正常业务受到影响。大表创建索引的过程往往会持续很长时间，所以要尽可能地平衡执行时间和集群性能之间的关系。 + +**参数调整：** + +目前主要使用 `tidb_ddl_reorg_worker_cnt` 和 `tidb_ddl_reorg_batch_size` 这两个参数来动态调整索引创建速度，通常来说它们的值越小对系统影响越小，但是执行时间越长。 + +一般情况下，先将值保持为默认的 4 和 256 ，观察集群资源使用情况和响应速度，再逐渐调大 `tidb_ddl_reorg_worker_cnt` 参数来增加并发，观察监控如果系统没有发生明显的抖动，再逐渐调大 `tidb_ddl_reorg_batch_size` 参数，但如果索引涉及的列更新很频繁的话就会造成大量冲突造成失败重试。 + +另外还可以通过调整参数 `tidb_ddl_reorg_priority` 为 PRIORITY_HIGH 来让创建索引的任务保持高优先级来提升速度，但在通用 OLTP 系统上，一般建议保持默认。 + +### GC 压力大 + +TiDB 的事务的实现采用了 MVCC（多版本并发控制）机制，当新写入的数据覆盖旧的数据时，旧的数据不会被替换掉，而是与新写入的数据同时保留，并以时间戳来区分版本。GC 的任务便是清理不再需要的旧数据。 + +* Resolve Locks 阶段在 TiKV 一侧会产生大量的 scan_lock 请求，可以在 gRPC 相关的 metrics 中观察到。scan_lock 请求会对全部的 Region 调用。 +* Delete Ranges 阶段会往 TiKV 发送少量的 unsafe_destroy_range 请求，也可能没有。可以在 gRPC 相关的 metrics 中和 GC 分类下的 GC tasks 中观察到。 +* Do GC 阶段，默认每台 TiKV 会自动扫描本机上的 leader Region 并对每一个 leader 进行 GC，这一活动可以在 GC 分类下的 GC tasks 中观察到。 From 7ad15c0c99fd56bee201d8c4dc42f5b95b4b4fb6 Mon Sep 17 00:00:00 2001 From: KASSADAR Date: Sat, 23 May 2020 19:36:13 +0800 Subject: [PATCH 03/11] Delete troubleshooting-cpu.md --- troubleshooting-cpu.md | 104 ----------------------------------------- 1 file changed, 104 deletions(-) delete mode 100644 troubleshooting-cpu.md diff --git a/troubleshooting-cpu.md b/troubleshooting-cpu.md deleted file mode 100644 index 02321069e8c3..000000000000 --- a/troubleshooting-cpu.md +++ /dev/null @@ -1,104 +0,0 @@ -## 常见原因 - -### TiDB 执行计划不对导致延迟增高 - -查询计划不稳定，偶尔执行计划走到错误的索引，导致查询延迟增加。 - -* 如果慢日志中输出了执行计划，可以直接查看执行计划。用 `select tidb_decode_plan('xxx...')` 的 SQL 语句可以解析出具体的执行计划。 -* 慢日志中 SQL 执行时间 `Scan Keys` 数目较大。 -* SQL 执行时间相比于其他数据库(例如 MySQL)有较大差距。可以对比其他数据库执行计划，例如 `Join Order` 是否不同 - -**解决方案：** - -* 更新统计信息 - * 手动 analyze table，配合 crontab 定期 analyze，维持统计信息准确度 - * 自动 auto analyze，调低 analyze ratio 阈值，提高收集频次，并设置运行时间窗口 - * set global tidb_auto_analyze_ratio=0.2; - * set global tidb_auto_analyze_start_time='00:00 +0800'; - * set global tidb_auto_analyze_end_time='06:00 +0800'; -* 绑定执行计划 - * 修改业务 SQL ，使用 use index 固定使用列上的索引 - * 3.0 版本下，业务可以不用修改 SQL，使用 create binding 创建 force index 的绑定 SQL - * 4.0 版本支持 SQL Plan Management，可以避免执行计划不稳定导致的性能下降 -### -### PD 服务响应异常 - -PD TSO wait duration 异常升高。wait duration 代表从开始等待 pd 返回，到等待结束的时间。 - -* 磁盘问题，PD 所在的节点 I/O 被打满，排查是否有其他 I/O 高的组件与 PD 混部以及盘的健康情况，可通过监控 grafana -> disk performance -> latency 和 load 等指标进行验证，必要时可以使用 fio 工具对盘进行检测，见案例 [case-292](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case292.md) -* PD 之间网络问题，PD 日志中有 `"lost the TCP streaming connection"`，排查 PD 之间网络是否有问题，可通过监控 grafana -> PD -> etcd 的 round trip 来验证，见案例 [case-177](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case177.md) -* 系统 load 高，日志中能看到 `"server is likely overloaded"`，见案例 [case-214](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case214.md) -* 选不出 leader，PD 日志中有 `"lease is not expired"`，见 issues [https://github.com/etcd-io/etcd/issues/10355](https://github.com/etcd-io/etcd/issues/10355) v3.0.x 版本和 v2.1.19 版本已 fix 该问题，见案例 [case-875](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case875.md) -* 选举慢，region 加载时间长，从 PD 日志中 `grep "regions cost"`（例如日志中可能是 load 460927 regions cost 11.77099s）, 如果出现秒级，则说明较慢，v3.0 版本可开启 region storage（设置 `use-region-storage` 为 true），该特性能极大缩短加载 region 的时间，见案例 [case-429](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case429.md) -* TiDB -> PD 网络问题，排查网络相关情况。通过监控 grafana -> blackbox_exporter -> ping latency 确定 TiDB 到 PD leader 的网络是否正常 -* PD 报 `FATAL` 错误，日志中有 `"range failed to find revision pair"`，3.0.8 已经 fix 改问题，见 PR [https://github.com/pingcap/pd/pull/2040](https://github.com/pingcap/pd/pull/2040) 详情请参考案例 [case-947](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case947.md) -* 使用 /api/v1/regions 接口时 region 数量过多可能会导致 PD OOM，v3.0.8 版本修复，见 [https://github.com/pingcap/pd/pull/1986](https://github.com/pingcap/pd/pull/1986) -* 滚动升级的时候 PD OOM，gRPC 消息大小没限制，监控可看到 TCP InSegs 较大，v3.0.6 版本修复，见 [https://github.com/pingcap/pd/pull/1952](https://github.com/pingcap/pd/pull/1952) 详情请参考案例 [case-852](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case852.md) -* PD panic，报 bug -* 其他原因，通过 `curl http://127.0.0.1:2379/debug/pprof/goroutine?debug=2` 抓 goroutine，报 bug -### -### TiKV 服务响应异常 - -KV Cmd Duration 异常升高。KV Cmd Duration 是 TiDB 发送请求给 TiKV 到收到回复的延迟。 - -*  gRPC duration，请求在 TiKV 端的总耗时。通过对比 TiKV 的 gRPC duration 以及 TiDB 中的 KV duration 可以发现潜在的网络问题。比如 gRPC duration 很短但是 TiDB 的 KV duration 显示很长，说明 TiDB 和 TiKV 之间网络延迟可能很高，或者 TiDB 和 TiKV 之间的网卡带宽打满了。 -* TiKV 重启了导致重新选举 - * TiKV `panic` 之后又被 systemd 重新拉起正常运行，可以通过查看 TiKV 的日志来确认是否有 `panic`，这种情况属于非预期，需要报 bug - * 被第三者 `stop/kill`，被 systemd 重新拉起。查看 `dmesg` 和 `TiKV log` 确认原因 - * TiKV 发生 OOM 导致重启了 - * 动态调整 `THP` 导致 hung 住，见案例 [case-500](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case500.md) -* 查看监控：grafana -> TiKV-details -> errors 面板 `server is busy` 看到 TiKV RocksDB 出现 write stall 导致发生重新选举 -* TiKV 发生网络隔离导致重新选举 -* `block-cache` 配置太大导致 OOM，在监控 grafana -> TiKV-details 选中对应的 instance 之后查看 RocksDB 的 `block cache size` 监控来确认是否是该问题。同时请检查 `[storage.block-cache] capacity = # "1GB"` 参数是否设置合理，默认情况下 TiKV 的 `block-cache` 设置为机器总内存的 `45%`;在 container 部署的时候需要显式指定该参数，因为 TiKV 获取的是物理机的内存，可能会超出 container 的内存限制。 -* coprocessor 收到大量大查询，返回的数据量太大，gRPC 发送速度跟不上 coprocessor 往外吐数据的速度导致 OOM。可以通过检查监控： grafana -> TiKV-details -> coprocessor overview 的 `response size` 是否超过 `network outbound` 流量来确认是否属于这种情况。 -### -### TiKV 单线程瓶颈 - -TiKV 中存在一些单线程线程，可能会成为瓶颈。 - -* 单个 TiKV region 过多导致单个 gRPC 线程成为瓶颈（查看 grafana -> TiKV-details -> `Thread CPU/gRPC CPU Per Thread` 监控），v3.x 以上版本可以开启 `hibernate region` 特性来解决，见案例 [case-612](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case612.md)。 -* v3.0 之前版本 raftstore 单线程或者 apply 单线程到达瓶颈（grafana -> TiKV-details -> `Thread CPU/raft store CPU 和 Async apply CPU` 超过 `80%`），可以选择扩容 TiKV（v2.x 版本）实例或者升级到多线程模型的 v3.x 版本，见案例 [case-517](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case517.md)。 -### -### CPU load 升高 - -CPU 资源使用到达瓶颈 - -* 热点问题，转 …… -* 整体负载高，排查 TiDB 的 slow_query 和 expensive_query。对运行的 query 进行优化，缺索引的加索引，可以做 batch 的做 batch 改造。另一个方案是对集群进行扩容。 -## 其它原因 - -### 集群维护 - -通常大多数的线上集群有 3 或 5 个 PD 节点，如果维护的主机上有 PD 组件，需要具体考虑节点是 leader 还是 follower，关闭 follower 对集群运行没有任何影响，关闭 leader 需要先切换，并在切换时有 3 s 左右的性能抖动。 - -### 少数派副本离线 - -TiDB 集群默认配置为 3 副本，每一个 Region 都会在集群中保存 3 份，它们之间通过 Raft 协议来选举 Leader 并同步数据。Raft 协议可以保证在数量小于副本数（注意，不是节点数）一半的节点挂掉或者隔离的情况下，仍然能够提供服务，并且不丢失任何数据。 对于 3 副本集群，挂掉一个节点除了可能会导致性能有抖动之外，可用性和正确性理论上不会受影响 - -### 新增索引 - -由于创建索引在扫表回填索引的时候会消耗大量资源，甚至与一些频繁更新的字段会发生冲突导致正常业务受到影响。大表创建索引的过程往往会持续很长时间，所以要尽可能地平衡执行时间和集群性能之间的关系。 - -**参数调整：** - -目前主要使用 `tidb_ddl_reorg_worker_cnt` 和 `tidb_ddl_reorg_batch_size` 这两个参数来动态调整索引创建速度，通常来说它们的值越小对系统影响越小，但是执行时间越长。 - -一般情况下，先将值保持为默认的 4 和 256 ，观察集群资源使用情况和响应速度，再逐渐调大 `tidb_ddl_reorg_worker_cnt` 参数来增加并发，观察监控如果系统没有发生明显的抖动，再逐渐调大 `tidb_ddl_reorg_batch_size` 参数，但如果索引涉及的列更新很频繁的话就会造成大量冲突造成失败重试。 - -另外还可以通过调整参数 `tidb_ddl_reorg_priority` 为 PRIORITY_HIGH 来让创建索引的任务保持高优先级来提升速度，但在通用 OLTP 系统上，一般建议保持默认。 - -### GC 压力大 - -TiDB 的事务的实现采用了 MVCC（多版本并发控制）机制，当新写入的数据覆盖旧的数据时，旧的数据不会被替换掉，而是与新写入的数据同时保留，并以时间戳来区分版本。GC 的任务便是清理不再需要的旧数据。 - -* Resolve Locks 阶段在 TiKV 一侧会产生大量的 scan_lock 请求，可以在 gRPC 相关的 metrics 中观察到。scan_lock 请求会对全部的 Region 调用。 -* Delete Ranges 阶段会往 TiKV 发送少量的 unsafe_destroy_range 请求，也可能没有。可以在 gRPC 相关的 metrics 中和 GC 分类下的 GC tasks 中观察到。 -* Do GC 阶段，默认每台 TiKV 会自动扫描本机上的 leader Region 并对每一个 leader 进行 GC，这一活动可以在 GC 分类下的 GC tasks 中观察到。 - - - - - - - - From 4d671fe67c2be429adbd865751b8b7613c6358c9 Mon Sep 17 00:00:00 2001 From: KASSADAR Date: Sun, 24 May 2020 22:50:49 +0800 Subject: [PATCH 04/11] Update troubleshoot-cpu-issues.md Co-authored-by: TomShawn <41534398+TomShawn@users.noreply.github.com> --- troubleshoot-cpu-issues.md | 1 + 1 file changed, 1 insertion(+) diff --git a/troubleshoot-cpu-issues.md b/troubleshoot-cpu-issues.md index b027d2262148..dd8e049e4396 100644 --- a/troubleshoot-cpu-issues.md +++ b/troubleshoot-cpu-issues.md @@ -4,6 +4,7 @@ summary: 介绍读写延时增加、抖动时的排查思路，可能的原因 category: troubleshoot-cpu-issues --- # CPU 占用较多、读写延时增加、抖动 + 本文档介绍读写延时增加、抖动时的排查思路，可能的原因和解决方法。 ## 常见原因 From f727e783dfb5d8799cfe950500f8733755443298 Mon Sep 17 00:00:00 2001 From: KASSADAR Date: Sun, 24 May 2020 22:50:59 +0800 Subject: [PATCH 05/11] Update troubleshoot-cpu-issues.md Co-authored-by: TomShawn <41534398+TomShawn@users.noreply.github.com> --- troubleshoot-cpu-issues.md | 1 + 1 file changed, 1 insertion(+) diff --git a/troubleshoot-cpu-issues.md b/troubleshoot-cpu-issues.md index dd8e049e4396..11d75b27b17b 100644 --- a/troubleshoot-cpu-issues.md +++ b/troubleshoot-cpu-issues.md @@ -20,6 +20,7 @@ category: troubleshoot-cpu-issues * SQL 执行时间相比于其他数据库(例如 MySQL)有较大差距。可以对比其他数据库执行计划，例如 `Join Order` 是否不同。 **可能的原因：** + * 统计信息不准确 **解决方案：** From 007c04eafed73ec7bd67f3e089d18421a143ffa2 Mon Sep 17 00:00:00 2001 From: KASSADAR Date: Sun, 24 May 2020 22:57:08 +0800 Subject: [PATCH 06/11] Update troubleshoot-cpu-issues.md --- troubleshoot-cpu-issues.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/troubleshoot-cpu-issues.md b/troubleshoot-cpu-issues.md index 11d75b27b17b..158e07897dd1 100644 --- a/troubleshoot-cpu-issues.md +++ b/troubleshoot-cpu-issues.md @@ -28,9 +28,9 @@ category: troubleshoot-cpu-issues * 更新统计信息 * 手动 analyze table，配合 crontab 定期 analyze，维持统计信息准确度 * 自动 auto analyze，调低 analyze ratio 阈值，提高收集频次，并设置运行时间窗口 - * set global tidb_auto_analyze_ratio=0.2; - * set global tidb_auto_analyze_start_time='00:00 +0800'; - * set global tidb_auto_analyze_end_time='06:00 +0800'; + * set global tidb_auto_analyze_ratio=0.2; + * set global tidb_auto_analyze_start_time='00:00 +0800'; + * set global tidb_auto_analyze_end_time='06:00 +0800'; * 绑定执行计划 * 修改业务 SQL ，使用 use index 固定使用列上的索引 * 3.0 版本下，业务可以不用修改 SQL，使用 create binding 创建 force index 的绑定 SQL @@ -66,10 +66,10 @@ category: troubleshoot-cpu-issues * 查看 gRPC duration，gRPC duration 是请求在 TiKV 端的总耗时。通过对比 TiKV 的 gRPC duration 以及 TiDB 中的 KV duration 可以发现潜在的网络问题。比如 gRPC duration 很短但是 TiDB 的 KV duration 显示很长，说明 TiDB 和 TiKV 之间网络延迟可能很高，或者 TiDB 和 TiKV 之间的网卡带宽打满了。 * TiKV 重启了导致重新选举 - * TiKV `panic` 之后又被 systemd 重新拉起正常运行，可以通过查看 TiKV 的日志来确认是否有 `panic`，这种情况属于非预期，需要报 bug - * 被第三者 `stop/kill`，被 systemd 重新拉起。查看 `dmesg` 和 `TiKV log` 确认原因 - * TiKV 发生 OOM 导致重启了 - * 动态调整 `THP` 导致 hung 住，见案例 [case-500](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case500.md) + * TiKV `panic` 之后又被 systemd 重新拉起正常运行，可以通过查看 TiKV 的日志来确认是否有 `panic`，这种情况属于非预期，需要报 bug + * 被第三者 `stop/kill`，被 systemd 重新拉起。查看 `dmesg` 和 `TiKV log` 确认原因 + * TiKV 发生 OOM 导致重启了 + * 动态调整 `THP` 导致 hung 住，见案例 [case-500](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case500.md) * 查看监控：grafana -> TiKV-details -> errors 面板 `server is busy` 看到 TiKV RocksDB 出现 write stall 导致发生重新选举 * TiKV 发生网络隔离导致重新选举 * `block-cache` 配置太大导致 OOM，在监控 grafana -> TiKV-details 选中对应的 instance 之后查看 RocksDB 的 `block cache size` 监控来确认是否是该问题。同时请检查 `[storage.block-cache] capacity = # "1GB"` 参数是否设置合理，默认情况下 TiKV 的 `block-cache` 设置为机器总内存的 `45%`;在 container 部署的时候需要显式指定该参数，因为 TiKV 获取的是物理机的内存，可能会超出 container 的内存限制。 From 1254debd03a888956267de5361ae212eca2d05e8 Mon Sep 17 00:00:00 2001 From: KASSADAR Date: Sun, 24 May 2020 22:58:16 +0800 Subject: [PATCH 07/11] Update troubleshoot-cpu-issues.md --- troubleshoot-cpu-issues.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/troubleshoot-cpu-issues.md b/troubleshoot-cpu-issues.md index 158e07897dd1..82848ae9874e 100644 --- a/troubleshoot-cpu-issues.md +++ b/troubleshoot-cpu-issues.md @@ -32,9 +32,9 @@ category: troubleshoot-cpu-issues * set global tidb_auto_analyze_start_time='00:00 +0800'; * set global tidb_auto_analyze_end_time='06:00 +0800'; * 绑定执行计划 - * 修改业务 SQL ，使用 use index 固定使用列上的索引 - * 3.0 版本下，业务可以不用修改 SQL，使用 create binding 创建 force index 的绑定 SQL - * 4.0 版本支持 SQL Plan Management，可以避免执行计划不稳定导致的性能下降 + * 修改业务 SQL ，使用 use index 固定使用列上的索引 + * 3.0 版本下，业务可以不用修改 SQL，使用 create binding 创建 force index 的绑定 SQL + * 4.0 版本支持 SQL Plan Management，可以避免执行计划不稳定导致的性能下降 ### PD 异常 From 3a72affeb82e64a12903328ae7afe1316ab76ee0 Mon Sep 17 00:00:00 2001 From: KASSADAR Date: Sun, 24 May 2020 23:03:02 +0800 Subject: [PATCH 08/11] Update troubleshoot-cpu-issues.md --- troubleshoot-cpu-issues.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/troubleshoot-cpu-issues.md b/troubleshoot-cpu-issues.md index 82848ae9874e..b59e9e148c91 100644 --- a/troubleshoot-cpu-issues.md +++ b/troubleshoot-cpu-issues.md @@ -26,15 +26,15 @@ category: troubleshoot-cpu-issues **解决方案：** * 更新统计信息 - * 手动 analyze table，配合 crontab 定期 analyze，维持统计信息准确度 - * 自动 auto analyze，调低 analyze ratio 阈值，提高收集频次，并设置运行时间窗口 - * set global tidb_auto_analyze_ratio=0.2; - * set global tidb_auto_analyze_start_time='00:00 +0800'; - * set global tidb_auto_analyze_end_time='06:00 +0800'; + * 手动 analyze table，配合 crontab 定期 analyze，维持统计信息准确度 + * 自动 auto analyze，调低 analyze ratio 阈值，提高收集频次，并设置运行时间窗口 + * set global tidb_auto_analyze_ratio=0.2; + * set global tidb_auto_analyze_start_time='00:00 +0800'; + * set global tidb_auto_analyze_end_time='06:00 +0800'; * 绑定执行计划 - * 修改业务 SQL ，使用 use index 固定使用列上的索引 - * 3.0 版本下，业务可以不用修改 SQL，使用 create binding 创建 force index 的绑定 SQL - * 4.0 版本支持 SQL Plan Management，可以避免执行计划不稳定导致的性能下降 + * 修改业务 SQL ，使用 use index 固定使用列上的索引 + * 3.0 版本下，业务可以不用修改 SQL，使用 create binding 创建 force index 的绑定 SQL + * 4.0 版本支持 SQL Plan Management，可以避免执行计划不稳定导致的性能下降 ### PD 异常 From 240d34388c2ac4659712f961671e495b80e33870 Mon Sep 17 00:00:00 2001 From: TomShawn <41534398+TomShawn@users.noreply.github.com> Date: Mon, 25 May 2020 14:39:34 +0800 Subject: [PATCH 09/11] refine format --- troubleshoot-cpu-issues.md | 99 ++++++++++++++++++++++---------------- 1 file changed, 57 insertions(+), 42 deletions(-) diff --git a/troubleshoot-cpu-issues.md b/troubleshoot-cpu-issues.md index b59e9e148c91..eabd0ddccfae 100644 --- a/troubleshoot-cpu-issues.md +++ b/troubleshoot-cpu-issues.md @@ -1,11 +1,11 @@ --- -title: CPU 占用较多、读写延时增加、抖动 +title: CPU 占用过多导致读写延迟增加 summary: 介绍读写延时增加、抖动时的排查思路，可能的原因和解决方法。 -category: troubleshoot-cpu-issues +category: troubleshoot --- -# CPU 占用较多、读写延时增加、抖动 +# CPU 占用过多导致读写延迟增加 -本文档介绍读写延时增加、抖动时的排查思路，可能的原因和解决方法。 +本文档介绍 CPU 占用过多导致读写延迟增加、抖动时的排查思路，可能的原因和解决方法。 ## 常见原因 @@ -15,9 +15,9 @@ category: troubleshoot-cpu-issues **现象：** -* 如果慢日志中输出了执行计划，可以直接查看执行计划。用 `select tidb_decode_plan('xxx...')` 的 SQL 语句可以解析出具体的执行计划。 +* 如果慢日志中输出了执行计划，可以直接查看执行计划。用 `select tidb_decode_plan('xxx...')` 语句可以解析出具体的执行计划。 * 监控中的 key 扫描异常升高；慢日志中 SQL 执行时间 `Scan Keys` 数目较大。 -* SQL 执行时间相比于其他数据库(例如 MySQL)有较大差距。可以对比其他数据库执行计划，例如 `Join Order` 是否不同。 +* SQL 执行时间相比于其他数据库（例如 MySQL）有较大差距。可以对比其他数据库执行计划，例如 `Join Order` 是否不同。 **可能的原因：** @@ -26,54 +26,69 @@ category: troubleshoot-cpu-issues **解决方案：** * 更新统计信息 - * 手动 analyze table，配合 crontab 定期 analyze，维持统计信息准确度 - * 自动 auto analyze，调低 analyze ratio 阈值，提高收集频次，并设置运行时间窗口 - * set global tidb_auto_analyze_ratio=0.2; - * set global tidb_auto_analyze_start_time='00:00 +0800'; - * set global tidb_auto_analyze_end_time='06:00 +0800'; + * 手动 `analyze table`，配合 crontab 定期 `analyze`，维持统计信息准确度。 + * 自动 `auto analyze`，调低 `analyze ratio` 阈值，提高收集频次，并设置运行时间窗口。示例如下： + * `set global tidb_auto_analyze_ratio=0.2;` + * `set global tidb_auto_analyze_start_time='00:00 +0800';` + * `set global tidb_auto_analyze_end_time='06:00 +0800';` * 绑定执行计划 - * 修改业务 SQL ，使用 use index 固定使用列上的索引 - * 3.0 版本下，业务可以不用修改 SQL，使用 create binding 创建 force index 的绑定 SQL - * 4.0 版本支持 SQL Plan Management，可以避免执行计划不稳定导致的性能下降 + * 修改业务 SQL，使用 `use index` 固定使用列上的索引。 + * v3.0 版本下，业务可以不用修改 SQL，使用 `create binding` 创建 `force index` 的绑定 SQL。 + * 4.0 版本支持 SQL Plan Management，可以避免因执行计划不稳定导致的性能下降。 ### PD 异常 **现象：** -监控中 PD TSO wait duration 异常升高。wait duration 代表从开始等待 pd 返回，到等待结束的时间。 +监控中 PD TSO 的 **wait duration** 异常升高。**wait duration** 代表从开始等待 PD 返回，到等待结束的时间。 **可能的原因：** -* 磁盘问题，PD 所在的节点 I/O 被打满，排查是否有其他 I/O 高的组件与 PD 混部以及盘的健康情况，可通过监控 grafana -> disk performance -> latency 和 load 等指标进行验证，必要时可以使用 fio 工具对盘进行检测，见案例 [case-292](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case292.md) -* PD 之间网络问题，PD 日志中有 `"lost the TCP streaming connection"`，排查 PD 之间网络是否有问题，可通过监控 grafana -> PD -> etcd 的 round trip 来验证，见案例 [case-177](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case177.md) -* 系统 load 高，日志中能看到 `"server is likely overloaded"`，见案例 [case-214](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case214.md) -* 选不出 leader，PD 日志中有 `"lease is not expired"`，见 issues [https://github.com/etcd-io/etcd/issues/10355](https://github.com/etcd-io/etcd/issues/10355) v3.0.x 版本和 v2.1.19 版本已 fix 该问题，见案例 [case-875](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case875.md) -* 选举慢，region 加载时间长，从 PD 日志中 `grep "regions cost"`（例如日志中可能是 load 460927 regions cost 11.77099s）, 如果出现秒级，则说明较慢，v3.0 版本可开启 region storage（设置 `use-region-storage` 为 true），该特性能极大缩短加载 region 的时间，见案例 [case-429](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case429.md) -* TiDB -> PD 网络问题，排查网络相关情况。通过监控 grafana -> blackbox_exporter -> ping latency 确定 TiDB 到 PD leader 的网络是否正常 -* PD 报 `FATAL` 错误，日志中有 `"range failed to find revision pair"`，3.0.8 已经 fix 改问题，见 PR [https://github.com/pingcap/pd/pull/2040](https://github.com/pingcap/pd/pull/2040) 详情请参考案例 [case-947](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case947.md) -* 使用 /api/v1/regions 接口时 region 数量过多可能会导致 PD OOM，v3.0.8 版本修复，见 [https://github.com/pingcap/pd/pull/1986](https://github.com/pingcap/pd/pull/1986) -* 滚动升级的时候 PD OOM，gRPC 消息大小没限制，监控可看到 TCP InSegs 较大，v3.0.6 版本修复，见 [https://github.com/pingcap/pd/pull/1952](https://github.com/pingcap/pd/pull/1952) 详情请参考案例 [case-852](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case852.md) -* PD panic，报 bug -* 其他原因，通过 `curl http://127.0.0.1:2379/debug/pprof/goroutine?debug=2` 抓 goroutine，报 bug +* 磁盘问题。PD 所在的节点 I/O 被打满，排查是否有其他 I/O 高的组件与 PD 混合部署以及盘的健康情况，可通过监控 Grafana -> **disk performance** -> **latency** 和 **load** 等指标进行验证，必要时可以使用 fio 工具对盘进行检测，见案例 [case-292](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case292.md)。 + +* PD 之间的网络问题。PD 日志中有 `"lost the TCP streaming connection"`，排查 PD 之间网络是否有问题，可通过监控 Grafana -> **PD** -> **etcd** 的 **round trip** 来验证，见案例 [case-177](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case177.md)。 + +* 系统负载高，日志中能看到 `"server is likely overloaded"`，见案例 [case-214](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case214.md)。 + +* 选不出 leader。PD 日志中有 `"lease is not expired"`，见 issues [https://github.com/etcd-io/etcd/issues/10355](https://github.com/etcd-io/etcd/issues/10355)。v3.0.x 版本和 v2.1.19 版本已解决该问题，见案例 [case-875](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case875.md)。 + +* 选举慢。Region 加载时间长，从 PD 日志中 `grep "regions cost"`（例如日志中可能是 `load 460927 regions cost 11.77099s`）, 如果出现秒级，则说明较慢，v3.0 版本可开启 Region Storage（设置 `use-region-storage` 为 `true`），该特性能极大缩短加载 Region 的时间，见案例 [case-429](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case429.md)。 + +* TiDB 与 PD 之间的网络问题，应排查网络相关情况。通过监控 Grafana -> **blackbox_exporter** -> **ping latency** 确定 TiDB 到 PD leader 的网络是否正常。 + +* PD 报 `FATAL` 错误，日志中有 `"range failed to find revision pair"`。v3.0.8 中已经解决问题，见 PR [https://github.com/pingcap/pd/pull/2040](https://github.com/pingcap/pd/pull/2040)。详情请参考案例 [case-947](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case947.md)。 + +* 使用 `/api/v1/regions` 接口时 Region 数量过多可能会导致 PD OOM。已于 v3.0.8 版本修复，见 [https://github.com/pingcap/pd/pull/1986](https://github.com/pingcap/pd/pull/1986)。 + +* 滚动升级的时候 PD OOM，gRPC 消息大小没限制，监控可看到 TCP InSegs 较大，已于 v3.0.6 版本修复，见 [https://github.com/pingcap/pd/pull/1952](https://github.com/pingcap/pd/pull/1952)。详情请参考案例 [case-852](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case852.md)。 + +* PD panic，报 bug。 + +* 其他原因，通过 `curl http://127.0.0.1:2379/debug/pprof/goroutine?debug=2` 抓取 goroutine，报 bug。 ### TiKV 异常 **现象：** -监控中 KV Cmd Duration 异常升高。KV Cmd Duration 是 TiDB 发送请求给 TiKV 到收到回复的延迟。 +监控中 **KV Cmd Duration** 异常升高。KV Cmd Duration 是 TiDB 发送请求给 TiKV 到收到回复的延迟。 **可能的原因：** -* 查看 gRPC duration，gRPC duration 是请求在 TiKV 端的总耗时。通过对比 TiKV 的 gRPC duration 以及 TiDB 中的 KV duration 可以发现潜在的网络问题。比如 gRPC duration 很短但是 TiDB 的 KV duration 显示很长，说明 TiDB 和 TiKV 之间网络延迟可能很高，或者 TiDB 和 TiKV 之间的网卡带宽打满了。 +* 查看 gRPC duration。gRPC duration 是请求在 TiKV 端的总耗时。通过对比 TiKV 的 gRPC duration 以及 TiDB 中的 KV duration 可以发现潜在的网络问题。比如 gRPC duration 很短但是 TiDB 的 KV duration 显示很长，说明 TiDB 和 TiKV 之间网络延迟可能很高，或者 TiDB 和 TiKV 之间的网卡带宽打满了。 + * TiKV 重启了导致重新选举 - * TiKV `panic` 之后又被 systemd 重新拉起正常运行，可以通过查看 TiKV 的日志来确认是否有 `panic`，这种情况属于非预期，需要报 bug - * 被第三者 `stop/kill`，被 systemd 重新拉起。查看 `dmesg` 和 `TiKV log` 确认原因 - * TiKV 发生 OOM 导致重启了 - * 动态调整 `THP` 导致 hung 住，见案例 [case-500](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case500.md) -* 查看监控：grafana -> TiKV-details -> errors 面板 `server is busy` 看到 TiKV RocksDB 出现 write stall 导致发生重新选举 -* TiKV 发生网络隔离导致重新选举 -* `block-cache` 配置太大导致 OOM，在监控 grafana -> TiKV-details 选中对应的 instance 之后查看 RocksDB 的 `block cache size` 监控来确认是否是该问题。同时请检查 `[storage.block-cache] capacity = # "1GB"` 参数是否设置合理，默认情况下 TiKV 的 `block-cache` 设置为机器总内存的 `45%`;在 container 部署的时候需要显式指定该参数，因为 TiKV 获取的是物理机的内存，可能会超出 container 的内存限制。 -* coprocessor 收到大量大查询，返回的数据量太大，gRPC 发送速度跟不上 coprocessor 往外吐数据的速度导致 OOM。可以通过检查监控： grafana -> TiKV-details -> coprocessor overview 的 `response size` 是否超过 `network outbound` 流量来确认是否属于这种情况。 + * TiKV panic 之后又被 `systemd` 重新拉起正常运行，可以通过查看 TiKV 的日志来确认是否有 `panic`，这种情况属于非预期，需要报 bug。 + * 被第三者 `stop`/`kill`，被 `systemd` 重新拉起。查看 `dmesg` 和 `TiKV log` 确认原因。 + * TiKV 发生 OOM 导致重启了。 + * 动态调整 `THP` 导致 hung 住，见案例 [case-500](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case500.md)。 + +* 查看监控：Grafana -> **TiKV-details** -> **errors** 面板 `server is busy` 看到 TiKV RocksDB 出现 write stall 导致发生重新选举。 + +* TiKV 发生网络隔离导致重新选举。 + +* `block-cache` 配置太大导致 OOM，在监控 Grafana -> **TiKV-details** 选中对应的 instance 之后查看 RocksDB 的 `block cache size` 监控来确认是否是该问题。同时请检查 `[storage.block-cache] capacity = # "1GB"` 参数是否设置合理，默认情况下 TiKV 的 `block-cache` 设置为机器总内存的 `45%`;在 container 部署的时候需要显式指定该参数，因为 TiKV 获取的是物理机的内存，可能会超出 container 的内存限制。 + +* Coprocessor 收到大量大查询，返回的数据量太大，gRPC 发送速度跟不上 Coprocessor 往外吐数据的速度导致 OOM。可以通过检查监控： Grafana -> **TiKV-details** -> **coprocessor overview** 的 `response size` 是否超过 `network outbound` 流量来确认是否属于这种情况。 ### TiKV 单线程瓶颈 @@ -81,7 +96,7 @@ TiKV 中存在一些单线程线程，可能会成为瓶颈。 * 单个 TiKV region 过多导致单个 gRPC 线程成为瓶颈（查看 grafana -> TiKV-details -> `Thread CPU/gRPC CPU Per Thread` 监控），v3.x 以上版本可以开启 `hibernate region` 特性来解决，见案例 [case-612](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case612.md)。 * v3.0 之前版本 raftstore 单线程或者 apply 单线程到达瓶颈（grafana -> TiKV-details -> `Thread CPU/raft store CPU 和 Async apply CPU` 超过 `80%`），可以选择扩容 TiKV（v2.x 版本）实例或者升级到多线程模型的 v3.x 版本，见案例 [case-517](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case517.md)。 - + ### CPU Load 升高 **现象：** @@ -90,8 +105,8 @@ CPU 资源使用到达瓶颈 **可能的原因：** -* 热点问题 -* 整体负载高，排查 TiDB 的 slow_query 和 expensive_query。对运行的 query 进行优化，缺索引的加索引，可以做 batch 的做 batch 改造。另一个方案是对集群进行扩容。 +* 热点问题。 +* 整体负载高，排查 TiDB 的 slow query 和 expensive query。对运行的 query 进行优化，缺索引的加索引，可以做 batch 的做 batch 改造。另一个方案是对集群进行扩容。 ## 其它原因 @@ -101,7 +116,7 @@ CPU 资源使用到达瓶颈 ### 少数派副本离线 -TiDB 集群默认配置为 3 副本，每一个 Region 都会在集群中保存 3 份，它们之间通过 Raft 协议来选举 Leader 并同步数据。Raft 协议可以保证在数量小于副本数（注意，不是节点数）一半的节点挂掉或者隔离的情况下，仍然能够提供服务，并且不丢失任何数据。 对于 3 副本集群，挂掉一个节点除了可能会导致性能有抖动之外，可用性和正确性理论上不会受影响 +TiDB 集群默认配置为 3 副本，每一个 Region 都会在集群中保存 3 份，它们之间通过 Raft 协议来选举 Leader 并同步数据。Raft 协议可以保证在数量小于副本数（注意：不是节点数）一半的节点挂掉或者隔离的情况下，仍然能够提供服务，并且不丢失任何数据。对于 3 副本集群，挂掉一个节点除了可能会导致性能有抖动之外，可用性和正确性理论上不会受影响 ### 新增索引 @@ -111,9 +126,9 @@ TiDB 集群默认配置为 3 副本，每一个 Region 都会在集群中保存 目前主要使用 `tidb_ddl_reorg_worker_cnt` 和 `tidb_ddl_reorg_batch_size` 这两个参数来动态调整索引创建速度，通常来说它们的值越小对系统影响越小，但是执行时间越长。 -一般情况下，先将值保持为默认的 4 和 256 ，观察集群资源使用情况和响应速度，再逐渐调大 `tidb_ddl_reorg_worker_cnt` 参数来增加并发，观察监控如果系统没有发生明显的抖动，再逐渐调大 `tidb_ddl_reorg_batch_size` 参数，但如果索引涉及的列更新很频繁的话就会造成大量冲突造成失败重试。 +一般情况下，先将值保持为默认的 `4` 和 `256` ，观察集群资源使用情况和响应速度，再逐渐调大 `tidb_ddl_reorg_worker_cnt` 参数来增加并发，观察监控如果系统没有发生明显的抖动，再逐渐调大 `tidb_ddl_reorg_batch_size` 参数，但如果索引涉及的列更新很频繁的话就会造成大量冲突造成失败重试。 -另外还可以通过调整参数 `tidb_ddl_reorg_priority` 为 PRIORITY_HIGH 来让创建索引的任务保持高优先级来提升速度，但在通用 OLTP 系统上，一般建议保持默认。 +另外还可以通过调整参数 `tidb_ddl_reorg_priority` 为 `PRIORITY_HIGH` 来让创建索引的任务保持高优先级来提升速度，但在通用 OLTP 系统上，一般建议保持默认。 ### GC 压力大 From 03ad70fe253f7a21d45be5de474035060473f6bd Mon Sep 17 00:00:00 2001 From: pepezzzz <35323945+pepezzzz@users.noreply.github.com> Date: Tue, 26 May 2020 11:56:32 +0800 Subject: [PATCH 10/11] Spoken language modified to written language --- troubleshoot-cpu-issues.md | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/troubleshoot-cpu-issues.md b/troubleshoot-cpu-issues.md index eabd0ddccfae..a5da4ea96911 100644 --- a/troubleshoot-cpu-issues.md +++ b/troubleshoot-cpu-issues.md @@ -3,15 +3,15 @@ title: CPU 占用过多导致读写延迟增加 summary: 介绍读写延时增加、抖动时的排查思路，可能的原因和解决方法。 category: troubleshoot --- -# CPU 占用过多导致读写延迟增加 +# CPU 占用率过高导致读写延迟增加 -本文档介绍 CPU 占用过多导致读写延迟增加、抖动时的排查思路，可能的原因和解决方法。 +本文档介绍 CPU 占用率过高导致读写延迟增加、抖动时的排查思路，可能的原因和解决方法。 ## 常见原因 ### TiDB 执行计划不对导致延迟增高 -查询计划不稳定，偶尔执行计划走到错误的索引，导致查询延迟增加。 +查询语句的执行计划不稳定，偶尔执行计划选择错误的索引，导致查询延迟增加。 **现象：** @@ -33,7 +33,7 @@ category: troubleshoot * `set global tidb_auto_analyze_end_time='06:00 +0800';` * 绑定执行计划 * 修改业务 SQL，使用 `use index` 固定使用列上的索引。 - * v3.0 版本下，业务可以不用修改 SQL，使用 `create binding` 创建 `force index` 的绑定 SQL。 + * v3.0 版本下，业务可以不用修改 SQL，使用 `create global binding` 创建 `force index` 的绑定 SQL。 * 4.0 版本支持 SQL Plan Management，可以避免因执行计划不稳定导致的性能下降。 ### PD 异常 @@ -44,13 +44,13 @@ category: troubleshoot **可能的原因：** -* 磁盘问题。PD 所在的节点 I/O 被打满，排查是否有其他 I/O 高的组件与 PD 混合部署以及盘的健康情况，可通过监控 Grafana -> **disk performance** -> **latency** 和 **load** 等指标进行验证，必要时可以使用 fio 工具对盘进行检测，见案例 [case-292](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case292.md)。 +* 磁盘问题。PD 所在的节点 I/O 被占满，排查是否有其他 I/O 高的组件与 PD 混合部署以及磁盘的健康情况，可通过监控 Grafana -> **disk performance** -> **latency** 和 **load** 等指标进行验证，必要时可以使用 fio 工具对盘进行检测，见案例 [case-292](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case292.md)。 * PD 之间的网络问题。PD 日志中有 `"lost the TCP streaming connection"`，排查 PD 之间网络是否有问题，可通过监控 Grafana -> **PD** -> **etcd** 的 **round trip** 来验证，见案例 [case-177](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case177.md)。 * 系统负载高，日志中能看到 `"server is likely overloaded"`，见案例 [case-214](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case214.md)。 -* 选不出 leader。PD 日志中有 `"lease is not expired"`，见 issues [https://github.com/etcd-io/etcd/issues/10355](https://github.com/etcd-io/etcd/issues/10355)。v3.0.x 版本和 v2.1.19 版本已解决该问题，见案例 [case-875](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case875.md)。 +* 选举不出 leader。PD 日志中有 `"lease is not expired"`，见 issues [https://github.com/etcd-io/etcd/issues/10355](https://github.com/etcd-io/etcd/issues/10355)。v3.0.x 版本和 v2.1.19 版本已解决该问题，见案例 [case-875](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case875.md)。 * 选举慢。Region 加载时间长，从 PD 日志中 `grep "regions cost"`（例如日志中可能是 `load 460927 regions cost 11.77099s`）, 如果出现秒级，则说明较慢，v3.0 版本可开启 Region Storage（设置 `use-region-storage` 为 `true`），该特性能极大缩短加载 Region 的时间，见案例 [case-429](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case429.md)。 @@ -74,7 +74,7 @@ category: troubleshoot **可能的原因：** -* 查看 gRPC duration。gRPC duration 是请求在 TiKV 端的总耗时。通过对比 TiKV 的 gRPC duration 以及 TiDB 中的 KV duration 可以发现潜在的网络问题。比如 gRPC duration 很短但是 TiDB 的 KV duration 显示很长，说明 TiDB 和 TiKV 之间网络延迟可能很高，或者 TiDB 和 TiKV 之间的网卡带宽打满了。 +* 查看 gRPC duration。gRPC duration 是请求在 TiKV 端的总耗时。通过对比 TiKV 的 gRPC duration 以及 TiDB 中的 KV duration 可以发现潜在的网络问题。比如 gRPC duration 很短但是 TiDB 的 KV duration 显示很长，说明 TiDB 和 TiKV 之间网络延迟可能很高，或者 TiDB 和 TiKV 之间的网卡带宽被占满。 * TiKV 重启了导致重新选举 * TiKV panic 之后又被 `systemd` 重新拉起正常运行，可以通过查看 TiKV 的日志来确认是否有 `panic`，这种情况属于非预期，需要报 bug。 @@ -86,9 +86,9 @@ category: troubleshoot * TiKV 发生网络隔离导致重新选举。 -* `block-cache` 配置太大导致 OOM，在监控 Grafana -> **TiKV-details** 选中对应的 instance 之后查看 RocksDB 的 `block cache size` 监控来确认是否是该问题。同时请检查 `[storage.block-cache] capacity = # "1GB"` 参数是否设置合理，默认情况下 TiKV 的 `block-cache` 设置为机器总内存的 `45%`;在 container 部署的时候需要显式指定该参数，因为 TiKV 获取的是物理机的内存，可能会超出 container 的内存限制。 +* `block-cache` 配置太大导致 OOM，在监控 Grafana -> **TiKV-details** 选中对应的 instance 之后查看 RocksDB 的 `block cache size` 监控来确认是否是该问题。同时请检查 `[storage.block-cache] capacity = # "1GB"` 参数是否设置合理，默认情况下 TiKV 的 `block-cache` 设置为机器总内存的 `45%`;在容器化部署时需要显式指定该参数，因为 TiKV 获取的是物理机的内存，可能会超出单个 container 的内存限制。 -* Coprocessor 收到大量大查询，返回的数据量太大，gRPC 发送速度跟不上 Coprocessor 往外吐数据的速度导致 OOM。可以通过检查监控： Grafana -> **TiKV-details** -> **coprocessor overview** 的 `response size` 是否超过 `network outbound` 流量来确认是否属于这种情况。 +* Coprocessor 收到大量大查询，返回的数据量太大，gRPC 发送速度跟不上 Coprocessor 向客户端输出数据的速度导致 OOM。可以通过检查监控： Grafana -> **TiKV-details** -> **coprocessor overview** 的 `response size` 是否超过 `network outbound` 流量来确认是否属于这种情况。 ### TiKV 单线程瓶颈 @@ -116,11 +116,11 @@ CPU 资源使用到达瓶颈 ### 少数派副本离线 -TiDB 集群默认配置为 3 副本，每一个 Region 都会在集群中保存 3 份，它们之间通过 Raft 协议来选举 Leader 并同步数据。Raft 协议可以保证在数量小于副本数（注意：不是节点数）一半的节点挂掉或者隔离的情况下，仍然能够提供服务，并且不丢失任何数据。对于 3 副本集群，挂掉一个节点除了可能会导致性能有抖动之外，可用性和正确性理论上不会受影响 +TiDB 集群默认配置为 3 副本，每一个 Region 都会在集群中保存 3 份，它们之间通过 Raft 协议来选举 Leader 并同步数据。Raft 协议可以保证在数量小于副本数（注意：不是节点数）一半的节点挂掉或者隔离的情况下，仍然能够提供服务，并且不丢失任何数据。对于 3 副本集群，挂掉一个节点可能会导致性能抖动，可用性和正确性理论上不会受影响。 ### 新增索引 -由于创建索引在扫表回填索引的时候会消耗大量资源，甚至与一些频繁更新的字段会发生冲突导致正常业务受到影响。大表创建索引的过程往往会持续很长时间，所以要尽可能地平衡执行时间和集群性能之间的关系。 +由于创建索引在扫表回填索引的时候会消耗大量资源，甚至与一些频繁更新的字段会发生冲突导致正常业务受到影响。大表创建索引的过程往往会持续很长时间，所以要尽可能地平衡执行时间和集群性能之间的关系，比如选择非高频更新时间段。 **参数调整：** From 119903a18077ca7a3a7af1d927b7676244b36353 Mon Sep 17 00:00:00 2001 From: TomShawn <41534398+TomShawn@users.noreply.github.com> Date: Tue, 26 May 2020 13:30:18 +0800 Subject: [PATCH 11/11] Update troubleshoot-cpu-issues.md --- troubleshoot-cpu-issues.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/troubleshoot-cpu-issues.md b/troubleshoot-cpu-issues.md index a5da4ea96911..b0d2f4b541fb 100644 --- a/troubleshoot-cpu-issues.md +++ b/troubleshoot-cpu-issues.md @@ -33,7 +33,8 @@ category: troubleshoot * `set global tidb_auto_analyze_end_time='06:00 +0800';` * 绑定执行计划 * 修改业务 SQL，使用 `use index` 固定使用列上的索引。 - * v3.0 版本下，业务可以不用修改 SQL，使用 `create global binding` 创建 `force index` 的绑定 SQL。 + * 3.0 版本下，业务可以不用修改 SQL，使用 `create global binding` 创建 `force index` 的绑定 SQL。 + * 4.0 版本支持 SQL Plan Management，可以避免因执行计划不稳定导致的性能下降。 ### PD 异常