憑借我對這些問題的直覺，首先就是意識(shí)到服務(wù)器出故障了，因?yàn)槲覀兊木W(wǎng)站流量不可能就在這幾天內(nèi)增加多少，也不可能是因?yàn)槲覀兂绦蛴兄T如死循環(huán)的故障。那個(gè)時(shí)候我感覺很無奈，因?yàn)樵谖抑霸诰W(wǎng)上看到的那些解決方案針對的問題我們自己的這個(gè)并不會(huì)出現(xiàn)，比如我們一直沒有修改網(wǎng)站程序所以不太可能造成網(wǎng)站程序上的錯(cuò)誤，也一直沒有更改服務(wù)器的配置搜易也不太可能是WEB服務(wù)器配置的故障。

我們看了服務(wù)器的資源消耗情況，發(fā)現(xiàn)服務(wù)器的內(nèi)存消耗在正常水平，而服務(wù)器的CPU資源消耗一直是爆滿的100%。因?yàn)閱栴}已經(jīng)出現(xiàn)了，而且這樣的問題可能讓我們失去訂單，因此我們必須盡快的解決它。于是縱然我們知道網(wǎng)上常用的解決方案所針對的不是我們出現(xiàn)的問題，但我們還是去嘗試了，比如調(diào)整Apache的配置、查看Apache的錯(cuò)誤日志、Apache和操作系統(tǒng)的沖突等等，但沒有任何作用，比如我們查看Apache的日志沒有任何錯(cuò)誤，只有我們之前重啟等操作的警告或者通知信息。

我們甚至嘗試重啟Apache，結(jié)果發(fā)現(xiàn)已啟動(dòng)這個(gè)服務(wù)CPU馬上就飆到了100%，我們直接重啟了服務(wù)器也沒任何作用。

到這個(gè)時(shí)候我們已經(jīng)排查一個(gè)多小時(shí)了，但依然沒有任何進(jìn)展，于是我們想到了是否有大量流量的攻擊，但查看我們這臺(tái)服務(wù)器的幾個(gè)主要網(wǎng)站的日志的時(shí)候發(fā)現(xiàn)并沒有固定的IP頻繁訪問網(wǎng)站，也就不是那種專來做攻擊的。

就在這個(gè)時(shí)候我們突然發(fā)現(xiàn)我們的一個(gè)WordPress的演示網(wǎng)站的錯(cuò)誤日志比我們另外的運(yùn)營狀態(tài)的正式網(wǎng)站還要多，當(dāng)然的錯(cuò)誤日志體積達(dá)到數(shù)百M(fèi)B，這個(gè)時(shí)候我們意識(shí)到了問題的所在。不是有人想要攻擊我們的服務(wù)器、也不是我們的網(wǎng)站程序出現(xiàn)故障了、更不是我們的服務(wù)器配置錯(cuò)誤了;原因就是這些發(fā)廣告的機(jī)器，做互聯(lián)網(wǎng)的都知道現(xiàn)在這種垃圾廣告發(fā)布機(jī)到處都是。然后我查詢了數(shù)據(jù)的大小，發(fā)現(xiàn)這個(gè)演示站的評論數(shù)據(jù)表高達(dá)500MB，里面的記錄數(shù)達(dá)到了30萬條，而且都是這兩天產(chǎn)生的，而且相應(yīng)的用戶表記錄數(shù)也很多。

因此到這里就徹底找到了問題的所在，那就是垃圾廣告信息的瘋狂發(fā)布，除了給網(wǎng)站帶來較高的訪問壓力外，在發(fā)布廣告的過程中廣告發(fā)布軟件可能錯(cuò)誤訪問網(wǎng)站于是產(chǎn)生大量的錯(cuò)誤日志，也就是說WEB服務(wù)器Apache在承受正常訪問外還需要不斷地寫錯(cuò)誤日志，于是就需要消耗大量的CPU資源，因此就造成了服務(wù)器CPU資源爆滿，網(wǎng)站卡殼。

而只要找到問題后解決起來就比較簡單了，那就是去掉那個(gè)演示站，或者給那個(gè)演示站設(shè)置相應(yīng)的權(quán)限，減少垃圾信息的發(fā)布;這樣CPU的使用率馬上下降到20%以下恢復(fù)到正常水平。

這樣不得不贊以下西部數(shù)碼云服務(wù)器，因?yàn)樵谶@樣的情況下只是服務(wù)器變慢，而不是直接宕機(jī)，這也是我做西部數(shù)碼代理這么久第一次最真切地感受到產(chǎn)品的品質(zhì)。另外也吐槽下互聯(lián)網(wǎng)上的網(wǎng)站，簡直是抄襲成風(fēng)。比如搜索解決Apache的httpd.exe進(jìn)程占用CPU過高后出現(xiàn)的文章內(nèi)容就是那幾種，而且每一種可能被數(shù)千個(gè)網(wǎng)站聲稱為自己原創(chuàng)。

所以這里也提醒大家，網(wǎng)上的資料僅供參考，最終還是需要自己去思考總結(jié)，這樣會(huì)有更多的收獲。

更多信息請查看IT技術(shù)專欄