当前位置: 首页 > 工具软件 > MIN1PIPE > 使用案例 >

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

傅高逸
2023-12-01

 java.sql.SQLRecoverableException: IO Error: Broken pipe

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

转载于:https://www.cnblogs.com/halberd-lee/p/11594548.html

 类似资料:

相关阅读

相关文章

相关问答