tidb内存持续升高

tidb菜鸟一只 · 2025 年5 月 8 日 09:50

tidb-server节点的话，直接设置这个参数SET GLOBAL tidb_server_memory_limit = “32GB”;也可以配置 **tidb_mem_quota_query**这个参数，限定单个sql的内存占用，然后你再去看执行报错的sql，就知道是哪些大sql导致你的tidb-server 内存高了

terry0219 · 2025 年5 月 8 日 10:11

应该不会，我们每天也有br备份，没有出现你这个情况，我用的是7,5的版本

HGHNICE_666 · 2025 年5 月 8 日 10:14

我7.5也没这个问题

residentevil · 2025 年5 月 9 日 04:09

看下tikv-client.copr-cache.capacity-mb这配置阈值是多少？

HGHNICE_666 · 2025 年5 月 12 日 02:07

这个配置也是使用的默认值的还没有单独配置

WalterWj · 2025 年5 月 14 日 02:06

1、升级到 8.5.1 版本试试
2、可以看下是否有长 sql，information_schema.cluster_processlist 这个表做下 time 等过滤排序即可
3、可以看下 tidb runtime 监控，里面有 go gc 相关监控，如果认为是 go gc 不及时可以确定下。
4、go gc 相关可以考虑调整下：https://docs.pingcap.com/zh/tidb/stable/configure-memory-usage/#其它
还有尝试关闭：https://docs.pingcap.com/zh/tidb/stable/system-variables/#tidb_enable_gogc_tuner-从-v640-版本开始引入
5、以上都不行，提供火焰图。

舞动梦灵 · 2025 年5 月 14 日 02:24

先看下是不是SQL导致看下这个，然后看系统日志message有没有OOM。

逍遥_猫 · 2025 年5 月 14 日 02:36

大哥，你这是怎么看出来的？？？

HGHNICE_666 · 2025 年5 月 19 日 02:57

heap (3.2 MB)
goroutine (596.7 KB)
哥有空帮忙看看昨天oom的

WalterWj · 2025 年5 月 20 日 02:36

https://docs.pingcap.com/zh/tidb/stable/system-variables/#tidb_enable_historical_stats
看看这个是关闭的么，不是的话关了试试。

HGHNICE_666 · 2025 年5 月 20 日 03:02

这边查询看了是开启的

我现在关闭看看

有猫万事足 · 2025 年5 月 20 日 15:25

你注意一下每次oom的是不是ddl owner。

https://docs.pingcap.com/zh/tidb/v8.4/sql-statement-admin-show-ddl/#admin-show-ddl

你这个oom的图形，我感觉大概率和统计信息收集有关。

另外，你手动分析以后直接把火焰图贴出来，给个heap文件，还要再找工具看，多麻烦。

HGHNICE_666 · 2025 年5 月 22 日 05:42

好的猫哥这边从监控看还是有一台机器负载不均衡目前预计关闭表统计分析

不懂为什么还是单台不降的上面是这台高内存的图

有猫万事足 · 2025 年5 月 22 日 08:38

你看看这个帖子。

注意mysql.tidb_ddl_notifier这个表的数据是不是很多。
如果是这个问题，那么这个bug在8.5.2修复。

HGHNICE_666 · 2025 年5 月 22 日 09:28

猫哥我这边看我的这张表是空的

有猫万事足 · 2025 年5 月 22 日 11:03

这个图上看，这30+G的内存空间就是在执行一个内部的sql，大概率就是收集统计信息。

https://docs.pingcap.com/zh/tidb/stable/tidb-resource-control-background-tasks/#使用资源管控-resource-control-管理后台任务

尝试通过资源管控控制一下。我这块也没其他的太好的思路了。

有猫万事足 · 2025 年5 月 22 日 11:14

github.com/pingcap/tidb

pkg/domain/historical_stats.go

v8.5.0


      
          	select {
          	case w.tblCH <- tableID:
          		return
          	default:
          		logutil.BgLogger().Warn("discard dump historical stats task", zap.Int64("table-id", tableID))
          	}
          }
          
          // DumpHistoricalStats dump stats by given tableID
          func (w *HistoricalStatsWorker) DumpHistoricalStats(tableID int64, statsHandle *handle.Handle) error {
          	historicalStatsEnabled, err := statsHandle.CheckHistoricalStatsEnable()
          	if err != nil {
          		return errors.Errorf("check tidb_enable_historical_stats failed: %v", err)
          	}
          	if !historicalStatsEnabled {
          		return nil
          	}
          	sctx := w.sctx
          	is := GetDomain(sctx).InfoSchema()
          	isPartition := false
          	var tblInfo *model.TableInfo

看你这个版本的代码，这块确实和 @WalterWj 提到的这个变量有关，一进来就会看这个变量是不是开启的。如果是OFF，就直接返回了。

理论上如果你关闭了这个变量。

就不应该有这一条存在。

建议global设置这个变量为OFF，重启所有tidb节点。看看还会不会复现。

HGHNICE_666 · 2025 年5 月 23 日 01:19

看样子是可以了猫哥总体比较稳定了

HGHNICE_666 · 2025 年5 月 23 日 01:23

感谢大佬问题解决了

system · 2025 年5 月 30 日 01:24

此话题已在最后回复的 7 天后被自动关闭。不再允许新回复。