Analyze Table 很慢，且报错wait recvLoop: context deadline exceeded

TiDBer_HVujeVgT · 2022 年6 月 28 日 02:47

【 TiDB 使用环境】生产环境 or 测试环境 or POC
【 TiDB 版本】 5.4.1
【遇到的问题】
【复现路径】做过哪些操作出现的问题
【问题现象及影响】

[2022/06/28 10:40:16.649 +08:00] [ERROR] [analyze.go:148] [“analyze failed”] [error=“wait recvLoop: context deadline exceeded”]

【附件】

请提供各个组件的 version 信息，如 cdc/tikv，可通过执行 cdc version/tikv-server --version 获取。

xfworld · 2022 年6 月 28 日 02:50

这个错误前后的信息可以分享出来么？

TiDBer_HVujeVgT · 2022 年6 月 28 日 02:54

[2022/06/28 10:40:16.639 +08:00] [INFO] [coprocessor.go:844] ["[TIME_COP_PROCESS] resp_time:10.721943311s txnStartTS:434211115702943810 region_id:1435368 store_addr:10.74.139.12:20160 kv_process_ms:10718 kv_wait_ms:3 kv_read_ms:20 processed_versions:256 total_versions:257 rocksdb_delete_skipped_count:97 rocksdb_key_skipped_count:1 rocksdb_cache_hit_count:2585 rocksdb_read_count:0 rocksdb_read_byte:0"] [conn=555]
[2022/06/28 10:40:16.649 +08:00] [ERROR] [analyze.go:148] [“analyze failed”] [error=“wait recvLoop: context deadline exceeded”]
[2022/06/28 10:40:16.649 +08:00] [INFO] [analyze.go:130] [“analyze table zabbix.history_uint has failed”] [partition=] [“job info”=“auto analyze columns”] [“start time”=2022/06/28 10:06:23.541 +08:00] [“end time”=2022/06/28 10:40:16.649 +08:00] [cost=33m53.108587436s]
[2022/06/28 10:40:16.652 +08:00] [INFO] [coprocessor.go:844] ["[TIME_COP_PROCESS] resp_time:10.734656783s txnStartTS:434211115702943810 region_id:1435368 store_addr:10.74.139.12:20160 kv_process_ms:10730 kv_wait_ms:3 kv_read_ms:37 processed_versions:512 total_versions:512 rocksdb_delete_skipped_count:339 rocksdb_key_skipped_count:0 rocksdb_cache_hit_count:5041 rocksdb_read_count:0 rocksdb_read_byte:0"] [conn=555]
[2022/06/28 10:40:16.654 +08:00] [INFO] [coprocessor.go:844] ["[TIME_COP_PROCESS] resp_time:670.453138ms txnStartTS:434211110919077968 region_id:809288 store_addr:10.74.137.17:20160 kv_process_ms:661 kv_wait_ms:0 kv_read_ms:569 processed_versions:38754 total_versions:223936 rocksdb_delete_skipped_count:650 rocksdb_key_skipped_count:199139 rocksdb_cache_hit_count:949 rocksdb_read_count:5 rocksdb_read_byte:327197"] [conn=1540849]

TiDBer_HVujeVgT · 2022 年6 月 28 日 03:04

history_uint | | 2022-06-28 11:02:14 | 13543122172 | 15993758471 |

TiDBer_HVujeVgT · 2022 年6 月 28 日 03:05

表很大，这个analyze，慢而且总失败，导致很多更新快的表得不到自动 analyze, 进而查询很慢

TiDBer_HVujeVgT · 2022 年6 月 28 日 03:06

mysql> select tidb_version();
±---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| tidb_version() |
±---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Release Version: v5.4.1
Edition: Community
Git Commit Hash: be484475e76b3aaa2cad520111353c3327db35fa
Git Branch: heads/refs/tags/v5.4.1
UTC Build Time: 2022-05-07 04:31:32
GoVersion: go1.16.4
Race Enabled: false
TiKV Min Version: v3.0.0-60965b006877ca7234adaced7890d7b029ed1306
Check Table Before Drop: false |
±---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)

xuexiaogang · 2022 年6 月 28 日 03:20

表大的话，分析表慢属于正常。但是表大和查询快慢没有直接联系。查询用到索引了吗？

TiDBer_HVujeVgT · 2022 年6 月 28 日 03:23

20分钟之后fail 算正常吗？是不是 TIDB 表大小就有限制了？

TiDBer_HVujeVgT · 2022 年6 月 28 日 03:25

history_uint | | auto analyze index history_uint_1 | 2413218 | 2022-06-28 10:40:16 | 2022-06-28 11:10:17 | failed |

30分钟就失败了，这个是串行的任务吗？不能是并行的吗？这样其他表的analyze不会阻塞在那里？请问这个设计合理吗

TiDBer_HVujeVgT · 2022 年6 月 28 日 03:47

TiDBer_HVujeVgT · 2022 年6 月 28 日 04:30

请问 tidb 是否支持对某些表不analyze的功能，有一个过滤表的功能？

tidb狂热爱好者 · 2022 年6 月 28 日 04:37

不能不analyze 不分析的话 sql 索引都执行的不准。你可以设置分析的允许时间比如上午下午夜里避开高峰期

TiDBer_HVujeVgT · 2022 年6 月 28 日 05:57

history | | auto analyze index history_1 | 0 | 2022-06-28 13:06:03 | 2022-06-28 13:38:44 | failed

40分钟Processed_rows 0 请问这是怎么回事

songxuecheng · 2022 年6 月 28 日 07:04

查看一下 tidb_analyze_version ， tidb_auto_analyze_ratio
表更新很频繁？
手动执行analyze 是否也失败？

xfworld · 2022 年6 月 28 日 07:43

版本为 5.4.1，tidb_analyze_version = 2
5.3 之前的版本， tidb_analyze_version = 1
如果确定 tidb_analyze_version = 2，出现问题，可以选择将 analyze version 降低到 1
analyze table 是有自动更新的配置的，https://docs.pingcap.com/zh/tidb/stable/statistics#自动更新
对于出现问题的情况，最好手动执行
注意观察执行的状态
analyze 也有很多配置参数，可以按照场景的要求，进行调整

主要参考文档：
https://docs.pingcap.com/zh/tidb/v5.4/statistics

h5n1 · 2022 年6 月 28 日 09:22

试试手动analyze,可以调整下面的参数加快速度

luqiuhua · 2022 年6 月 28 日 09:59

如需更快的分析速度，可将 tidb_enable_fast_analyze 设置为 1 来打开快速分析功能。该参数的默认值为 0。

Z六月星星 · 2023 年9 月 12 日 03:08

SET GLOBAL tidb_enable_fast_analyze=1 试下呢