tidb集群 压力过大,导致业务无响应

为提高效率,请提供以下信息,问题描述清晰能够更快得到解决:
【 TiDB 使用环境】v5.0.3

【背景】 每天定时出现集群压力过大

【现象】

【问题】 集群压力过大,导致应用连接超时

【业务影响】 业务无法正常使用

【TiDB 版本】 v5.0.3

【应用软件及版本】

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

监控

1赞

你给的监控图看不清楚,麻烦安装这个帖子的方式,导出一下监控:[FAQ] Grafana Metrics 页面的导出和导入

不过按照 你 tikv 的CPU 监控,怀疑你慢日志/热点导致的此问题,建议你按照 慢日志的方向来看一下

当时集中并发在收集大量历史表的统计信息

慢查询里面大量的这种 sql 各个字段采样统计应该是
– Metabase SELECT tbl_new_ssp_ad_log_20210529.planId AS planId FROM tbl_new_ssp_ad_log_20210529 GROUP BY tbl_new_ssp_ad_log_20210529.planId ORDER BY tbl_new_ssp_ad_log_20210529.planId ASC LIMIT 5000;

我们的需求是能不能有一个收集统计信息表的例外表,我们可以指定例外掉哪些历史表 不再自动收集统计信息
另外能不能设置收集时间凌晨1点开始 ,收集的并发度调低 ,中间加一下间隔时间什么的。
我记得5.0.1 的时候不是有 某个表更新多少比例的数据 才会触发analzye吗? ,现在是大量的样本统计 把系统搞崩溃了 。 导致当时简单的insert 语句都需要30多s 才能执行完
可以加我微信 直接沟通吗? heming_0120 希望能快速修避免影响明天清晨2个多小时 慢查询 。
或者你们可以指定某个库的统计信息不收集也行 ,我把历史表都集中扔到一个库里 避免统计信息收集

页面把图片压缩了,可以下载图片,这样就清晰了。 还需要哪个监控图?

可以看一下:tidb_enable_fast_analyze、 tidb_auto_analyze_end_timetidb_auto_analyze_ratiotidb_auto_analyze_start_timetidb_build_stats_concurrency。这几个参数 @heming

select @@tidb_enable_fast_analyze @@tidb_auto_analyze_ratio @@tidb_auto_analyze_start_time @@tidb_auto_analyze_end_time @@tidb_build_stats_concurrency

0 0.5 00:00 +0000 23:59 +0000 4

tidb_enable_fast_analyze 这个要设置为 1 吗? tidb_build_stats_concurrency 这个设置为 2 或者 1 ?

如果要关闭 Analyze ,请参考这里 https://docs.pingcap.com/zh/tidb/stable/statistics#自动更新

1、收集统计信息,可以关闭,然后手工进行收集(可以写个定时任务)关闭收集统计信息的参数: run-auto-analyze https://docs.pingcap.com/zh/tidb/stable/tidb-configuration-file#run-auto-analyze
2、上面提到的几个参数:分别可以控制 analyze 任务的运行时间,及触发条件,而tidb_enable_fast_analyze 则是收集统计信息的方式(这里牵扯 tidb 收集统计信息 和mysql 的兼容性),而tidb_build_stats_concurrency 等几个参数,则是控制收集任务的并发度之类(具体没有参考值,每个集群的数据量,业务形态不一样,没发给你明确的数值建议)https://docs.pingcap.com/zh/tidb/stable/statistics#查看-analyze-状态

image
这种SQL 是在做什么

这是业务 SQL 吧

这是dashoboard 慢查询 看到的,业务并没有这种SQL。在压力大的时候,大量这种SQL去查 历史数据

建议你看看 tidb_slow.log看看关于这个语句的信息(或者发我一下)

建议你根据 connect id。username 来判断业务线是谁,确认一下这个 SQL是不是业务 SQL(这个不是 数据库内部执行 的 SQL)

好的,谢谢。 之前看有metabase,以为是统计信息的SQL

好的:grinning::grinning:,建议咱们1、看看慢日志 2、根据 dashboard 的 kv 功能,找到对应 读写较为高的表,查看表结构,是否能打散(热点的处理方式)(因为看咱们的 kv 截图,是有规律行的 几张特点的几个表,读写流量较高)

现在是range 按月 分区表的形式,还能有别的方式打散吗