集群内某几台tikv IO过高

为提高效率,提问时请提供以下信息,问题描述清晰可优先响应。

若提问为性能优化、故障排查类问题,请下载脚本运行。终端输出打印结果,请务必全选并复制粘贴上传。

1.集群版本写错了吧?v4.0.9 还没有发布;
2.请问下集群使用的磁盘类型是什么,并麻烦核实下是否存在写入热点问题,可参考下面的方法:

3.数据增长量和实际插入量不符,请问下这个具体是如何判断的?

感谢回复

  1. 不好意思,写错了,是v4.0.8
  2. 1)我们用的ssd, 磁盘的io测试如下
    2)在上周五的时候,由于ip为23的机器io暴涨导致数据难以写入,当时怀疑过是热点问题,便把两张流量较大的表(联合主键,流量占总体写入的60%)重新规划了下,按照SHARD_ROW_ID_BITS重新建立,并添加了64个分片,但从周末的情况看那个节点的io仍然没有降下去
    3)查看了hot write,该节点的Raftstore CPU监控与其他节点并没有太大的差距
    4)coprocessor grafana内一直没有数据;不过集群是新建的,没正式上线,当前读取量不大
    5)用iotop查看了ip为23的节点,其中[raftstore-x]的两个进程写入的io要明显高于其他四个节点

麻烦看下监控面板 TiKV-Details -> Thread CPU 中 Unified read pool CPU 使用情况。

  1. 麻烦在 IO 高的时候, 执行 iotop 看下哪个进程占用的 IO 多。
  2. 使用 [FAQ] Grafana Metrics 页面的导出和导入 方法,导出 over-view, detail-tikv 一段 IO 高的监控信息,多谢。
  1. 一直是tidb的两个写程序占用的很高:bin/tikv-server --addr 0.0.0.0:20161 --advertise-addr 10.247.1~og-file /tidb-deploy/tikv-20161/log/tikv.log [raftstore-20871]
  2. tidb-deploy-sj1-TiKV-Details_2020-11-18T15_30_02.317Z.json (5.7 MB) , 多谢

1.提供的监控信息不完整,大部分页面没有数据,麻烦重新上传下 overview、tikv-detail 和 tikv-throuble-shooting 面板的数据,时间选择 IO 明显冲高的时间段;
2.在监控面板 server report failures 里每个 tikv 都有大量的 “tikv unreachable to” 报错信息,麻烦检查下 tikv 节点或网络是否正常,并且也发现 23 这台网段和其他的 tikv 均不在一个网段内;
3.请问下各个 tikv 节点的机器配置都是一样的吗?

  1. tikv-detail: tidb-deploy-sj1-TiKV-Details_2020-11-19T09_16_02.692Z.json.tar.gz (1.6 MB)
    overview: tidb-deploy-sj1-Overview_2020-11-19T09_20_46.668Z.json (2.5 MB)
    tikv-throuble-shooting: tidb-deploy-sj1-TiKV-Trouble-Shooting_2020-11-19T09_24_05.060Z.json.tar.gz (1.5 MB)

  2. 23这台机器是后来添加的,确实不在同一网段;确认过和其他节点间不存在丢包的情况,机器间传输文件有170M/s的速度

  3. 各机器间配置完全一样

多谢

麻烦再反馈下 23 节点的 disk-performance 的监控数据,我们这边再分析下。

tidb-deploy-sj1-Disk-Performance_2020-11-23T05_16_35.414Z.json (106.1 KB) 过去三天23节点 disk-performance信息,感谢帮助


可以检查一下 store_id 为 110410 的节点,从监控看到别的 store 节点一直报无法连接到 110410 这个节点。这个情况比较异常,可以先解决一下这个。

解决了 是之前下线tiflash节点有信息没彻底删除导致pd里面仍有这个store_id

:+1::+1::+1: