【案例】某基金FMS系统交易慢故障分析

在传统的IT网络建设期，用户主要着重于IT网络及主机的基础架构建设与维护，而在建设后期客户需要更加主动、灵活、可视化并专注于关键业务系统性能的监控分析。传统运维就像扑火式的运维，当出现业务不通、交易不畅的现象时，网络运维人员就会马上使用各种ping、tracert，使用网管查看交换机内存、端口状态。

当前，客户的IT环境更多强调数据对接、三方互联，实时性、稳定性、安全性缺一不可的前提下，需要做到以业务为核心的性能监控、告警定位分析、挖掘数据包分析，从上至下的监控分析思路，形成业务性能的完整管理闭环。下面就是一个金融行业的故障分析案例。

故障背景

在某Top规模基金公司在高频交易时段，用户反应交易访问慢，该问题已持续两个月之久未得到解决。

业务访问逻辑及部署

网络工程师在客户核心网络交换机部署科来网络回溯分析设备，镜像所有交易系统流量，进一步分析系统故障。生产网部署示意图如下：

业务访问逻辑：客户端→交易服务器→数据库

分析结果及建议

客户端与交易服务器网络性能良好，客户端由于Delay ACK机制，对交易服务器的响应交易数据存在大量延迟确认现象。

建议向应用部门反映此情况，修改请求方Delay ACK参数。

回溯告警参数设置建议

在科来回溯分析系统点击应用警报可以设置客户端或者服务端ACK延迟>=200ms长期监控此类问题，一旦有延迟ACK确认故障触发应用报警，我们可以根据告警明细快速找到有问题的主机。

分析过程

在交易性能慢的时间段内，提取客户端→交易服务器之间的通讯数据包进行分析。流量总体运行平稳，没有突发。TCP同步包与同步确认包比例接近1:1，网络性能各项指标良好。

同时对FMS系统的TCP会话ACK Time排名发现客户端→交易服务器的平均ACK延迟高达到200多毫秒。

提取相应时段的会话数据包，均能看到客户端与交易服务器之间存在大量Delay ACK延迟确认，延迟确认时间大约200ms左右。如下图所示：

Delay ACK机制原理

Delayed ACK机制是通过减少网络中的ACK数据包降低网络负载，在一个连接中，客户端在交易服务器发送数据后，并不立即发送ACK,会延迟这个ACK的发送，只有以下情况时才会发出对本端数据的ACK确认：

• 应用层的处理完毕，与返回数据一起发送；

• 连续收到服务器端两个TCP报文段；

• 延迟确认计时器轮转超时（默认设置为200ms）；

在上面截图中，客户端对于交易服务器的请求报文，未立即确认，而是在延迟确认计时器超时时，才发出ACK确认，过多的延迟确认时间，导致传输效率下降，从而影响到客户访问交易慢。

-END-