公司每周会对.net web网站进行更新，而我这边每天会对该web网站进行定时压测，周二更新好后，周三的定时压测抛出大量的504错误，开始对其进行排查。如图：

公司的服务器环境使用阿里云，入口机器为一台linux，进行分流及转发的操作，而web服务器搭建在Windows2008上，起初怀疑是程序问题，因为504错误是在程序更新后发生的，并且压测过程中，CPU占用会处于100%，如图：

图中所示，深色线条是错误数，浅色线条是CPU占用，高并发下CPU 达到瓶颈，而错误数开始上升，2者之间呈规律式，请求多，cpu高；cpu高，错误多；错误多，请求少了；请求少了，cpu则低了，呈一个循环；经过观察，web段，开发自己编写了3个tcp服务，并且这3个tcp服务器在压测过程中，cpu占用特别高；所以将这3个服务停止，504报错就没出现。

该错误情况，本应该这样结束了；但是事后考虑，之前的每日压测，这3个服务也是开着，cpu也一直是饱和状态，但是系统从来没报504，为什么现在会报？应该不单单是这3个服务的问题；随后就想到，是不是程序逻辑的问题，通过检查IIS日志和系统日志，发现页面新调用了个接口超时，导致整个页面500，这问题上报给了开发，但是只是解决了500错误，而504错误仍然在，排查继续中....

然后继续使用windbg工具进行调试，压测中，使用windbg先抛出dump日志，然后进行分析，不过看了下，有问题的线程日志，都是内核原因，开发也无法定位，只能放弃。

问题排查进展到这里，好像进入了死胡同，之前从来没考虑过linux入口服务器的问题，因为这台服务器的设置没更改过；后来在压测中，先用netstat | find "ip" 查看到有3w左右的tcp端口开着，状态是close_wait()，网上查了下，该接口表示被请求端正在等待关闭，然后在linux服务器上同样检查netstat -ano | grep "ip" 发现同样开启了3w左右的端口，大多数tcp端口状态是open_wait()，然后查看了下本台linux服务器的端口配置，端口范围只能从32000-61000 只能开启29000个端口；终于，找到了问题所在，由于入口服务器，只能同时接收2w9个请求，在循环压测中，请求连续不断，而由于web服务器因为新增了功能，cpu处理能力下降，导致请求释放变慢，导致入口服务器tcp端口爆满，额外超出的请求，只能抛出504（gateway timeout）错误。