版权信息：
作者：drfdai邮箱：63780668@qq.com昨天晚上，2台后端apache服务器负载突然变的超大（昨晚24点睡觉时硬重启了下apache服务，今天8点起来，负载又跑到了400多）如下图：iostat图：
apache worker_module配置图：
这几天服务器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系统运维：
本文出自 “江江” 博客，请务必保留此出处
一个人的天地是冷得连呼吸都会寂寞的颤栗，而麻烦，
