记一次生产高并发导致nginx频繁超时问题排查（历史）

提供给我的页面内网域名（inter.xxxx.xxxx）从1月1日中午开始陆陆续续有nginx 499 链接断开的告警，12月30日有过类似问题的发生，但是只出现了几次。

       当时排查问题原因以为是机器内存过小导致，因为线上机器中只有一台机器是8G 而正好是告警的业务机器，就替换16G内存机器。这个错误的决定也导致了后面问题的再次发生，因为我们的JVM参数中配置的JVM大小是4G，机器内存8G。

       现象：

              1月1号11点左右nginx告警不断，由于新版APP审核通过，nginx 从1号QPS一直在上升的趋势。

       问题排查：                 

              1.业务耗时

              期间观察QPS情况一直在不断攀升，而基线后端请求我们的超时时间是300毫秒，在业务监控中观察接口请求均为50毫秒以内返回，极个别的请求会超过300毫秒，其原因是查询passport耗时，但这种请求极少数，所以排除业务接口处理过慢的问题。

              2.业务机器性能

              在jvm监控中发现yangGC的次数比较高，每次在200ms左右，所以怀疑jvm yangGC时的卡顿导致请求处理排队，返回时间过长再加上网络耗时可能会超过300ms导致基线后端链接断开。后面的网络排查否定了这一情况。

      

              3.网络排查

                     大多数nginx 499链接断开的请求耗时都在0.030秒以内甚至0.000就499断开，之前了解到基线后端的主力机房在百度万国，而我的钱包机房是北京电信和北京联通，怀疑基线后端请求到我们中间就耗时比较长，ngxin是一直在用的，业务也没问题新增加的只有QLB，所以找到基线后端的运维和QLB同事一起排查发现网络没有问题。

              4.ngxin机器性能

                     在爱奇艺云平台观察到nginx整个机器CPU在95%。在nginx机器中观察到venusagent占用CPU高达80%以上，停掉venus后nginx机器的CPU没有下降迹象，联系venusagent负责同事后得知venusagent只使用机器中一个核心。

       最终原因：对CPU占用的进程逐一排查，发现nginx机器中一直会有grep进程，grep进程来自于nginx_api_qps_alert.sh。发现该文件每隔5分钟会使用grep 命令分析日志文件，而且不断会产生新的grep进程，inter.xxxx域名所产生的日志文件没有做切割，导致该文件过大，发现时已经18G，grep 信息时占用cpu较大，导致无法处理其他请求，删除日志文件后杀掉grep进程cpu负载降低至5%以下。

       后续跟进：

              inner.xxxx域名产生的日志文件进行切割，避免日志文件追加过大，导致grep信息时占用cpu负载的问题。

       总结：

              问题的排查需要多方面考虑，对于监控告警的产生分析不够透彻，对于问题的定位过于武断，没能深入分析问题产生原因，从而导致问题再次发生，线上压测时间过短没能体现问题所在。

 关注我的公众号 LearnMoreDoMore 可以及时看到更多技术分享文章（不会该死的卖课广告）。