版权信息：
作者：drfdai
邮箱：63780668@qq.com
昨天晚上，2台后端apache服务器负载突然变的超大（昨晚24点睡觉时硬重启了下apache服务，今天8点起来，负载又跑到了400多）
如下图：
回到昨天吧，昨天服务器报警，服务器负载变大了
这是昨天的截图：
top图：
vmstat图：
服务器网络链接：
iostat图：
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负载正常了，故障解决
如下图：
运维，不能只靠技术，思想很重要
附：
与运维朋友的交谈：
Ｓ2Ｔ69丶 邓亚运(1223809852) 11:42:34
都说程序问题了
昨天就说过直接找程序猿
Ｓ2Ｔ69丶邓亚运(1223809852) 11:46:18
通过你昨天的截图初步就知道应该是程序问题了
Ｓ2Ｔ69丶戴儒锋(63780668) 11:43:54
别这么果断，没有找到原因之前，不能直接找开发
如果不是程序问题，那你以后再出问题，他们百分百会把责任推你身上
2Ｔ69丶戴儒锋(63780668) 11:48:00
太果断
也有可能是架构或服务配置引起的
Ｓ2Ｔ69丶 罗小波<xiaoboluo768@163.com> 11:52:52
我们这边经常出现mysql服务器突然高负载的情况，有时候是突然高一下就恢复了，有时候是一直高负载，我们运维这边没有做任何操作，但是一开始也要先排除不是运维问题，并且还会尽量找出证据是他们研发的问题
表面一看就是程序问题了，为什么不直接找开发改呢？
我是这样想的，如果不是程序问题怎么办？如果这次是运维问题，那以后怎么取得开发的信任？所以我们这方面经验不够丰富之前，如果业务不紧急的情况下，我们应该先检查自身，排除自身的情况外，再联系开发解决，这样我们容易取得大家的信任，以后容易工作。
还有，出了问题，一定要跟上级及时汇报
邮箱：63780668@qq.com
昨天晚上，2台后端apache服务器负载突然变的超大（昨晚24点睡觉时硬重启了下apache服务，今天8点起来，负载又跑到了400多）
如下图：
回到昨天吧，昨天服务器报警，服务器负载变大了
这是昨天的截图：
top图：
vmstat图：
服务器网络链接：
iostat图：
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负载正常了，故障解决
如下图：
运维，不能只靠技术，思想很重要
附：
与运维朋友的交谈：
Ｓ2Ｔ69丶 邓亚运(1223809852) 11:42:34
都说程序问题了
昨天就说过直接找程序猿
Ｓ2Ｔ69丶邓亚运(1223809852) 11:46:18
通过你昨天的截图初步就知道应该是程序问题了
Ｓ2Ｔ69丶戴儒锋(63780668) 11:43:54
别这么果断，没有找到原因之前，不能直接找开发
如果不是程序问题，那你以后再出问题，他们百分百会把责任推你身上
2Ｔ69丶戴儒锋(63780668) 11:48:00
太果断
也有可能是架构或服务配置引起的
Ｓ2Ｔ69丶 罗小波<xiaoboluo768@163.com> 11:52:52
我们这边经常出现mysql服务器突然高负载的情况，有时候是突然高一下就恢复了，有时候是一直高负载，我们运维这边没有做任何操作，但是一开始也要先排除不是运维问题，并且还会尽量找出证据是他们研发的问题
表面一看就是程序问题了，为什么不直接找开发改呢？
我是这样想的，如果不是程序问题怎么办？如果这次是运维问题，那以后怎么取得开发的信任？所以我们这方面经验不够丰富之前，如果业务不紧急的情况下，我们应该先检查自身，排除自身的情况外，再联系开发解决，这样我们容易取得大家的信任，以后容易工作。
还有，出了问题，一定要跟上级及时汇报
转载请注明linux系统运维：
http://www.linuxyw.com/a/yunweiguzhang/20130607/552.html
转载于:https://blog.51cto.com/drfdai/1217895
662
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
