Broken pipe 问题

结论

915投产演练时，因服务器刀容存在问题，引起了网络抖动，致使响应时间超长，耗尽了渠道接入数量，积累大量请求得不到请求，客户端主动断开链接，服务端后续处理返回时回写数据失败。

问题

以下截图，是一段来自服务器的渠道接入（Socket）异常信息。

broken-pipe.png

通信代码抛异常：

java.net.SocketExcetipn:Broken pipe（Write failed）

是什么意思呢？

直观解释 —— 回写（服务端向前端socket连接管道写返回数据）数据时，链接（pipe）却断了！….

从应用角度分析，这是因为客户端（TWS）等待返回超时了，主动断开了与服务端（BS）的链接—— TWS 与 BS是短链接，请求时建立，“请求》处理》响应”完成后即结束，关闭链接。

从服务端日志分析，交易逻辑均正常，无异常，处理速度也很快（包括：BS自己、BS与外界）只是在通信返回时报了Broken pipe的异常。

如何引起的？

解决这个问题，根本在于找出【通信链接是如何被关闭的】这个根本原因所在！

渠道接入连接数设置太小，并发量增加后，造成大量请求排队等待，等待了69秒才获得处理，但是处理时间超过1秒，此时TWS主动断开了链接（假设：超时时长为70秒），虽然服务端完成了处理，但是返回结果时，发现此前建立的通信链接已断开了——Broken pipe（Write failed） ；

分析思路

1. 使用【kcusage】查看系统参数设置情况，是否正常！命令：

/usr/sbin/kcusage

kcusage 命令

• 检查系统用户【可用文件句柄数】max_file_limt，设置太小，会导致渠道无法创建更多链接数，导致渠道接入能力弹性伸缩失败（增加接入数失败）；

• 检查系统用户【可用线程数】max_thread_proc，如果设置太小，导致建立渠道连接时无法可用线程，也会导致渠道接入能力的弹性伸缩失败（增加接入数失败）；报错如下：

2. 检查应用上渠道连接数配置，【接入数】应该与【预期并发数】大小匹配。

3. 检查【启动内存】设置，应该足够大，以支持大并发时建立连接、处理业务所需要内存。

-Xms1024m -Xmx2048m -XX:MaxPermSize=256m

4. 检查【网络延迟】情况，因为网络延迟会增加socket通信时间，增加了对渠道连接数的消耗量，即使接入数量为预期配置，但是会被很快消耗掉；

• 查看客户端与应用服务器之间的【网络情况】——ping， 是否有延迟，是否有丢包；
• 查看应用服务器服务【端口占用数】—— netstat -an | grep 9901 | grep “ESTABLISH| "wc -l ，对比ESTABLISH的数量和配置参数值大小情况；

收获

同样的代码，部署新环境后，出现问题，排查内容和顺序：

1. 服务器参数检查（硬件）

2. 网络环境的检查（网络）

   检查点1： 请求方与服务方之间的网络ping情况
   检查点2： 服务器之间的网络ping情况；
   检查点3： F5负载/软负载/网关 这种入口系统与应用服务器之间的网络ping情况；

3. 应用自身的配置（应用配置）

   • 检查点1： 接入能力，如：渠道配置 —— ip、断开、接入数、弹性配置（初始、增量、最大）
   • 检查点2： DB能力，如：数据库配置——ip、断开、用户、密码、弹性配置（初始、增量、最大）、恢复
   • 检查点3： 与Backend的通信能力，如：通道配置

3、做系统预热（综合）