apache服务器负载高之故障排查(思想方法)

版权信息

作者:drfdai
邮箱:[email protected]


昨天晚上,2台后端apache服务器负载突然变的超大(昨晚24点睡觉时硬重启了下apache服务,今天8点起来,负载又跑到了400多)
如下图:


回到昨天吧,昨天服务器报警,服务器负载变大了
这是昨天的截图:
top图:
apache 负载高

vmstat图:


服务器网络链接:


iostat图:
apache 负载高

apache worker_m odule配置图:



这几天服务器PV一下子增多,用cnzz站长统计工具查看,日PV40多万,以前PV只有几万,看了这些数据,有点怀疑是服务器硬件或服务配置或 网络架构不合理导致的,因为我们服务器是很老的了,而且很多配件还是DIY出来的,请勿见笑。

排查流程:
1:就是用以上 命令查看各种数据了,即上图
2:服务器是用了NFS架构的,后端的apache所读取的文件,都是从NFS 文件服务器上所读过来的,所以,把程序打包SCP到apache-1服务器本地,解压到本地文件夹,并把apache虚拟目录指向这个文件夹。在前端nginx上把apache-1服务器注释掉,让前端不分配请求给apache-1 服务器,然后在apache-1重启apache服务,然后单独访问这台apache-1,没问题,在前端开启apache-1,再查看apache-1的负载,结果还是一样负载这么大。
结论:这跟NFS无关(NFS也是很老的硬件配置了,不过交换机还是用的思科千M的。)
3:排查apache配置和内核,把worker参数修改,内核参数修改,把time_wait改小,硬重启apache,故障依在。
4:因为后端的2台apache服务器都出现负载问题,所以,现在可以排除硬件问题了。我apache用的是worker模式,按理,established这么小的情况下,而且我把time_wait又改小了,其实内核最大只保留1000个time_wait,而且有效果时间改成300,在worker_module的MaxRequestsPerChild只有300,服务器应该很快释放连接才对,也就是说,不可能会存在这么多HTTPD进程,看文章前面的图片top图。因此,非运维问题,那就要靠 运维思想来解决了。老男孩老师就教过,故障排查方法之一: 定位
何为定位?就是故障发生前后,我们都做了什么操作?
运维方面,我没做什么啊?那应该不是运维方面导致的了。
开发方面?
今天上班,我就找开发部问了,前二天做了什么操作吗?改了什么代码?然后,就让他们检查代码去了,他们根据时间定位,把相关修改过的代码回滚到故障前。
把apache服务硬重启下,观察半小时,OK,CPU负载正常了,故障解决
如下图:
apache 负载高

运维,不能只靠技术,思想很重要

附:
与运维朋友的交谈:
S2T69丶 邓亚运(1223809852)  11:42:34
都说程序问题了
昨天就说过直接找程序猿
S2T69丶邓亚运(1223809852)  11:46:18
通过你昨天的截图初步就知道应该是程序问题了
S2T69丶戴儒锋(63780668)  11:43:54
别这么果断,没有找到原因之前,不能直接找开发
如果不是程序问题,那你以后再出问题,他们百分百会把责任推你身上
2T69丶戴儒锋(63780668)  11:48:00
太果断
也有可能是架构或服务配置引起的
S2T69丶 罗小波<[email protected]>  11:52:52
我们这边经常出现mysql服务器突然高负载的情况,有时候是突然高一下就恢复了,有时候是一直高负载,我们运维这边没有做任何操作,但是一开始也要先排除不是运维问题,并且还会尽量找出证据是他们研发的问题



表面一看就是程序问题了,为什么不直接找开发改呢?
我是这样想的,如果不是程序问题怎么办?如果这次是运维问题,那以后怎么取得开发的信任?所以我们这方面经验不够丰富之前,如果业务不紧急的情况下,我们应该先检查自身,排除自身的情况外,再联系开发解决,这样我们容易取得大家的信任,以后容易工作。

还有,出了问题,一定要跟上级及时汇报

转载请注明linux系统运维:
http://www.linuxyw.com/a/yunweiguzhang/20130607/552.html


你可能感兴趣的:(故障排查,服务器负载,思想方法)