开启tidb_enable_non_prepared_plan_cache参数之后，缓存的数量远超tidb_session_plan_cache_size且内存持续上涨，关闭该参数之后，内存和缓存数量依旧上涨

nobody · 2024 年12 月 13 日 02:27

看堆栈是从 storage 加载统计信息的时候需要 copy 当前内存里的统计信息。加载时机是统计信息版本更新。
当时是有大批量的统计信息 analyze 收集任务吗？

有猫万事足 · 2024 年12 月 13 日 11:26

我前面就提醒你了，session级修改只影响你当前那个session。

SET tidb_enable_non_prepared_plan_cache = ON;

你这都没加 global。还好是你自己发出来的，不然真说不清了。

有猫万事足 · 2024 年12 月 13 日 11:30

老鹰506 · 2024 年12 月 16 日 01:44

有的，

SET @@global.tidb_enable_non_prepared_plan_cache = OFF ;

然后show global 查看也是关闭的状态

老鹰506 · 2024 年12 月 16 日 01:47

是刚开始没有添加，后面的语句有添加的global 包括12号那天调整的时候也是，开启关闭都是global ， 13:07 关闭之后有下降，但不是立即下降，所以觉得应该有另外的缓存失效时间控制

老鹰506 · 2024 年12 月 16 日 01:57

没有大批量做 analyze 统计，从mysql.analyze_jobs 就能看到

但是之前遇到过另外一个集群因为statistics导致oom的问题，当时是调整慢查阈值，倒是慢查增多。

多以本次调大慢查阈值有缓解，但是问题还在

老鹰506 · 2024 年12 月 16 日 02:03

哦哦，这个知道

nobody · 2024 年12 月 16 日 03:03

这都是 12 号的，11 号是没有数据吗？你的内存增加是 11 号开始的

老鹰506 · 2024 年12 月 16 日 03:22

一样的，11号12号都做调试了，没有集中那个小时很高的执行analyze

nobody · 2024 年12 月 16 日 03:30

不能单看 analyze 个数，也要看 analyze 涉及的表的字段数、字段类型、索引数量、数据量等，
这些才会实质性的影响内存使用。