【项目实战-1】NAT网关的最佳实践

【问题表现】

项目某后台接口QPS出现周期性的掉坑现象。每一次耗时的峰值，都对应一次QPS掉坑。

【问题分析和排查思路】

从波形图来看一定是资源耗尽，才会出现周期性的掉坑现象。分析问题之前，首先要拿到整个链路，如下：

压测机（运行Jmeter脚本）--> NAT网关 --> STGW --> nginx --> 项目后台

这里每个环节都可能出问题，需要每个链路去排查。

1.首先查看业务后台的资源占用

CPU、内存都不高，函数耗时也不长。看来压测流量还没打到业务后台，需要继续往前找原因。

下面是 23:41 ～ 23 ：50之间，场景getlist压测时候的rpc 耗时，平均耗时都在 50ms以下 。

2.分析nginx的日志，看看是否有压测流量

外层nginx的access日志，23:41~23:44之间访问量为0。这个现象和压测工具界面上看的QPS表现一致，说明压测流量没有过来。

3.查看NAT网关，看是否有带宽限制

NAT网关出带宽为5000 Mbps，实际使用不到20 Mbps，排除。

4.查看压测机的资源占用

查看压测机的CPU，内存和网络情况，也没有发现啥异常情况。

业务方的压测同学提供了如下的信息：

掉坑的地方会出现connection timeout，该接口耗时高达31秒

拉了NAT网关的同学一起来排查问题，发现确实是EIP不够用的问题。

给NAT绑定了10个EIP，问题得以解决

【总结】

通过NAT网关配置出口IP往往一开始只配置一个IP，端口数的上限是65535。对于实时通讯的场景来说，需要保持大量的长连接，所以需要提高端口数量。

整体排查思路如下：

1. 首先要转变意识，不要停留在单点排查，要有全链路的意识
2. 每个环节进行初步排查，看能否快速定位问题
3. 实在没有办法，就只能抓包分析了