为什么分析表的语句内存占用显示很大

zhanggame1 · 2023 年12 月 6 日 06:47

【 TiDB 使用环境】生产环境 /测试/ Poc
【 TiDB 版本】7.5
【复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】
做一个表分析ANALYZE table ticket2;，分区表，数据量2700万，做了大概3分钟，分析时候看processlist的mem特别大

小龙虾爱大龙虾 · 2023 年12 月 6 日 08:15

感觉是显示错误吧，你有这么大内存吗

Jellybean · 2023 年12 月 6 日 13:10

转换为GB看看具体有多大的值

zhanggame1 · 2023 年12 月 6 日 13:39

应该是显示错误吧，人类还没这么大内存的机器

有猫万事足 · 2023 年12 月 6 日 15:43

这个数字是大的离谱，如果能复现的话，应该算作bug。

dba远航 · 2023 年12 月 7 日 01:01

这应该是累积值，不是单次值，所以大家千万别弄错了

zhanggame1 · 2023 年12 月 7 日 01:14

就算累计也过于离谱，我们是测试的小数据库没多少内存

tidb菜鸟一只 · 2023 年12 月 7 日 03:05

processlist里面的内存我都当他闹着玩的，一点也不准。。。

zhanggame1 · 2023 年12 月 7 日 03:49

有靠谱的看session内存占用情况的吗

TiDBer_lBAxWjWQ · 2023 年12 月 7 日 05:59

就算式累计值也不太准吧，太大了

Hacker007 · 2023 年12 月 7 日 06:57

这个多个任务累加的值吧

Jellybean · 2023 年12 月 7 日 15:13

印象中还没可以实时查看会话级别的内存使用量的地方。

日志到是会打印内存过多的SQL，实例节点的就可以通过grafana看，不过粒度太粗了。

内存使用可观测性目前是TiDB亟待优化的功能要点

Kongdom · 2023 年12 月 8 日 09:41

应该是累计值，估计是表太大，一次没analyze完成，遇到gc或者其他情况，导致重新analyze，然后内存就累加了。

江湖故人 · 2023 年12 月 23 日 15:19

不是累积值，大家看这个问题[1]
17秒这么大MEM：

YuchongXU · 2023 年12 月 24 日 00:18

累加的数值

zhanggame1 · 2023 年12 月 24 日 04:26

都有规律，1844开头得，是不是一个地址

江湖故人 · 2023 年12 月 24 日 10:13

我看另外一个帖子也是1844开头

江湖故人 · 2023 年12 月 24 日 10:18

zhanggame1 · 2023 年12 月 24 日 10:21

排查内存占用没用，一般看看看有没有正在执行得sql长时间跑不完的