著作權資訊：
作者：drfdai
郵箱：63780668@qq.com
昨天晚上，2台後端apache伺服器負載突然變的超大昨晚24點睡覺時硬重啟了下apache服務，今天8點起來，負載又跑到了400多）
如：
650) this.width=650;" src="http://www.bkjia.com/uploads/allimg/131227/1PKK558-0.jpg" style="padding:0px;margin:0px;border:none;" />
回到昨天吧，昨天伺服器警示，伺服器負載變大了
這是昨天的：
top圖：
650) this.width=650;" alt="apache 負載高" src="http://www.bkjia.com/uploads/allimg/131227/1PKG148-1.png" style="padding:0px;margin:0px;border:none;height:440px;width:690px;" />
vmstat圖：
650) this.width=650;" src="http://www.bkjia.com/uploads/allimg/131227/1PKL1H-2.png" style="padding:0px;margin:0px;border:none;height:248px;width:690px;" />
伺服器網路連結：
650) this.width=650;" src="http://www.bkjia.com/uploads/allimg/131227/1PKLV2-3.png" style="padding:0px;margin:0px;border:none;height:73px;width:690px;" />
iostat圖：
650) this.width=650;" alt="apache 負載高" src="http://www.bkjia.com/uploads/allimg/131227/1PKJ150-4.png" style="padding:0px;margin:0px;border:none;height:29px;width:69px;" />
apache worker_module配置圖：
650) this.width=650;" src="http://www.bkjia.com/uploads/allimg/131227/1PKK320-5.jpg" style="padding:0px;margin:0px;border:none;" />
這幾天伺服器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負載正常了，故障解決
如：
650) this.width=650;" alt="apache 負載高" src="http://www.bkjia.com/uploads/allimg/131227/1PKL0R-6.png" style="padding:0px;margin:0px;border:none;height:133px;width:690px;" />
營運，不能只靠技術，思想很重要
附：
與營運朋友的交談：
Ｓ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
本文出自 “江江” 部落格，請務必保留此出處http://drfdai.blog.51cto.com/3825228/1217895
