analyze table消耗很大内存

特雷西-迈克-格雷迪 · 2024 年7 月 11 日 02:10

【 TiDB 使用环境】生产环境
【 TiDB 版本】v6.5.9
【复现路径】tidb自动 analyze table 出现的问题
【遇到的问题：问题现象及影响】

analyze table lxx_pro.t_call_log;
analyze消耗的内存达到4G，表的大小才1.5G。

[2024/07/10 18:05:27.542 +08:00] [WARN] [expensivequery.go:118] [expensive_query] [cost_time=300.291215976s] [conn_id=695449359] [user=root] [database=l_pro] [txn_start_ts=451046441542221825]
[mem_max=“4332905993 Bytes (4.04 GB)”] [sql=“analyze table lxx_pro.t_call_log”]

【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【附件：截图/日志/监控】

呢莫不爱吃鱼 · 2024 年7 月 11 日 05:45

1.检查表数据分布：使用 EXPLAIN 命令查看 ANALYZE TABLE 背后的执行计划，检查数据分布是否均匀。
2.调整并行度：如果并行度设置得过高，尝试降低并行度，以减少内存消耗。
3.检查 TiDB 配置：查看 tidb_analyze_auto_threshold 和 tidb_mem_quota_query 等参数的设置，根据实际情况调整。
4.监控资源使用：在执行 ANALYZE TABLE 时，监控系统的资源使用情况，包括 CPU、内存和磁盘 I/O，以帮助确定瓶颈。

MrSylar · 2024 年7 月 11 日 06:14

一直存在的不那么符合“直观”的“现象”，期待 TiDB 早点解决或能出个明确的预估公式

T02iDBer_7S8XqKfl · 2024 年7 月 11 日 08:34

期待官方给出明确的解决方案。

TIDB-Learner · 2024 年7 月 11 日 10:04

执行analyze命令期间是否有其他高消耗的任务？

yiduoyunQ · 2024 年7 月 11 日 11:27

这个怎么得出的

zhanggame1 · 2024 年7 月 11 日 12:36

分区表吗，另外你看表的key数量了吗

T02iDBer_7S8XqKfl · 2024 年7 月 12 日 03:51

使用 TiDB 的监控工具来跟踪 ANALYZE TABLE 操作期间的资源使用情况，以确定是否有过多的并发操作或配置问题。

vincentLi · 2024 年7 月 12 日 06:32

这个跟表1.5G，但是索引可能会有3，4G道理是不是一样的？

逍遥_猫 · 2024 年7 月 12 日 11:47

3.检查 TiDB 配置：查看 tidb_analyze_auto_threshold 和 tidb_mem_quota_query 等参数的设置，根据实际情况调整。
还有个参数 tidb_mem_quota_analyze=-1 默认，假设此时tidb_mem_quota_query=3G ，那在执行 ANALYZE TABLE 时，内存受tidb_mem_quota_query 控制？
是不是以这2个值中的较小值来判断 ANALYZE 会被终止退出？

tony5413 · 2024 年7 月 15 日 02:16

消耗是挺大的，tidb_mem_quota_query这个限制下试试？

TiDBer_小阿飞 · 2024 年7 月 15 日 02:27

目前 TiDB 中支持两种统计信息：tidb_analyze_version = 1 以及 tidb_analyze_version = 2。在 v5.3.0 及之后的版本中，该变量的默认值为 2。如果从 v5.3.0 之前版本的集群升级至 v5.3.0 及之后的版本，tidb_analyze_version 的默认值不发生变化。

Version 2 的统计信息避免了 Version 1 中因为哈希冲突导致的在较大的数据量中可能产生的较大误差，并保持了大多数场景中的估算精度。
https://docs.pingcap.com/zh/tidb/stable/statistics

T02iDBer_7S8XqKfl · 2024 年7 月 15 日 07:44

目前的版本，应该没有解决。

TiDBer_3Cusx9uk-0775 · 2024 年7 月 16 日 00:54

调整内存限制：在 TiDB 的配置文件中调整 performance.max-memory 选项，限制单个查询可以使用的最大内存量。

濱崎悟空 · 2024 年7 月 17 日 13:37

是挺大的

zhaokede · 2024 年7 月 18 日 00:57

这个大一点的表，都是这样的，不知道新牌本什么情况

xfworld · 2024 年7 月 18 日 01:09

好的策略估计还没出来，
一种是很快，肯定需要大量的资源
一种是可以慢一些，需要的资源可以比较少
一种是平衡，需要的资源会根据实际的情况来做平衡

估计还要等等

dba-kit · 2024 年7 月 18 日 02:52

可以把自动 analyze 的时间限制在闲时，防止 auto analyze 影响业务。同时也可以降低一下可使用的内存大小。和 analyze 性能相关参数有：

+----------------------------------------+-------------------------------+
| Variable_name                          | Value                         |
+----------------------------------------+-------------------------------+
| tidb_analyze_partition_concurrency     | 10                            |
| tidb_analyze_skip_column_types         | json,blob,mediumblob,longblob |
| tidb_auto_analyze_end_time             | 08:00 +0800                   |
| tidb_auto_analyze_partition_batch_size | 1                             |
| tidb_auto_analyze_start_time           | 00:00 +0800                   |
| tidb_max_auto_analyze_time             | 0                             |
| tidb_mem_quota_analyze                 | -1                            |
+----------------------------------------+-------------------------------+

TiDBer_iLonNMYE · 2024 年7 月 18 日 09:36

不能抽样分析吗？sample_size

hawkingrei · 2024 年7 月 18 日 16:22

6.5 系列里如果配置不合理，可能存在 analyze 内存高的风险，另外表的自身特性也会影响analyze的内存使用，特别是大宽表，分区表。这方面上，在v7.5及之上版本，对这方面做了优化，可以尝试使用。另外 tidb_enable_historical_stats 有可能导致 OOM，这个在最新版本里已经默认关闭，可以考虑直接关闭。

1、给出一下表结构
2、看一下是否改变了 analyze 的默认配置值