tidb server的日志里持续有error

🪐 TiDB 技术问题
1

【 TiDB 使用环境】生产环境 /测试/ Poc
【 TiDB 版本】v3.0.13
【复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】
tidb server 的日志里每隔30s就报如下错误，即使没有任何业务访问也报错，有没有什么办法可以定位一下是什么原因？不知道是什么触发的，目前看对业务没有什么影响
2023/07/31 14:57:18.837 terror.go:357: [error] EOF
github.com/pingcap/errors.AddStack
/home/jenkins/agent/workspace/tidb_v3.0.13/go/pkg/mod/github.com/pingcap/errors@v0.11.4/errors.go:174
github.com/pingcap/errors.Trace
/home/jenkins/agent/workspace/tidb_v3.0.13/go/pkg/mod/github.com/pingcap/errors@v0.11.4/juju_adaptor.go:15
github.com/pingcap/tidb/server.(*packetIO).readOnePacket
/home/jenkins/agent/workspace/tidb_v3.0.13/go/src/github.com/pingcap/tidb/server/packetio.go:80
github.com/pingcap/tidb/server.(*packetIO).readPacket
/home/jenkins/agent/workspace/tidb_v3.0.13/go/src/github.com/pingcap/tidb/server/packetio.go:105
github.com/pingcap/tidb/server.(*clientConn).readPacket
/home/jenkins/agent/workspace/tidb_v3.0.13/go/src/github.com/pingcap/tidb/server/conn.go:265
github.com/pingcap/tidb/server.(*clientConn).readOptionalSSLRequestAndHandshakeResponse
/home/jenkins/agent/workspace/tidb_v3.0.13/go/src/github.com/pingcap/tidb/server/conn.go:471
github.com/pingcap/tidb/server.(*clientConn).handshake
/home/jenkins/agent/workspace/tidb_v3.0.13/go/src/github.com/pingcap/tidb/server/conn.go:172
github.com/pingcap/tidb/server.(*Server).onConn
/home/jenkins/agent/workspace/tidb_v3.0.13/go/src/github.com/pingcap/tidb/server/server.go:345
runtime.goexit
/usr/local/go/src/runtime/asm_amd64.s:1357

【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【附件：截图/日志/监控】

2

这个错误信息是 TiDB Server 的日志信息，其中 EOF 表示读取数据时遇到了文件结束符。这个错误信息通常是由于客户端或代理程序断开连接导致的，而 TiDB Server 在返回数据给客户端时才会发现连接已经断开，因此会打印这个错误信息。这个错误信息本身并不会对业务产生影响，但如果频繁出现，可能会影响 TiDB Server 的性能。

要定位这个问题的原因，可以从以下几个方面入手：

  1. 检查 TiDB Server 的配置文件，确保配置文件中的参数设置正确。例如，可以检查 max-connections 参数是否设置得过小，导致连接数不足。

  2. 检查 TiDB Server 的日志文件，查看是否有其他的错误信息或警告信息。如果有其他的错误信息或警告信息，可能会提供更多的线索。

  3. 检查 TiDB Server 的监控信息，查看是否有异常。可以使用 TiDB Dashboard 或 Grafana 等工具查看 TiDB Server 的监控信息，例如连接数、QPS、CPU 使用率等。

  4. 检查 TiDB Server 的网络环境，查看是否有网络故障或者网络拥塞等问题。可以使用 ping 命令或者其他网络诊断工具检查网络连接是否正常。

如果以上方法都无法解决问题，可以尝试升级 TiDB Server 的版本，或者联系 TiDB 官方技术支持寻求帮助。

3

版本太低了，建议升级新版版本，出现问题时，社区小伙伴没有合适的环境可复现，无法帮你拍出问题~

4

EOF的好像都是网络层面的错误

5

感谢回答,公司具体情况，现在还无法升级。线上环境之前没有报错(线上是从低版本升级上来的)，某天tidb的CPU跑满了，把feedback-probability改成0.00后重启了tidb server就开始报这个错。 测试环境不管参数怎么改都报着错。
max-connections调大也有，show processlist没有任何连接，没有业务，日志只有这个报错，没有其他日志。qps是0，cpu几乎是0。 因为没跑业务，grafana报表也没有什么异常,现在想问一下有没有什么调试手段可以定位到是什么请求导致的这个报错？报错很有规律，每30s报一次，想知道每30s干了点什么。

6

不影响业务，等能升级时弄好

7

看起来是在连接创建时候报错的，是开启了SSL证书？或者是负载均衡探活导致的？

1 个赞
8

一般建议是使用10080的HTTP端口来进行探活，这样是不会在日志里打印报错的

9

tidb前面有负载均衡吗

11

学到了

12

升级应该能解决大部分莫名其妙的报错

13

问题定位到了，是prometheus里的tidb_port_probe 每个30s探测一次，把这行注释了 或 这改成探测 10080就不报错了。
image
tidb3.0可以把4000改成探测10080吗？ 我看tidb6探测的是10080.
奇怪的是都是3.0的集群，都是探测4000，有的就报错，有的就不报错，不知道是哪触发了什么。

2 个赞
14

不会是有防火墙吧

15

没有防火墙，探测4000端口是成功的，只是报这个错

16

这个报错其实就是握手失败而已，其实问题不大。你这几个就是版本太老了，告警规则还不是最优的

17

可以忽略了，或者升级

18

这是我见过的最早的版本了，骨灰真爱粉了吧。
应该派表妹给现场支持升级 :joy:

19

此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。