tikv batch put fail

[Hacker_7yuXN6RZ]

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

• 【TiDB 版本】：v3.0.7 【问题描述】：

部署结构：目前还在测试接入，部署了 3 node，每台上一个 pd、一个 tikv 使用 tikv 的 go client，发现 batch put 操作的时候经常连不上 tikv server，请问可能是什么原因？pd 和 tikv 都存活 time=“2020-03-21T13:26:37Z” level=info msg="drop regions that on the store 1(xxx) due to send request fail, err: rpc error: code = Unavailable desc = all SubConns are in TransientFailure, latest connection error: connection error: desc = "transport: Error while dialing dial tcp xxx connect: connection refused

[yilong (yi888long)]

您好：

   1. 请确认这个tikv进程是否正常  ps -ef | grep tikv 看下进程是否存活
   2. 看一下tikv.log日志，在那个时候是否正常,如果有异常日志，请上传信息。
   3. 如果是连接一段时间出问题，检查是否在客户端和tikv之间存在防火墙

[Hacker_7yuXN6RZ]

您好！感谢回复~
确认了下，1 和 3 都没问题。

目前我们的情况是读操作正常，但有时候也会出错，如下：

batch put 操作一直失败，如下：

搜到了一些 error 日志，如下：

麻烦帮忙看下可能是什么问题，感谢！

[yilong (yi888long)]

os code 13是说明这个用户没有权限操作这个目录。你可以检查下，是不是有多个用户尝试连接tikv，但是有的用户没有权限。

[Hacker_7yuXN6RZ]

对，我们是在 k8s 有 3 个实例在连接 tikv，配置是一样的，服务启动的时候显示连接 tikv 集群是成功的，如下：

除了上面这些日志，还搜到一些 fail 日志如下：

[yilong (yi888long)]

connection refused 可能是由于重启导致。 麻烦grep Welcome tikv.log，找出一段启动到异常结束的tikv日志信息 ,打包上传下。 同时这段时间的pd日志，也请上传下，多谢。

[Hacker_7yuXN6RZ]

搜了下，三台 Tikv 中确实有一台在不断重启，大约一个小时一次，其他两台正常。看系统日志，应该是 oom 了，这台机器磁盘大一点，所以负载更高吧。但在它正常期间为什么完全写不进数据呢 一次完整日志见： 链接: https://pan.baidu.com/s/1A5X54J8XnSdQ6ns96Jx7aQ 提取码: p23i

[飞与非-PingCAP (飞与非)]

请确认一下是否 OOM，可以通过 demsg 命令可以看到

[Hacker_7yuXN6RZ]

你好，有一台 tikv 确实 oom 了，就是磁盘更大的那台，上面 region 更多。问题是我配置了 block-cache，似乎没有生效。

写入为什么会一直超时呢

[飞与非-PingCAP (飞与非)]

1.判断 block-cache 配置没有生效的方法是？另外你的机器的内存大小是？

2. 写入一直超时是指有问题的 TiKV 写入有超时，还是指前端写入有超时，若有请提供一下相关的日志，监控信息等

[Hacker_7yuXN6RZ]

1. 内存 32GB，配置了 block-cache 22GB，然而跑到了 28GB，导致 oom:
   
   
   
2. 写入超时指的是我们用 tikv go client，执行 batch put 操作，一直报错，报错的节点就是经常 oom 的节点 ：

time=“2020-03-23T07:39:24Z” level=info msg=“drop regions that on the store 1(xxx:20160) due to send request fail, err: rpc error: code = DeadlineExceeded desc = context deadline exceeded”

time=“2020-03-23T10:12:19Z” level=info msg=“drop regions that on the store 1(xxx:20160) due to send request fail, err: rpc error: code = Unavailable desc = all SubConns are in TransientFailure, latest connection error: connection error: desc = "transport: Error while dialing dial tcp xxx:20160: i/o timeout"”

[飞与非-PingCAP (飞与非)]

1. 建议将 block-cache 调整成16GB及以下，原因：占用内存的地方有多个，block-cache 只是其中之一，当前版本没有全局的内存管理功能，导致配置内存管理并不是很精确
2. 请问超时的时间跟 OOM 的时间是否一致，请先确认一下是否是由于 OOM 导致的报错

[Hacker_7yuXN6RZ]

你好，已经配置了 block-cache 16G，该节点 tikv01 还是一个小时 oom 一次。写入是一直超时的，即便整个集群刚重启的时候。请问这是否和配置不平衡有关呢？最开始的时候，tikv01 节点磁盘是更大的，上面的 region 数比其他两个更多，目前写入报错的都是 tikv01 相关的，比如： INFO[0022] drop regions that on the store 1(xxx:20160) due to send request fail, err: rpc error: code = DeadlineExceeded desc = context deadline exceeded

[yilong (yi888long)]

您好：

  1.   麻烦上传一份OOM时前后一小时的监控信息，多谢。 
    (1)、chrome 安装这个插件https://chrome.google.com/webstore/detail/full-page-screen-capture/fdpohaocaechififmbbbbbknoalclacl

(2)、鼠标焦点置于 Dashboard 上，按 ?可显示所有快捷键，先按 d 再按 E 可将所有 Rows 的 Panels 打开，需等待一段时间待页面加载完成。 (3)、使用这个 full-page-screen-capture 插件进行截屏保存

 2. OOM的时候，业务上是高峰期，或者说你看下时间，是否有什么批量业务。

[Hacker_7yuXN6RZ]

另外我们查看网络状态，发现 kv 和 pd 2380 端口之间连接不少 TIME_WAIT，是我们内部网络问题吗:

[Hacker_7yuXN6RZ]

好，这是近六个小时截图。出问题后，我们读都停止了，写还在请求，但是在不断超时：

[yilong (yi888long)]

你好：

    1. 从问题看应该是在133.6对吧
    2. 从region数量看133.6比其他两个要多很多，leader数量也多很多，导致不均衡，大量的操作都在133.6上
    3. 使用pd-ctl 参考官方文档章节，反馈下 store, cluster, config show all , member信息，多谢

https://pingcap.com/docs-cn/stable/

[Hacker_7yuXN6RZ]

好的，稍后提供。目前确认 133.6 节点不断 oom 和一直写请求超时有关，停止后内存就平缓了

[Hacker_7yuXN6RZ]

[yilong (yi888long)]

1. 可以看到相同的磁盘，但是store1 就是133.6，regioni总数和leader都很多，但是我看日志里有transfer的日志，麻烦把您这边有的监控都上传下， PD，OVERVIEW这些，多谢

2. 好的，稍后提供。目前确认 133.6 节点不断 oom 和一直写请求超时有关，停止后内存就平缓了 -----这个是把写入操作停止了吗？

3. 能否在观察下，写入操作停止后， 这3个节点开始balance了吗？