前幾天有朋友向我們反饋說打開我們的網(wǎng)站特別慢，而他是想讓我們幫他做網(wǎng)站并提供網(wǎng)站運維服務(wù)的，這樣的反饋對我們而言確實不是什么好事情，我開始的反應(yīng)就是認為他是第一次打開我們的網(wǎng)所以這么慢，而我這里因為經(jīng)常打開自己的網(wǎng)站所以感受不到有多慢。然后我ctrl+F5一看果然比蝸牛還慢，我此刻意識到問題的重要性了。

　　憑借我對這些問題的直覺，首先就是意識到服務(wù)器出故障了，因為我們的網(wǎng)站流量不可能就在這幾天內(nèi)增加多少，也不可能是因為我們程序有諸如死循環(huán)的故障。那個時候我感覺很無奈，因為在我之前在網(wǎng)上看到的那些解決方案針對的問題我們自己的這個并不會出現(xiàn)，比如我們一直沒有修改網(wǎng)站程序所以不太可能造成網(wǎng)站程序上的錯誤，也一直沒有更改服務(wù)器的配置搜易也不太可能是WEB服務(wù)器配置的故障。

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

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

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

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

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

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

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

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