TiDB-server OOM，日志发现很多PD相关报错，“fail to load safepoint from pd”等。

[TiDBer_spike]

为提高效率，请提供以下信息，问题描述清晰能够更快得到解决：
【概述】
场景及问题：晚上21:10，监控告警tidb-server节点持续oom，陡增陡降。tidb.log日志发现很多pd ts相关报错。

【背景】晚上21点会有任务 mydumper 进行数据库备份导出，导出报错。
** (mydumper:24893): CRITICAL **: 21:29:52.933: Could not read data from db.table: PD server timeout%!(EXTRA string=start timestamp may fall behind safe point)
【现象】一个tidb-server节点持续 oom，该节点连接断开
【业务影响】
【TiDB 版本】
TiDB v5.3.0
【附件】
TiDB.Mem：

Blackbox Exporter.ping latency监控 (该tidb节点ping其他角色)：

日志：

tidb_stderr.log：

tidb.log tidb-0330.log (203.3 KB)

• 相关日志 和 监控

1. TiUP Cluster Display 信息

2. TiUP Cluster Edit Config 信息

3. TiDB- Overview 监控

• 对应模块日志（包含问题前后1小时日志）

[xfworld (魔幻之翼)]

PD 在哪个时间段正常么？

1. 查阅 PD leader 网络流量是否正常
2. 查阅 PD leader TSO 的处理延迟是否正常

然后 tidb 这边也可以配合查一下

1. 网络流量是否被打满了？
2. 获取 TSO 的延时情况

[TiDBer_spike]

[quote=“xfworld, post:2, topic:632813”]
PD leader TSO 的处理延迟：

TiDB获取 TSO 的延时情况：

[TiDBer_spike]

麻烦老师先看看呢，网络流量情况还在看

[xfworld (魔幻之翼)]

网络慢了

首先立马查看 PD TSO RPC Duration，其正常数值范围 80% 差不多在 1ms 以内，99% 在 4ms 内，如果数值比较高，则说明网络和 PD 的处理时间长（包括 Go Runtime 调度和实际 TSO 处理逻辑），此时继续看 PD server TSO handle time + Client revc time 是否慢，如果不慢则说明 PD TSO 处理（和发送）不慢，大概率是网络问题，需要往网络问题方向排查。

PD 卡了

如果 PD server TSO handle time + Client revc time 慢：

• 如果是 v4.0.13 版本及以后，由于这个监控其实只包括了 PD leader 处理 TSO 时间，所以它慢说明 PD TSO 处理的慢，此时应该考察 PD Leader 的 CPU 占用情况是否较高？以及是否存在混布（混合部署）的情况，即同一台机器上有其他的进程或操作扰乱了 PD 的计算，影响了 TSO 的处理速度。
• 如果是 v4.0.13 版本之前（不包括），那么说明 PD leader 处理 TSO 时间慢或回传给客户端的发送时间慢或两者都比较慢，需要同时考虑上述 PD CPU 问题以及 PD 到 TiDB 之间的网络问题。

还有一个情况也会影响到 PD 的 TSO 分配——PD 出现了 leader 切换，不过一般出现 leader 切换，直接会导致 TSO 不可用，并不能是让 TSO 变慢的原因，只在此一提，仅供参考。

TSO 慢排查手册 v2.0——2022.03.11 更新

时过境迁，随着客户量的增加和代码的更新换代，TSO 的一些细节和监控都发生了些许变化，所以在此重新归纳整理，推出 TSO 慢排查手册 v2.0 版本。 [image] 监控项详解 TiDB 侧监控 PD TSO OPS [image] 位置：TiDB - PD Client 每秒的 TSO 请求个数和实际发送到 PD 的 gRPC 请求数量。 cmd 代表 TiDB 侧 Wait…

---

是一直这样，还是偶发性的？ 从你发的图上来看 PD 的处理速度偏慢了…

[TiDBer_spike]

这种oom的情况比较多，最近一周出现了3次，也做了一些优化，比如设置tidb_analyze_version = 1 、调大mem-quota-query参数等。

[xfworld (魔幻之翼)]

那你得先排除 慢SQL 的问题

1. 设置 SQL 最大执行时间，增加资源可控性
2. 设置 SQL 的最大可用内存，并且开启 磁盘缓存

同时对资源消耗较大的 SQL 进行定位
https://docs.pingcap.com/zh/tidb/stable/identify-expensive-queries

在逐个进行优化…

[TiDBer_spike]

好的老师，还有请问tidb.log 很多gc的报错与这个有关么
[ERROR] [gc_worker.go:713] ["[gc worker] delete range failed on range"] [uuid=5fd934311c40002] [startKey=748000000000
00305f] [endKey=748000000000003060] [error="[gc worker] destroy range finished with errors: [unsafe destroy range failed on store 7: gc worker is too
busy unsafe destroy range failed on store 1: gc worker is too busy unsafe destroy range failed on store 2: gc worker is too busy]"]

[xfworld (魔幻之翼)]

建议你升级吧，貌似是个已经修复的bug

https://docs.pingcap.com/zh/tidb/stable/release-5.3.1

[TiDBer_spike]

好的，升级的事情已经反馈。开启数据落盘缓解OOM有一个问题，tmp-storage-quota参数默认配置的-1，是不会开启落盘的么？

[xfworld (魔幻之翼)]

数据落盘

TiDB 支持对执行算子的数据落盘功能。当 SQL 的内存使用超过 Memory Quota 时，tidb-server 可以通过落盘执行算子的中间数据，缓解内存压力。支持落盘的算子有：Sort、MergeJoin、HashJoin、HashAgg。

• 落盘行为由参数 mem-quota-query 、 oom-use-tmp-storage 、 tmp-storage-path 、 tmp-storage-quota 共同控制。
• 当落盘被触发时，TiDB 会在日志中打印一条包含关键字 memory exceeds quota, spill to disk now 或 memory exceeds quota, set aggregate mode to spill-mode 的日志。

https://docs.pingcap.com/zh/tidb/stable/tidb-configuration-file#oom-use-tmp-storage

[TiDBer_spike]

好的，多谢老师

[TiDBer_spike]

老师请问，设置 SQL 最大执行时间是对应哪个配置项呢

[MrSylar]

[xfworld (魔幻之翼)]

可以根据场景设定一下

https://docs.pingcap.com/zh/tidb/stable/optimizer-hints#max_execution_timen

[TiDBer_spike]

好的，多谢老师们的回复。