TIDB 两个节点内存飙升

[wind (Ti D Ber B Bgs Ljoo)]

【TiDB 使用环境】生产环境
【TiDB 版本】v8.5.1
【操作系统】Linux
【部署方式】AWS tiup部署，使用LB负载转发给3个tidb 4000端口，负载方式是： 轮询(每个节点权重相同)。
【集群数据量】300～500G
【集群节点数】3个tidb/pd(tidb与pd在一个节点)、3个tikv、3个tiflash】
【问题复现路径】未排查到故障原因，没有进行配置相关的操作，没有手动重启节点。
【遇到的问题：问题现象及影响】3个tidb节点，其中两个tidb节点的内存基本拉满。可能是内存拉满导致的这两个节点上有较多业务慢SQL。
【资源配置】

【复制黏贴 ERROR 报错的日志】

【其他附件：截图/日志/监控】
故障tidb节点火焰图

正常tidb节点火焰图

慢查询SQL界面没有消耗内存太多的语句，且3个tidb节点是平均负载的，业务SQL消耗的内存理论上应该是平均的。

和上次单个tidb节点内存飙升问题不一样，mysql.tidb_ddl_notifier正常。

求助大佬们，帮忙看下是哪方面问题吧

[努力学习 (Ti D Ber 1 Wtj Gk4 A)]

42.132节点死了，重启试下

[TiDBer_xx13 (Ti D Ber 3ix3 Rp1 H)]

感谢老师分享

[wind (Ti D Ber B Bgs Ljoo)]

感谢回复，我去试下

[wind (Ti D Ber B Bgs Ljoo)]

那两个内存高的节点重启后，确实恢复了

但是另外那个没重启的节点，看情况有点像是持续运行后增加到这么多的，没释放掉。
目前看起来好像是运行下去就必然复现的一个问题。
能麻烦您帮忙确定下这个问题的根本原因嘛？
另外该问题和tidb_gc_run_interval=10m、tidb_gc_life_time=20m这俩参数是否有关呢？

[wind (Ti D Ber B Bgs Ljoo)]

通过这几天的观察，看问题似乎没有改变性的解决，TiDB内存还是在不断增加中

重启只能临时解决问题，这块是GC的不彻底么？

[随缘天空 (Ti D Ber Ivw R7o Pj)]

把tidb组件的日志拉出来，看看有没有内存溢出的错误，然后找到对应sql语句，优化下

[wind (Ti D Ber B Bgs Ljoo)]

@随缘天空

，看看有没有内存溢出的错误，

感谢回复，之前就看过的，tidb error等级的日志 没有OOM

都是这种无关紧要的提示

[有猫万事足]

日志里面搜

reload schema in loop

有什么内容嘛？

[wind (Ti D Ber B Bgs Ljoo)]

2025-07-06 15:45:22 (UTC+08:00)

TiDB 172...106:4000

[domain.go:1117] [“reload schema in loop failed”] [error=“[tikv:9001]PD server timeout: start timestamp may fall behind safe point”]

确实有报错的，大佬 刚刚就是那台tidb组件的机器出现故障，持续的无响应，几分钟后自己恢复了。
你说的那个日志关键字出现了一次，能麻烦帮忙定位下原因嘛？感谢🙏
ps:我们这边还有个7.5.1版本的TiDB，用着很稳定，没出现过这类情况呢

[有猫万事足]

@wind

2025-07-06 15:45:22 (UTC+08:00)

TiDB 172...106:4000

[domain.go:1117] [“reload schema in loop failed”] [error=“[tikv:9001]PD server timeout: start timestamp may fall behind safe point”]

https://docs.pingcap.com/zh/tidb/stable/error-codes/#mysql-原生报错汇总

• Error Number: 9001 (HY000)完整的报错信息为 ERROR 9001 (HY000): PD server timeout start timestamp may fall behind safe point这个报错一般是 TiDB 访问 PD 出了问题，TiDB 后台有个 worker 会不断地从 PD 查询 safepoint，如果超过 100s 查不成功就会报这个错。一般是因为 PD 磁盘操作过忙、反应过慢，或者 TiDB 和 PD 之间的网络有问题。TiDB 常见错误码请参考错误码与故障诊断。

你下面的日志上看也是有大量的网络异常。

是不是因为什么sql，把你的内网流量打满了？至少tidb到pd从日志上看是连不上的。

[wind (Ti D Ber B Bgs Ljoo)]

AWS上的内网通信，是没问题的，看指标像是那个tidb机器CPU和内存同时飙升，导致影响到那个机器上的pd服务无法响应。（我们的pd和tidb在一个服务器上，共3台tidb/pd）

本质似乎还是tidb内存这边的问题

然后重启这台tidb之前，火焰图：

[有猫万事足]

[domain.go:1117] [“reload schema in loop failed”] [error=“[tikv:9001]PD server timeout: start timestamp may fall behind safe point”]

这个报错就在这个位置。

pkg/domain/domain.go

你要是怀疑前面有问题，最好是能提供一个完整的日志。起码你提供的这个时间点的日志，结论现在看是比较明确的。就是pd没法提供服务了。

[wind (Ti D Ber B Bgs Ljoo)]

还有个现象比较奇怪
查询内存：SELECT * FROM information_schema.memory_usage;
我直连3个TiDB节点

172.*.*.106
SELECT * FROM information_schema.memory_usage;
+--------------+--------------+----------------+-----------------+-------------+-------------------+--------------------+---------------------+----------+------------+------------------+
| MEMORY_TOTAL | MEMORY_LIMIT | MEMORY_CURRENT | MEMORY_MAX_USED | CURRENT_OPS | SESSION_KILL_LAST | SESSION_KILL_TOTAL | GC_LAST             | GC_TOTAL | DISK_USAGE | QUERY_FORCE_DISK |
+--------------+--------------+----------------+-----------------+-------------+-------------------+--------------------+---------------------+----------+------------+------------------+
|  32809394176 |  26247515280 |     8118542336 |     11164213248 | NULL        | NULL              |                  0 | 2025-07-06 18:12:47 |        1 |          0 |                0 |
+--------------+--------------+----------------+-----------------+-------------+-------------------+--------------------+---------------------+----------+------------+------------------+
1 row in set (0.00 sec)


172.*.*.132
+--------------+--------------+----------------+-----------------+-------------+-------------------+--------------------+---------------------+----------+------------+------------------+
| MEMORY_TOTAL | MEMORY_LIMIT | MEMORY_CURRENT | MEMORY_MAX_USED | CURRENT_OPS | SESSION_KILL_LAST | SESSION_KILL_TOTAL | GC_LAST             | GC_TOTAL | DISK_USAGE | QUERY_FORCE_DISK |
+--------------+--------------+----------------+-----------------+-------------+-------------------+--------------------+---------------------+----------+------------+------------------+
|  32809394176 |  26247515280 |    10752163840 |     20545314816 | NULL        | NULL              |                  0 | 2025-07-07 01:39:48 |     5643 |          0 |                0 |
+--------------+--------------+----------------+-----------------+-------------+-------------------+--------------------+---------------------+----------+------------+------------------+
1 row in set (0.00 sec)


172.*.*.83
+--------------+--------------+----------------+-----------------+-------------+-------------------+--------------------+---------------------+----------+------------+------------------+
| MEMORY_TOTAL | MEMORY_LIMIT | MEMORY_CURRENT | MEMORY_MAX_USED | CURRENT_OPS | SESSION_KILL_LAST | SESSION_KILL_TOTAL | GC_LAST             | GC_TOTAL | DISK_USAGE | QUERY_FORCE_DISK |
+--------------+--------------+----------------+-----------------+-------------+-------------------+--------------------+---------------------+----------+------------+------------------+
|  32809394176 |  26247515280 |    11750137856 |     17820385280 | NULL        | NULL              |                  0 | 2025-07-07 01:40:42 |     5375 |          0 |                0 |
+--------------+--------------+----------------+-----------------+-------------+-------------------+--------------------+---------------------+----------+------------+------------------+
1 row in set (0.00 sec)

和Dashboard上展示的内存对不上，且那两个内存高的节点GC次数很大，后来经过对比发现每分钟都在GC。
然后top -c直接查看服务器的内存占用，发现tidb进程确实占用着13、14G。

1. 是专门设计的tidb内存超过10G就会这么频繁触发GC 还是有啥问题呢？
2. 看起来GC没效果且SQL查询的和Dashboard展示的内存也对不上？

[wind (Ti D Ber B Bgs Ljoo)]

@有猫万事足

reload schema in loop

这边导出了故障时间15:38～15:50的log

pd的是warn等级，且3个节点打印类似只导了一个，没有error等级的log
tidb是ERROR等级日志

tidb-pd_log.zip (5.4 KB)

再次感谢帮忙

[有猫万事足]

[2025/07/06 07:40:53.330 +00:00] [Warn] [retry_interceptor.go:63] [“retrying of unary invoker failed”] [target=etcd-endpoints://0xc007dec1e0/172.27.142.132:2379] [attempt=0] [error=“rpc error: code = Unavailable desc = keepalive ping failed to receive ACK within timeout”]

[2025/07/06 07:40:53.331 +00:00] [Warn] [retry_interceptor.go:63] [“retrying of unary invoker failed”] [target=etcd-endpoints://0xc007dec1e0/172.27.142.132:2379] [attempt=1] [error=“rpc error: code = NotFound desc = etcdserver: requested lease not found”]

[2025/07/06 07:40:53.406 +00:00] [Warn] [retry_interceptor.go:63] [“retrying of unary invoker failed”] [target=etcd-endpoints://0xc007dec000/172.27.142.132:2379] [attempt=0] [error=“rpc error: code = DeadlineExceeded desc = context deadline exceeded”]

这是pd的日志，这个就是etcd已经连不上了。

[2025/07/06 07:38:01.614 +00:00] [Error] [distsql.go:1567] [“table reader fetch next chunk failed”] [conn=2217617658] [session_alias=] [error=“context canceled”]

[2025/07/06 07:38:01.614 +00:00] [Error] [distsql.go:1567] [“table reader fetch next chunk failed”] [conn=2217617658] [session_alias=] [error=“context canceled”]

[2025/07/06 07:38:01.614 +00:00] [Error] [select_result.go:562] [“invalid cop task execution summaries length”] [expected=1] [received=0]

这是tidb的日志，就是从tikv获取数据也不行了。

[“invalid cop task execution summaries length”] [expected=1] [received=0]

注意上面这个，意思是获取cop task的执行细节信息，发现没有内容。received=0就是什么也没有收到，至少应该是1。

怎么看都是这个时间点7：38-7：40的时候，整个系统的互相访问已经出了很大的问题。

可以继续往前溯源，起码这个时间点的结论和上面的结论不会有什么差别。

[wind (Ti D Ber B Bgs Ljoo)]

pd这边和tidb是同台机器，tidb连pd、tikv都出问题的话，比较像是tidb自身出现问题。这边想继续溯源的话还有哪些方向或日志可以排查的呢？

刚刚看了下pd warn日志，还有挺多leader get region nil的提示

[有猫万事足]

dashboard里面这个图，你找个和你故障时间对的上的，发出来看看。

[wind (Ti D Ber B Bgs Ljoo)]

2025-07-06 15:30～15:50期间有故障

[有猫万事足]

感觉整体都慢。慢的还挺均匀，写入也是20s左右，查询也是20s左右。

SQL Execute Time Overview这个图里面找tso wait，看看是多少。