P0 故障 --- 生产tidb 4.0.12 突然非常慢 然后 发现pd 和tikv 一直断自动重启 集群用不了

为提高效率,请提供以下信息,问题描述清晰能够更快得到解决:
【 TiDB 使用环境】
【概述】生产tidb 4.0.12 突然非常慢 然后 发现pd 和tikv 一直断自动重启 集群用不了
【现象】生产tidb 4.0.12 突然非常慢 然后 发现pd 和tikv 一直断自动重启 集群用不了
【业务影响】 生产用不了 P0 级别
【TiDB 版本】4.0.12
【附件】

  1. TiUP Cluster Display 信息
[tidb@bydata1 ~]$ ~/.tiup/bin/tiup cluster display baiyao-v4
Starting component `cluster`: /home/tidb/.tiup/components/cluster/v1.5.5/tiup-cluster display baiyao-v4
Cluster type:       tidb
Cluster name:       baiyao-v4
Cluster version:    v4.0.12
Deploy user:        tidb
SSH type:           builtin
ID                Role          Host         Ports                            OS/Arch       Status  Data Dir                           Deploy Dir
--                ----          ----         -----                            -------       ------  --------                           ----------
10.1.209.13:9095  alertmanager  10.1.209.13  9095/9096                        linux/x86_64  Up      /data/tidb-data/alertmanager-9095  /data/tidb-deploy/alertmanager-9095
10.1.209.13:3030  grafana       10.1.209.13  3030                             linux/x86_64  Down    -                                  /data/tidb-deploy/grafana-3030
10.1.209.11:9379  pd            10.1.209.11  9379/9380                        linux/x86_64  Down    /data/tidb-data/pd-9379            /data/tidb-deploy/pd-9379
10.1.209.12:9379  pd            10.1.209.12  9379/9380                        linux/x86_64  Down    /data/tidb-data/pd-9379            /data/tidb-deploy/pd-9379
10.1.209.13:9379  pd            10.1.209.13  9379/9380                        linux/x86_64  Down    /data/tidb-data/pd-9379            /data/tidb-deploy/pd-9379
10.1.209.13:9080  prometheus    10.1.209.13  9080                             linux/x86_64  Up      /data/tidb-data/prometheus-9080    /data/tidb-deploy/prometheus-9080
10.1.209.11:9383  tidb          10.1.209.11  9383/9384                        linux/x86_64  Up      -                                  /data/tidb-deploy/tidb-9383
10.1.209.12:9383  tidb          10.1.209.12  9383/9384                        linux/x86_64  Up      -                                  /data/tidb-deploy/tidb-9383
10.1.209.13:9383  tidb          10.1.209.13  9383/9384                        linux/x86_64  Up      -                                  /data/tidb-deploy/tidb-9383
10.1.209.11:8000  tiflash       10.1.209.11  8000/7123/2930/20270/20192/7234  linux/x86_64  N/A     /data/tidb-data/tiflash-8000       /data/tidb-deploy/tiflash-8000
10.1.209.12:8000  tiflash       10.1.209.12  8000/7123/2930/20270/20192/7234  linux/x86_64  N/A     /data/tidb-data/tiflash-8000       /data/tidb-deploy/tiflash-8000
10.1.209.13:8000  tiflash       10.1.209.13  8000/7123/2930/20270/20192/7234  linux/x86_64  N/A     /data/tidb-data/tiflash-8000       /data/tidb-deploy/tiflash-8000
10.1.209.11:9385  tikv          10.1.209.11  9385/9386                        linux/x86_64  N/A     /data/tidb-data/tikv-9385          /data/tidb-deploy/tikv-9385
10.1.209.12:9385  tikv          10.1.209.12  9385/9386                        linux/x86_64  N/A     /data/tidb-data/tikv-9385          /data/tidb-deploy/tikv-9385
10.1.209.13:9385  tikv          10.1.209.13  9385/9386                        linux/x86_64  N/A     /data/tidb-data/tikv-9385          /data/tidb-deploy/tikv-9385
Total nodes: 15

  1. TiUP Cluster Edit Config 信息

  2. TiDB- Overview 监控

2 个赞

pd 日志

pd.log.tar.gz (6.4 MB)

2 个赞

麻烦发一下机器配置以及监控

  1. 机器配置 TiKV、PD
  2. 监控信息,参考 metrictools做一下监控导出
2 个赞

机器配置正在导出, dashboard 挂了 我们需要手工导

然后我们其中集群一台bydata2 iotop 非常高

2 个赞

grafana 也挂了嘛 ?可以导出一下 grafana 监控

1 个赞

Hi~ 生产环境不建议混合部署,尤其是 TiDB 、TiKV、TiFlash 混布,如果有大的 query 要做聚合查询,这个容易把机器资源打满。

1 个赞

tiflash 没有表用

1 个赞

找一下低效的 SQL 吧,看起来是高成本的查询导致的

1 个赞

现在只是PD server 就把其中一台磁盘io 打满了, 生产已经运行3个多月了

1 个赞

问题是 现在启动不了 也不没地方去看慢sql

1 个赞

是不是 PD leader ,然后出现大量报错。发一下 log 吧

2 个赞

pd 日志 前面贴子已经发了

[2021/08/24 14:26:00.520 +08:00] [INFO] [trace.go:145] ["trace[813541521] range"] [detail="{range_begin:/pd/6949765272974193820/config; range_end:; response_count:1; response_revision:7953856; }"] [duration=1.080507047s] [start=2021/08/24 14:25:59.439 +08:00] [end=2021/
08/24 14:26:00.520 +08:00] [steps="[\"trace[813541521] 'range keys from in-memory index tree'  (duration: 1.079725106s)\"]"]
[2021/08/24 14:26:00.520 +08:00] [WARN] [etcdutil.go:112] ["kv gets too slow"] [request-key=/pd/6949765272974193820/config] [cost=1.081112745s] []
[2021/08/24 14:26:02.480 +08:00] [INFO] [trace.go:145] ["trace[1785218849] put"] [detail="{key:/tidb/server/minstartts/9d7d0fc8-d0e5-440c-8d14-aa4eec89b6a1; req_size:92; response_revision:7953859; }"] [duration=426.594762ms] [start=2021/08/24 14:26:02.053 +08:00] [end=2
021/08/24 14:26:02.480 +08:00] [steps="[\"trace[1785218849] 'process raft request'  (duration: 426.552482ms)\"]"]
[2021/08/24 14:26:05.400 +08:00] [INFO] [trace.go:145] ["trace[901465958] put"] [detail="{key:/tidb/server/minstartts/a1141859-45d7-4503-9c6f-617039973aeb; req_size:92; response_revision:7953862; }"] [duration=803.969797ms] [start=2021/08/24 14:26:04.596 +08:00] [end=20
21/08/24 14:26:05.400 +08:00] [steps="[\"trace[901465958] 'process raft request'  (duration: 803.834184ms)\"]"]
[2021/08/24 14:26:05.821 +08:00] [WARN] [util.go:144] ["apply request took too long"] [took=382.13993ms] [expected-duration=100ms] [prefix="read-only range "] [request="key:\"/pd/6949765272974193820/config\" "] [response="range_response_count:1 size:3143"] []
[2021/08/24 14:26:05.821 +08:00] [INFO] [trace.go:145] ["trace[1441365093] range"] [detail="{range_begin:/pd/6949765272974193820/config; range_end:; response_count:1; response_revision:7953863; }"] [duration=382.215349ms] [start=2021/08/24 14:26:05.439 +08:00] [end=2021
/08/24 14:26:05.821 +08:00] [steps="[\"trace[1441365093] 'range keys from in-memory index tree'  (duration: 381.34295ms)\"]"]
[2021/08/24 14:26:07.183 +08:00] [WARN] [util.go:144] ["apply request took too long"] [took=135.225096ms] [expected-duration=100ms] [prefix=] [request="header:<ID:17829042162284369098 > put:<key:\"/topology/tidb/10.1.209.12:9383/ttl\" value_size:19 lease:860567012542919
7423 >"] [response=size:7] []
[2021/08/24 14:26:07.674 +08:00] [WARN] [util.go:144] ["apply request took too long"] [took=235.028251ms] [expected-duration=100ms] [prefix="read-only range "] [request="key:\"/pd/6949765272974193820/config\" "] [response="range_response_count:1 size:3143"] []

磁盘 I/O 打满了,所有的节点落盘都在同一块盘上面,这个也不合理。需要进一步看一下监控,导致的原因。现阶段可以试试重启集群,是否可以缓解问题。

现在重启已经试了很多次 就是启动不了 启动起来 不到一分钟就pd 和tikv 全部down了

看一下 slow query log ,是不是有异常的查询。

现在都启动不起来 没法看slow query log, 我们新加一块盘 来单独放pd 的是否可以更快, 同时是否可以关闭一些pd的日志写入操作, 来节约磁盘io, 现在是pd 自己就能到磁盘io 的99%, 这个很难理解, 你说tikv 和tidb io 高我还能理解, pd 只是协调器 咋个IO那么高

可以吧 PD 、TiKV、TiDB 单独独立出来,不要互相影响 ~

刷了大量日志,导致 I/O 被打高了

好 我们先试试 非常感谢