tikv batch put fail

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

  • 【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

您好:

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

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

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

batch put 操作一直失败,如下:

搜到了一些 error 日志,如下:

麻烦帮忙看下可能是什么问题,感谢!

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

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

除了上面这些日志,还搜到一些 fail 日志如下:

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

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

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

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

写入为什么会一直超时呢

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

  1. 写入一直超时是指有问题的 TiKV 写入有超时,还是指前端写入有超时,若有请提供一下相关的日志,监控信息等
  1. 内存 32GB,配置了 block-cache 22GB,然而跑到了 28GB,导致 oom: tikv_mem
  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””

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

你好,已经配置了 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

您好:

  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的时候,业务上是高峰期,或者说你看下时间,是否有什么批量业务。

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

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

你好:

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

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

cluster

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

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

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