服務(wù)器負(fù)載暴漲之后怎么辦?
正在趕寫(xiě)演講的ppt,突然聽(tīng)到短信想起,沒(méi)理會(huì),以為是廣告呢。剛放下念頭,短信接連不斷的響起來(lái),不用想,準(zhǔn)是哪個(gè)服務(wù)器報(bào)警了。
打開(kāi)nagios監(jiān)控見(jiàn)面,發(fā)現(xiàn)3個(gè)服務(wù)器(3個(gè)服務(wù)器處于同一個(gè)集群下,業(yè)務(wù)為論壇,同時(shí)在線(xiàn)人數(shù)大概4萬(wàn)人)的load過(guò)高,處于warning狀態(tài)
1、 先查看訪問(wèn)流量,通過(guò)對(duì)比,跟以前沒(méi)什么差別。
2、 查看每個(gè)服務(wù)器的進(jìn)程數(shù)和cpu使用情況,跟以前也沒(méi)什么差別。
3、 查看系統(tǒng)日志,每個(gè)服務(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”。打開(kāi)論壇首頁(yè),居然花了120多秒。我在php配置文件里設(shè)置的執(zhí)行中斷時(shí)間是120秒,超過(guò)這個(gè)值則關(guān)閉該子進(jìn)程??磥?lái)應(yīng)該從這里下手了。
先問(wèn)問(wèn)其他人,最近有沒(méi)有改程序,有沒(méi)有加插件?答:“沒(méi)有”。我再仔細(xì)檢查了系統(tǒng):
(1) 查看有沒(méi)有文件系統(tǒng)損壞而不能寫(xiě)入
(2) 查看分區(qū)是否滿(mǎn)(實(shí)際上滿(mǎn)了的話(huà),有短信報(bào)警的)
(3) 查看tcp連接狀態(tài),還沒(méi)以前多呢,看來(lái)不是系統(tǒng)的問(wèn)題
那么,與之有關(guān)聯(lián)的還有數(shù)據(jù)庫(kù)、nfs文件系統(tǒng)以及memchached。先檢查容易的,好!先檢查nfs,正常;再檢查memcached,正常。看來(lái)估計(jì)數(shù)據(jù)庫(kù)有什么問(wèn)題了。
登錄數(shù)據(jù)庫(kù),先查看數(shù)據(jù)庫(kù)錯(cuò)誤日志,tail –f 一下,滾動(dòng)輸出,看來(lái)問(wèn)題找到了。輸入的內(nèi)容主要有一下幾行:
| 
             [ERROR] Got error 134 when reading table './uc_mumayi/cdb_uc_members' [ERROR] Got error 134 when reading table './uc_mumayi_net/cdb_uc_members' [ERROR] /usr/local/mysql/libexec/mysqld: The table 'pre_common_session' is full  | 
        
接下來(lái),從處理表滿(mǎn)開(kāi)始,把它的行數(shù)值設(shè)置巨大一點(diǎn),我設(shè)置的是1000萬(wàn),指令為:mysql>ALTER TABLE pre_common_session MAX_ROWS=10000000; 完畢后3個(gè)web服務(wù)器的負(fù)載馬上就下降了。從報(bào)錯(cuò)信息中,可以判斷有2個(gè)表可能損壞了。檢查一下,如果真壞了,就修復(fù)一下吧!
(1)檢查第一個(gè)表: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個(gè)表,方法同上。
(3)再次檢查表狀態(tài)。
(4)讓管理員從后臺(tái)登錄,查看是否正常。
原文:http://b.formyz.org/2011/1124/53.html
【編輯推薦】















 
 
 






 
 
 
 