结论
915投产演练时，因服务器刀容存在问题，引起了网络抖动，致使响应时间超长，耗尽了渠道接入数量，积累大量请求得不到请求，客户端主动断开链接，服务端后续处理返回时回写数据失败。
问题
以下截图，是一段来自服务器的渠道接入（Socket）异常信息。
通信代码抛异常：
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） ；
分析思路
- 使用【kcusage】查看系统参数设置情况，是否正常！命令：
/usr/sbin/kcusage
检查系统用户【可用文件句柄数】max_file_limt，设置太小，会导致渠道无法创建更多链接数，导致渠道接入能力弹性伸缩失败（增加接入数失败）；
检查系统用户【可用线程数】max_thread_proc，如果设置太小，导致建立渠道连接时无法可用线程，也会导致渠道接入能力的弹性伸缩失败（增加接入数失败）；报错如下：
检查应用上渠道连接数配置，【接入数】应该与【预期并发数】大小匹配。
检查【启动内存】设置，应该足够大，以支持大并发时建立连接、处理业务所需要内存。
-Xms1024m -Xmx2048m -XX:MaxPermSize=256m
- 检查【网络延迟】情况，因为网络延迟会增加socket通信时间，增加了对渠道连接数的消耗量，即使接入数量为预期配置，但是会被很快消耗掉；
- 查看客户端与应用服务器之间的【网络情况】——ping， 是否有延迟，是否有丢包；
- 查看应用服务器服务【端口占用数】—— netstat -an | grep 9901 | grep “ESTABLISH| "wc -l ，对比ESTABLISH的数量和配置参数值大小情况；
收获
同样的代码，部署新环境后，出现问题，排查内容和顺序：
服务器参数检查（硬件）
-
网络环境的检查（网络）
检查点1： 请求方与服务方之间的网络ping情况
检查点2： 服务器之间的网络ping情况；
检查点3： F5负载/软负载/网关 这种入口系统与应用服务器之间的网络ping情况； -
应用自身的配置（应用配置）
- 检查点1： 接入能力，如：渠道配置 —— ip、断开、接入数、弹性配置（初始、增量、最大）
- 检查点2： DB能力，如：数据库配置——ip、断开、用户、密码、弹性配置（初始、增量、最大）、恢复
- 检查点3： 与Backend的通信能力，如：通道配置
3、做系统预热（综合）
