Broken pipe问题排查

问题：

|ERROR|c.x.s.c.s.AccessPermissionFilter|b2a299e5a8cbe429.b2a299e5a8cbe429<:b2a299e5a8cbe429||Unexpected error occurred in AccessPermissionFilter: com.xueqiu.snowball.common.servlet.ExceptionWrapper: org.apache.catalina.connector.ClientAbortException: java.io.IOException: Broken pipe|||

描述：

AccessPermissionFilter组件是不是有点问题，最近部署的时候总报这个错误

 

10.10.54.21 版本com/xueqiu/snowball/snowball-common/4.17/snowball-common-4.17-sources.jar!/com/xueqiu/snowball/common/servlet/AccessPermissionFilter.java

复现：

IDEA后端接口打断点，浏览器发起请求

在IDEA断点没有往下执行的情况下，浏览器停止接收（点击X）

或者你一直刷新页面，刷新的速度比服务器返回给你的速度快

IDEA就会出现错误，broken pipe（主机中的软件中止了一个已建立的连接）。

tip：

并不是只有超时才会导致这个问题，只要是连接断开，再往这个断开的连接上去执行写操作，都会出现这个异常，客户端超时断开只是其中的一种情况

 

分析：

软件方面：

Broken pipe产生的原因通常是当管道读端没有在读，而管道的写端继续有线程在写，就会造成管道中断。（由于管道是单向通信的） SIGSEGV(Segment fault)意味着指针所对应的地址是无效地址，没有物理内存对应该地址。 
以下是UNIX的信号解释： 
11 / SIGSEGV: Unerlaubter Zugriff auf Hauptspeicher (Adressfehler). 
12 / SIGUSER2: User-defined Signal 2 (POSIX). 
把_JAVA_SR_SIGNUM改成12只是将信号至成user-defined，让它不报出来而已，不能解决问题。 

Tips:
“_JAVA_SR_SIGNUM=12”等号两边必须没有空格，等号是半角 

 

sun的解释： 
   －－posted by: cooper 
Below is a clipping from Sun on working around JVM crashes under high thread counts in the JVM 1.3 for Linux.
On Linux, use a larger signal number for hotspot thread suspension/resumption handler. 
The signal number being used is specified by environment variable _JAVA_SR_SIGNUM. 
Setting it to a number larger than SIGSEGV (11) will solve the problem. 
A good number to use is 12, which is SIGUSR2. 
Using signal 16 to work around the problem might have potential problems. 
So on tcsh,"setenv _JAVA_SR_SIGNUM 12" can solve the problem.

系统方面：

用命令查看ulimit系统限制：ulimit -a  通过 ulimit 改善系统性能

 

用命令查看系统总句柄数：/proc/sys/fs/file-nr

 

用命令查看当前应用打开的文件句柄数：ls -l /proc/{pid}/fd | wc -l

 

**上面这三部分，可以看出来**

1.系统已经占用的句柄数远远小于系统最大句柄数

2.系统允许的单个进程创建的最大socket链接是524288，snowflake应用占用的链接是1978远小于允许最大值

以下部分是用在系统方面有问题时进一步排查

用命令查看tcpip的状态： netstat -n | awk '/^tcp/ {++state[$NF]} END {for(key in state) print key,"\t",state[key]}'  

 

用命令查看系统的keepalive配置：sysctl -a |grep keepalive  

 

线上操作时，这个命令没有权限，op用户查看信息为空，我下面就截取一张我这边的一台Linux虚拟机做参考（因为CLOSE_WAIT不多，这次问题不出现在这里）

 

（由此便可以看出，当CLOSE_WAIT的占用数量过多时，就需要优化keepalive的时间）当前咱们的系统明显不存在此类问题

扩展:

这个异常是由于以下几个原因造成。 

1、客户端再发起请求后没有等服务器端相应完，点击了stop按钮，导致服务器端接收到取消请求。
     通常情况下是不会有这么无聊的用户，出现这种情况可能是由于用户提交了请求，服务器端相应缓慢，比如业务逻辑有问题等原因，导致页面过了很久也没有刷新出来，用户就有可能取消或重新发起请求。

2、Tomcat服务器在接受用户请求的时候，有其自身的处理能力，线程、服务器等各个资源限制，超出Tomcat承载范围的请求，就会被tomcat停掉，也可能产生该错误。 

3、linux的线程机制会产生JVM出错的问题，特别是在连接高峰期间经常出现这样的问题，tomcat在linux下也出现类似情况。

建议： 

1． 资源没有完全释放，用完后要至NULL 值（JAVA的GC没那么完善）

2． 数据库连接顺序关闭！（RS，PS，CONN） 

3． 优化JAVA虚拟机 加入相应的内存参数！ 

4． 不要在数据库中获取大段文本（即一个栏位的值不要太大）

5． JAVA 不推荐 用String 获取大量信息。（容易造成内存泄露，建议用StringBuffer）

6． 页面重复提交 

7． 尽量将METHOD移到JAVA中，在JSP中所有的方法都看做全局变量，编译执行本身就有很多问题。 

8． 如果是查询功能，尽可能的使用非XA(事务)。 

9． 尽量用较新较稳定版本的JDK，低版本的JVM本身也有很多BUG，比如1。5的垃圾回收比起1.2，1.3一定是非常明显的进步。 

10． LINUX系统本身没有这么稳定，有些问题无法避免的~~：）

**以下是数据库链接的问题，不在web问题范围内**

XA协议由Tuxedo首先提出的，并交给X/Open组织，作为资源管理器（数据库）与事务管理器的接口标准。目前，Oracle、Informix、DB2和Sybase等各大数据库厂家都提供对XA的支持。XA协议采用两阶段提交方式来管理分布式事务。
XA接口提供资源管理器与事务管理器之间进行通信的标准接口。XA协议包括两套函数，以xa_开头的及以ax_开头的。

解决方案：

1.eg：progress公司解决方案 忽略这种异常

 

**雪球应该来忽略吗？为了防止频繁报警的引起的误会，将该异常捕获记录为warn**

2.后来又发现一个版块与APP的信道有关：Broken pipe异常分析及解决

 

• • 咱们的matrix监控，snowflake的QPS不到1000，由上面服务器的参数来看，看来不是并发导致的
  • client端的并发请求？
    用ab来模拟APP端上的并发请求，control+C中断，出现大量报错，

 

借用他人的结论：

1.问题原因
client端用户在杀死进程时，接口的TCP请求尚未完成（未完成的原因是处理时间长）。 
导致server端write数据时，收到SIGPIPE信号，抛出Broken pipe异常。 
但由于已经杀死了进程，并不会对用户产生任何影响。

2.其他结论
ios和android在处理1M以内（尚不清楚有没有最大值）大小报文时，没有问题
ios和android均是阻塞请求，本次请求不会对上次请求造成影响，即使上次请求尚未完成
ios切换至后台，短时间内（5000ms以内，最大值根据系统不同而不同）并不会中断已经存在的TCP连接。
android切换至后台，并不会中断已经存在的TCP连接。
ios、android杀死进程会一并关闭已经存在的TCP连接。
android框架（公司基于google改造的框架）默认并发5线程一组。
3.解决方案
由于kill进程我们无法控制，故只能通过降低接口处理时间，减少用户kill进程时未完成的TCP连接数量。

**具体**

1. 1. 1. 会话列表翻页
      2. 会话列表限制展示数量
      3. 客户端分组获取会话列表数据

3.另外，经过内部讨论，部分产品APP端不直接请求SERVER，大部分由NGINX代理，因此，此问题应该是大部分出现在微服务之间的相互调用

1.微服务的异步调用没有约定一个response wait time，调用方主动关闭

2.调用方微服务的重新部署，没有实现graceful shutdown，暴力关闭

过程：

1.问题原因已经make sure ✔️

2.目前公司的架构服务都存在这种问题，不影响线上，故本次先不进行处理，issues状态留存

参考资料：

https://confluence.atlassian.com/jirakb/clientabortexception-java-io-ioexception-broken-pipe-225122378.html

https://stackoverflow.com/questions/642061/error-commiting-response-java-io-ioexception-broken-pipe-at-sun-nio-ch-filedisp

https://stackoverflow.com/questions/15785175/java-io-ioexception-broken-pipe

http://www.cnblogs.com/liu1989/p/3383714.html

https://blog.csdn.net/zqz_zqz/article/details/52235479

https://community.oracle.com/thread/1347653

https://issues.apache.org/jira/browse/WW-4386

https://gaoyaohuachina.iteye.com/blog/2399765

https://blog.csdn.net/zqz_zqz/article/details/52235479

https://www.ibm.com/developerworks/cn/linux/l-cn-ulimit/index.html

https://blog.csdn.net/ooppookid/article/details/54891771