提供给我的页面内网域名(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 可以及时看到更多技术分享文章(不会该死的卖课广告)。