正在趕寫演講的ppt，突然聽到短信想起，沒理會，以為是廣告呢。剛放下念頭，短信接連不斷的響起來，不用想，準(zhǔn)是哪個服務(wù)器報警了。

打開nagios監(jiān)控見面，發(fā)現(xiàn)3個服務(wù)器（3個服務(wù)器處于同一個集群下，業(yè)務(wù)為論壇，同時在線人數(shù)大概4萬人）的load過高，處于warning狀態(tài)

1、 先查看訪問流量，通過對比，跟以前沒什么差別。

2、 查看每個服務(wù)器的進程數(shù)和cpu使用情況，跟以前也沒什么差別。

3、 查看系統(tǒng)日志，每個服務(wù)器都有“TCP: Treason uncloaked! Peer 113.247.241.146:21345/80 shrinks window 2128147967:2128149427. Repaired.”

4、 查看php日志，大量“[WARNING] fpm_request_check_timed_out(), line 158: child 25379, script '/mnt/html/bbs/forum.php' (pool default) execution timed out (120.306361 sec), terminating”。打開論壇首頁，居然花了120多秒。我在php配置文件里設(shè)置的執(zhí)行中斷時間是120秒，超過這個值則關(guān)閉該子進程?？磥響?yīng)該從這里下手了。

先問問其他人，最近有沒有改程序，有沒有加插件？答：“沒有”。我再仔細(xì)檢查了系統(tǒng)：

（1）       查看有沒有文件系統(tǒng)損壞而不能寫入

（2）       查看分區(qū)是否滿（實際上滿了的話，有短信報警的）

（3）       查看tcp連接狀態(tài)，還沒以前多呢，看來不是系統(tǒng)的問題

那么，與之有關(guān)聯(lián)的還有數(shù)據(jù)庫、nfs文件系統(tǒng)以及memchached。先檢查容易的，好！先檢查nfs，正常；再檢查memcached，正常。看來估計數(shù)據(jù)庫有什么問題了。

登錄數(shù)據(jù)庫，先查看數(shù)據(jù)庫錯誤日志，tail –f 一下，滾動輸出，看來問題找到了。輸入的內(nèi)容主要有一下幾行：

接下來，從處理表滿開始，把它的行數(shù)值設(shè)置巨大一點，我設(shè)置的是1000萬，指令為：mysql>ALTER TABLE pre_common_session MAX_ROWS=10000000; 完畢后3個web服務(wù)器的負(fù)載馬上就下降了。從報錯信息中，可以判斷有2個表可能損壞了。檢查一下，如果真壞了，就修復(fù)一下吧!

（1）檢查第一個表：mysql> check table cdb_uc_notelist;輸出為

+---------------------------+-------+----------+-----------------------------------------------------------+
| Table                     | Op    | Msg_type | Msg_text                                                  |
+---------------------------+-------+----------+-----------------------------------------------------------+
| uc_mumayi.cdb_uc_notelist | check | warning | 11 clients are using or haven't closed the table properly |
| uc_mumayi.cdb_uc_notelist | check | warning | Size of datafile is: 260372       Should be: 259760       |
| uc_mumayi.cdb_uc_notelist | check | error    | Wrong bytesec: 101-114-110 at linkstart: 258412           |
| uc_mumayi.cdb_uc_notelist | check | error    | Corrupt                                                   |
+---------------------------+-------+----------+-----------------------------------------------------------+
4 rows in set (0.04 sec)

真損壞了，修復(fù)一把：

mysql> repair table cdb_uc_notelist; 

輸出為

+---------------------------+--------+----------+-----------------------------------------------+
| Table                     | Op     | Msg_type | Msg_text                                      |
+---------------------------+--------+----------+-----------------------------------------------+
| uc_mumayi.cdb_uc_notelist | repair | info     | Wrong bytesec: 101-114-110 at 258412; Skipped |
| uc_mumayi.cdb_uc_notelist | repair | warning | Number of rows changed from 5715 to 5742      |
| uc_mumayi.cdb_uc_notelist | repair | status   | OK                                            |
+---------------------------+--------+----------+-----------------------------------------------+

（2）修復(fù)第2個表，方法同上。

（3）再次檢查表狀態(tài)。

（4）讓管理員從后臺登錄，查看是否正常。

原文：http://b.formyz.org/2011/1124/53.html

【編輯推薦】

1. 如何配置Web服務(wù)器實現(xiàn)負(fù)載均衡？
2. 軟件級負(fù)載均衡器(LVS/HAProxy/Nginx)的特點和對比
3. CPU 負(fù)載過高的故障