close connection error java.sql.SQLRecoverableException: IO Error: Broken pipe

java.sql.SQLRecoverableException: IO Error: Broken pipe

Table of Contents

• 1. 错误信息
• 2. 分析
  • 2.1. 连接池
  • 2.2. TCP网络
  • 2.3. 数据库监听

1 错误信息

ERROR [com.alibaba.druid.util.JdbcUtils] - close connection error
java.sql.SQLRecoverableException: IO Error: Broken pipe

2 分析

遇到这个问题，一般是程序访问服务（比如数据库）时遇到的。这之间存在着好几个网络 通信节点:

程序 –> 连接池 –> 网卡 –> 防火墙 –> 路由器 –> 防火墙 —> 服务端网卡 —> 服务端静态路由 –> 服务端防火墙 –> 服务监听 –> 服务

除了程序与连接池(一般集成在一起)，其他任何一个节点中断连接，都有可能引发这个问 题,尤其是防火墙。而一般将某个连接中断原因，是因为这个连接空闲了太长的时间(保持 连接却不做任何事情)。网络防火墙、tcp网络、服务器本地防火墙、监听这几个节点上都 有空闲连接控制。

下面分别通过配置连接池、服务器上的tcp网络、数据库层面、来解决空闲连接被异常中 断的问题。

2.1 连接池

现在国内大都使用druid 作为程序的连接池。那么该连接池针对空闲连接提供了检测和 校验机制。比如在申请使用该连接时，先测试该连接是否可用，定时检查空闲连接是否 可用等，空闲连接定时执行无意义的SQL以保证会话被验证为alive,推荐配置如下:

spring.datasource.druid.test-while-idle=true
spring.datasource.druid.validation-query=SELECT 1 FROM DUAL
spring.datasource.druid.validation-query-timeout=1000
sping.datasource.druid.min-Evictable-Idle-Time-Millis=300000
sping.datasource.druid.time-Between-Eviction-Runs-Millis=3000
spring.datasource.druid.keep-alive=true
spring.datasource.druid.remove-abandoned=true
spring.datasource.druid.remove-abandoned-timeout=3600
spring.datasource.druid.log-abandoned=true

一般使用以上配置后，就不会再出现连接中断的问题。

2.2 TCP网络

• keepalive 类Unix系统上,TCP 连接的 keepalive 可以在应用层实现，也可以在 TCP 中提供。 这个问题存在争议，因此 TCP 连接的保活探测并不是 TCP 规范中的一部分。但为了方便 ,几乎所有类 Unix 系统均在 TCP 中提供了相应的功能。

  常见类UNIX系统中的tcp keepalive:

  操作系统	保活定时器
  AIX	# no -a | grep keep
  	tcp_keepcnt = 8
  	tcp_keepidle = 14400
  	tcp_keepintvl = 150
  Linux	# sysctl -A | grep keep
  	net.ipv4.tcp_keepalive_intvl = 75
  	net.ipv4.tcp_keepalive_probes = 9
  	net.ipv4.tcp_keepalive_time = 7200
  FreeBSD	#sysctl -A | grep net.inet.tcp
  	net.inet.tcp.keepidle=…
  	net.inet.tcp.keepintvl=…

  不同系统上的各参数的时间单位不尽相同。在 AIX 上， tcp_keeidle/tcp_keepinit/tcp_keepintvl 的时间单位是 0.5 秒；而在 Linux 上， net.ipv4.tcp_keepalive_intvl 和 net.ipv4.tcp_keepalive_time 的时间单位则为秒。并 且，上述参数仅对运行在其上的服务器应用连接有效。

  note

  在 Solaris 上可通过“ndd /dev/tcp \?”命令显示上述类似参数信息，而在 HP

  Unix 上则可通过 nettune 或 ndd 命令进行查询。

  由于所有类 Unix 系统上均支持这种功能，因此，在接下来的部分中我们将基于 AIX 系统 具体讲述上述参数的意义和作用机制。

  控制参数	参数说明
  tcp_keepcnt	关闭一个非活跃连接之前进行探测的最大次数，默认为 8 次
  tcp_keepidle	对一个连接进行有效性探测之前运行的最大空闲时长，默认值为 14400（即 2 个小时）
  tcp_keepintvl	两个探测的时间间隔，默认值为 150 即 75 秒

  我们要通过设置这些参数，使其控制时间间隔要小于防火墙设置的最大空闲时间,如果不了 解防火墙的设置,可以将该tcp_keepintvl的值设置为3分钟以内，一般网络防火墙对于 空闲会话的限制不会短于这个时间。

• tcp retries 这里有另外一个现象，当连接被异常中断，但是程序这端的服务器没有收到相关终止信息 时，由原来存在的会话继续发送报文时，不会得到反馈，超过一定时间后，TCP会重新发 送该报文，直到超过最大允许重发次数。所以，有些时间，程序收到broken pipe 信息 时，是在一段时间以后(常见的是15分钟)。而在测试、开发人员的眼中，就是业务从开 始执行到报错, 中间等待了很久，比如15分钟。这里涉及到Linux内核对tcp 重发报文 次数的控制: net.ipv4.tcp_retries2 ,可以通过文件/proc/sys/net/ipv4/tcp_retries2 进行临时调整。

  其规则是:配置重传次数小于9的话，就是指数增长时间，如果大于9的话，就是最大超时时间.

  TCP_RTO_MIN=(HZ/5)=0.2s

  TCP_RTO_MAX=(120HZ)=120s

  linear_backoff_thresh = ilog2(1205)=ilog2(0x258)=9

  timeout：未超过linear_backoff_thresh=9的部分按TCP_RTO_MIN 2的指数倍增长，超过 的部分按TCP_RTO_MAX线性增长

  比如:

  sysctl_tcp_retries2=9，则timeout=1023TCP_RTO_MIN=204.6s sysctl_tcp_retries2=11时，timeout=1023TCP_RTO_MIN+2TCP_RTO_MAX=448.6s

针对这个问题，我们可以将重传次数设置得小一些。比如设置为3.

2.3 数据库监听

数据库也会把一些长时间没有任何操作的会话给kill掉，并不会给出任何的反馈。当程序 使用长连接，再次请求这些会话时，就会遇到报错。从数据库角度来讲，可以把空闲时间 设置得更长一些，但是这样是存在风险的，日积月累后，数据库中可能存在大量的空闲连 接，由于数据库一般会限制最大连接数的。如果大量的空闲连接存在，可能导致新的连接 无法建立。

• ORACLE oracle中对空闲会话的检测是在$ORACLE_HOME/network/admin/sqlnet.ora中配置

的,参数是sqlnet.expire_time ，单位是秒。比如:

sqlnet.expire_time=180

• MySQL 设置wait_timeout 指定空闲时间，单位是秒，最长不建议超过1天。

Author: halberd.lee

Created: 2019-09-26 Thu 21:20

Validate