手动analyze时会导致tidb down掉

为提高效率,请提供以下信息,问题描述清晰能够更快得到解决:
【TiDB 版本】
tidb v5.1.0 tidb配置8C16G

【概述】 场景 + 问题概述
每次手动analyze大表后会导致tidb down掉,表数据量50亿rows左右

【背景】 做过哪些操作
删除旧索引后,发现执行计划没有选择最优索引,所以尝试手动analyze

【现象】 业务和数据库现象
tidb down掉

【附件】 相关日志及配置信息
tidb.log

[2021/12/13 16:49:03.670 +08:00] [WARN] [grpclogger.go:85] [“grpc: Server.Serve failed to create ServerTransport: connection error: desc = “transport: http2Server.HandleStreams failed to receive the preface from client: EOF””] [system=grpc] [grpc_log=true]
[2021/12/13 16:49:03.970 +08:00] [WARN] [memory_usage_alarm.go:139] [“tidb-server has the risk of OOM. Running SQLs and heap profile will be recorded in record path”] [“is server-memory-quota set”=false] [“system memory total”=17179869184] [“system memory usage”=14578753536] [“tidb-server memory usage”=9328578696] [memory-usage-alarm-ratio=0.8] [“record path”="/export/temp/0_tidb/MC4wLjAuMDo0MDAwLzAuMC4wLjA6MTAwODA=/tmp-storage/record"]
[2021/12/13 16:49:04.563 +08:00] [WARN] [pd.go:131] [“get timestamp too slow”] [“cost time”=46.510589ms]
[2021/12/13 16:49:04.564 +08:00] [WARN] [pd.go:131] [“get timestamp too slow”] [“cost time”=33.113369ms]
[2021/12/13 16:49:04.564 +08:00] [WARN] [pd.go:131] [“get timestamp too slow”] [“cost time”=32.193579ms]
[2021/12/13 16:49:04.565 +08:00] [WARN] [pd.go:131] [“get timestamp too slow”] [“cost time”=31.223144ms]
[2021/12/13 16:49:04.597 +08:00] [WARN] [pd.go:131] [“get timestamp too slow”] [“cost time”=43.983743ms]
[2021/12/13 16:49:04.895 +08:00] [WARN] [pd.go:131] [“get timestamp too slow”] [“cost time”=60.1678ms]
[2021/12/13 16:49:05.097 +08:00] [WARN] [pd.go:131] [“get timestamp too slow”] [“cost time”=62.183869ms]
[2021/12/13 16:49:05.099 +08:00] [WARN] [pd.go:131] [“get timestamp too slow”] [“cost time”=44.85017ms]
[2021/12/13 16:49:05.177 +08:00] [WARN] [pd.go:131] [“get timestamp too slow”] [“cost time”=35.951316ms]
[2021/12/13 16:49:05.179 +08:00] [WARN] [pd.go:131] [“get timestamp too slow”] [“cost time”=31.821064ms]
[2021/12/13 16:49:05.180 +08:00] [WARN] [pd.go:131] [“get timestamp too slow”] [“cost time”=32.478411ms]

goroutine2021-12-13T16_49_03 08_00 (1.2 MB) heap2021-12-13T16_49_03 08_00 (1.1 MB) running_sql2021-12-13T16_49_03 08_00 (494 字节)

1 个赞

tidb_analyze_version 查询一下这个参数

±---------------------±------+
| Variable_name | Value |
±---------------------±------+
| tidb_analyze_version | 2 |
±---------------------±------+

tidb_analyze_version = 2 时,如果执行 ANALYZE 语句后发生 OOM,请设置全局变量 tidb_analyze_version = 1 ,然后进行以下操作之一:

  • 如果 ANALYZE 语句是手动执行的,请手动 analyze 每张需要的表:

select distinct(concat(‘ANALYZE ‘,table_schema, ‘.’, table_name,’;’)) from information_schema.tables, mysql.stats_histograms where stats_ver = 2 and table_id = tidb_table_id ;


* 如果 ANALYZE 语句是开启了自动 analyze 后 TiDB 自动执行的,请使用以下 SQL 语句生成 DROP STATS 的语句并执行:

select distinct(concat(‘DROP STATS ‘,table_schema, ‘.’, table_name,’;’

https://docs.pingcap.com/zh/tidb/v5.1/statistics 参考这里

手动analyze只能是同步的吗?执行完语句后就一直hang在那里了,show analyze status也看不到进程。

show admin ddl 看下

show admin ddl看不到的,show analyze status有的时候能看到,但主要是现在执行analyze语句的客户端不能退出,否则analyze就会失败,analyze不能手动异步化提交吗?

现在是什么问题?

手动analyze不能异步化提交命令吗?如果analyze耗时较长,客户端只能阻塞等待?

这个不能异步,你要异步的话可以使用mysql -h -u -p -e "analyze table xxx"这种。
show analyze status只能看对应tidb节点上的analyze,看不到别的tidb节点。

1 个赞

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