记一次ZABBIX监控JMX故障

最新推荐文章于 2024-04-05 15:57:38 发布

Linux????? Mr.Liyz

最新推荐文章于 2024-04-05 15:57:38 发布

阅读量275

点赞数

文章标签：运维网络 java

原文链接：https://segmentfault.com/a/1190000015675000

版权

最近偶然发现线上其中一个服务的zabbix图形没有出来，点开发现报了一个错：

java.rmi.ConnectIOException: error during JRMP connection establishment; nested exception is: 
java.net.SocketException: Connection reset

初步怀疑是端口占用，然后看了端口，发现端口并没有被占用。重启了一下，图形依然没有出来。

接着看了下系统上的一些限制，没有超过限制，因为之前已经调整过了。

netstat看了下端口，全是TIME_WAIT，问题就应该出在这里了。

调整内核参数

/etc/sysctl.conf 

# tcp连接保持时间为1800秒
net.ipv4.tcp_keepalive_time = 1800
# 回收TIME_WAIT占用的连接
net.ipv4.tcp_tw_recycle = 1

sysctl -p

本来我以为这样就解决了，然而，几行文字出现在我的眼前

启用TIME-WAIT状态sockets的快速回收，这个选项不推荐启用。在NAT(Network Address Translation)网络下，会导致大量的TCP连接建立错误。如果没有技术大神的指点的话，千万不要去改动他。

最合适的解决方案是增加更多的四元组数目，比如，服务器可用端口，或服务器IP，让服务器能容纳足够多的TIME-WAIT状态连接。

在服务端，不要启用net.ipv4.tcp_tw_recycle，除非你能确保你的服务器网络环境不是NAT。在服务端上启用net.ipv4.tw_reuse对于连接进来的TCP连接来说，并没有任何卵用.

在客户端（尤其是服务器上，某服务以客户端形式运行时，比如上面提到的nginx反代，连接着redis、mysql的FPM等等）上启用net.ipv4.tcp_tw_reuse，还算稍微安全的解决TIME-WAIT的方案。再开启net.ipv4.tcp_tw_recycle的话，对客户端（或以客户端形式）的回收，也没有什么卵用，反而会发生很多诡异的事情（尤其是FPM这种服务器上，相对nginx是服务端，相对redis是客户端）。