tidb memoy和cpu随着运行的时间一直向上增加,低谷期也没有明显的回落

【 TiDB 使用环境】生产环境
【 TiDB 版本】v7.5.5
【遇到的问题:问题现象及影响】
从tidb v6.5.11升级到v7.5.5后,随着运行时间的推移,tidb实例的内存和cpu不断走高,在凌晨低谷期也没有回落的趋势,影响系统正常使用.通过reload tidb节点后,内存和cpu可以降下来.
【资源配置】


【其他附件:截图/日志/监控】
2月9号凌晨进行的升级, 在2月11号23点左右内存跑了75%左右.
手工进行realod后,内存和cpu回落,2月12后到当前时间,还在持续走高.
备注: 三台tidb节点,tidb-70是低配,haproxy分配的权重很低,所以数据看着比较正常

把时间范围调小,观察到cpu大概是2分半跳高一次,比较有规律.

通过profiling看,内存占用NewSessionVar 占了比较高的比例,调低应用连接数后,内存也无明显变化

CPU看着gc占了比较大的比例

怀疑是存在内存泄露,导致触发gc,但gc又回收不掉,所以频繁gc

是不是有 TTL 任务,大概率是这个 bug 。tidb-server其中一台的内存占用很高,cpu也很高,该如何排查

我们没有用到ttl相关功能,看tidb_ttl_job_history也没有数据,tidb内部是否有看不到的ttl ?

tidb 内部没有。你可以通过 dashboard 看下 tidb 的内存火焰图。
https://docs.pingcap.com/zh/tidb/stable/dashboard-profiling

1 个赞

这难道不是自愿瓶颈了吗?扩容吧

比较像这个问题 planner: avoid slicesgrow in the buildDataSource by hawkingrei · Pull Request #58853 · pingcap/tidb · GitHub

1 个赞

log-backup.enable 关闭后观察了几天恢复正常了,但br用不了了,现在靠cdc

2 个赞

和br有关,是有点令人费解。

tiup br升级到和tidb一样的版本,重新建立br快照备份和日志备份呢?

或者看看以前的br log备份是有什么问题嘛?

不过如果cdc是全量往别的地方发送数据的话,br确实可有可无。如果cdc不是全量,没有br pitr备份还是稍微有点不踏实。

升级br看看,还是得定期做一下备份的,保险一点。