tikv的日志大量["kv rpc failed"] [err=RemoteStopped]的原因？

🪐 TiDB 技术问题
1

【 TiDB 使用环境】生产环境
【 TiDB 版本】v5.3
tikv的日志大量tikv的日志大量[“kv rpc failed”] [err=RemoteStopped]

[2023/12/01 15:59:48.895 +08:00] [INFO] [kv.rs:1023] [“kv rpc failed”] [err=RemoteStopped] [request=batch_commands]
[2023/12/01 15:59:48.895 +08:00] [INFO] [kv.rs:1023] [“kv rpc failed”] [err=RemoteStopped] [request=batch_commands]
[2023/12/01 15:59:48.895 +08:00] [INFO] [kv.rs:1023] [“kv rpc failed”] [err=RemoteStopped] [request=batch_commands]
[2023/12/01 15:59:48.954 +08:00] [INFO] [kv.rs:1023] [“kv rpc failed”] [err=RemoteStopped] [request=batch_commands]
[2023/12/01 15:59:48.954 +08:00] [INFO] [kv.rs:1023] [“kv rpc failed”] [err=RemoteStopped] [request=batch_commands]
[2023/12/01 15:59:48.954 +08:00] [INFO] [kv.rs:1023] [“kv rpc failed”] [err=RemoteStopped] [request=batch_commands]
[2023/12/01 15:59:48.954 +08:00] [INFO] [kv.rs:1023] [“kv rpc failed”] [err=RemoteStopped] [request=batch_commands]
[2023/12/01 15:59:49.023 +08:00] [INFO] [kv.rs:1023] [“kv rpc failed”] [err=RemoteStopped] [request=batch_commands]
[2023/12/01 15:59:49.023 +08:00] [INFO] [kv.rs:1023] [“kv rpc failed”] [err=RemoteStopped] [request=batch_commands]

请问这是什么原因？

2

[INFO] 级别的不用管

3

但是一直报这个，每秒很多次，为什么一直报这个？能不能不让它报

4
  1. 版本能够清晰点么?
  2. tikv 所有的节点都如此？
  3. 目前集群什么配置？ 状态如何？
  4. 影响目前使用的问题是什么？
5

1、Version:v5.3.0
2、所有tikv都是这样，单日多达10个文件，单个文件有2660418条这个日志

image
image723×474 14.2 KB

3、集群配置如下图
image
内存256 + 2块nvme盘
image
image912×264 9.79 KB

4、不知道有没有影响，就是想知道日志量为什么这么大？有没有隐藏风险？
5、当前主要用于juiceFS保存元数据，业务相对简单，region数：213955，tikv的总qps在100万左右
6、pd的从节点和tikv混部，pd主节点单独部署,128核Cpu，当前pd主节点的cpu使用率50%左右，7个pd是不是有点多？

6

  1. PD 和 tikv 节点能不混合部署，就不要混合

  2. PD 的副本数和高可用，可以参考 ETCD 的容错能力（按照你想要的场景自行处理）

    image
    image1080×823 37.4 KB

  3. 查下 region 的副本数在所有的 kv 节点上是否平均

  4. region 的副本数是否达到了 设定的量（一般是三副本）

  5. 有风险的，这个错误是描述了 kv rpc 请求失败了… （请确定所有的节点之间的网络通讯是否正常）

  6. 集群的网络带宽是否达到了 W 兆…

    image
    image800×369 16.6 KB

  7. 是突然发生这个状况的么？ 之前有没有什么操作…

7

1、从pd-master的主节点上看网络流量，和其它pd节点之间的网络流量就比较高了，我理解pd节点越多那么资源消耗越高，是不是对主节点的cpu资源也会有很大的消耗？现在cpu 50%，如果降低两个节点的话，是不是可以降低一些？业内大多数公司一般是配置多少个pd节点？还有一个问题就是，我们目前213955个region在128核心的pd-master就用了50%的cpu，随着region数据量越来越多，是不是这个主机的配置风险就会越来越高？我们应该怎么来优化处理？

image
image1051×283 10.6 KB

2、这个“kv rpc failed”应该持续很长时间了，网卡Speed: 25000Mb/s，我看各节点间的网络是通的，这个期间我们也就是做了一个扩缩容的操作
3、region数量相对不是很平均，为了减少back off，我们的pd调度是在qps不是很高的情况下才开启
4、请问怎么查看region 的副本数是否达到了 设定的量？

8

是否远程机器有连接数限制

9
  1. region 的数量越多，会占用更多的资源
    • cpu 资源
    • 内存资源
    • 网络资源
      需要维持region 的心跳处理
  2. region 海量的处理是有参考文档的 (https://docs.pingcap.com/zh/tidb/stable/massive-regions-best-practices)
  3. 优先考虑查阅 region 的目前状态，来判断现在的副本信息，通过grafana 就可以了，查阅以下的参数
  4. region不平均会带来读写倾斜，有的kv 节点就特别忙，有的就十分空闲…
  5. 甚至会出现 大量的热点问题，这个通过pd 的dashboard 的界面可以查阅到了

优先检查 region，尽量做一些合并，减少 empty region 和 region 的数量… 这样可利用的资源会变多，效率也会变高

请参考！

10

这个从哪里设置？

11

查看下集群状态，有没有节点故障的情况

12

检查了没有

13

1、请问213955个region算海量regoin吗？总数据量才不到14T，pd-master就用满了64C的cpu，这个合理吗？
2、所有region状态是ok的，也没有明显的热点读写
3、所有tikv的日志大量输出“kv rpc failed”的原因还是没有找到

14
  1. region 的数量 和 PD 没有直接的关系，但是 region 的心跳信息会传递到 PD，需要 PD 做全局的控制和维护
  2. PD 64C 用满了，是持续用满，还是峰值用满？请按照 Client 接入使用的情况进行判断（最好将监控图一并放出）
  3. kv rpc failed， 请结合 PD 的日志进行查询，是否有其他的异常

根据提供的信息，也只能尝试帮你做一些判断和处理，请理解… :rofl:

15

  1. 21万的region数量不算多，你确认是pd进程占了64个CPU吗？.看着不太正常，可以看看pd监控的cpu

  2. 如果pd leader cpu高是属于正常消耗。5.3 版本有个 tidb_enable_tso_follower_proxy 可以设置pd follower来转发请求，以减少pd leader CPU，到可能导致延迟又增加

  3. 我看别人juicefs很多都用裸kv, 但看你的还有个tidb节点，是用的事务模式吗？tikv qps用哪个指标衡量的，看你用着指标描述貌似又是用的裸kv

  4. 5.3.0属于比较基础的版本建议升到 比较新的5.3.4

16

1、image
我们的读写访问量比较大，这个cpu的使用量，我也不知道是否正常？
2、这个参数目前来说可以不用调整，主机的配置还够
3、只用了一个tidb主要用于GC，实际读写都是raw kv
4、升级到5.3.4有坑吗？

17

1、cpu使用率在峰值有达到64c，一般保持在50c左右
image

3、pd存在大量read: connection reset by peer

image
image1377×222 8.07 KB

18

节点之间互相网络访问正常不，有没有检查过不同角色的节点版本是否一致，业务访问上有没有出现异常状况

19

节点间访问是正常的，用tiup安装的版本应该都是一致的吧?业务没有明显的异常

20

我感觉是误报，日志级别是 info 的。
反馈区让研发看看吧，有影响 info 级别也不应该的。没影响打很多感觉也是有问题的。

1 个赞