背景:
某天公司突然发现整个网站访问很慢,请求大部分报502,基本处于宕机状态....时间大概持续一整晚,导致公司大量的投诉直接造成经济损失...
网站主要使用的技术栈:
nginx+php+mysql+redis
阿里云ecs
定位问题过程:
第一步就去查看mysql服务器状况,是否有慢查询导致,结果是mysql运行良好
第二步查看web服务器服务器情况,内存使用偏高,但整体负载并没有过红线
第三步查看redis服务器,服务器负载“运行良好”(这里先打个引号后面详细说明)
以上我把它称为排查问题的前置3部曲,检查问题的基本操作。
结果运维工程师告诉我3步完成后竟然一点问题都没有,我当时就有点蒙....
开始检查当天发布的代码是否有可能出现问题,但当时思绪是没有目标的,我们就像无头苍蝇一样扫代码(可想而知没有大概的范围是很难解决的,你得告诉开发工程师大概的方向才能定位问题)...
再次督促运维工程师继续排查...
二次定位问题过程:
检查nginx访问日志,全是60秒超时,查看高峰日志最高约1800/秒左右,这时突然想到我们的php-fpm是静态部署,每台设置260左右的数量(也就是并发最多260个访问左右),我们有6台web 也就是1560(260*6)左右
得出第一结论:我们的web服务器访问数满负荷了,吞吐量很低,也就是访问要排队了
第一结论的疑问1:为什么访问接满负荷web服务器负载没有超红线?
原因:2