有時(shí)Linux磁盤(pán)碎片多，甚至出現(xiàn)故障，都會(huì)導(dǎo)致系統(tǒng)運(yùn)行緩慢，這是不少用戶都遇到過(guò)的事情了，那么遇到這種問(wèn)題應(yīng)該如何處理呢?下面小編就給大家介紹下Linux磁盤(pán)故障導(dǎo)致系統(tǒng)運(yùn)行變慢的解決方法。

　　Linux磁盤(pán)故障導(dǎo)致系統(tǒng)運(yùn)行緩慢的解決方法

　　OS ：solaris 10

　　DBMS:Oracle 10.2.0.3.0

　　Canada 某運(yùn)營(yíng)商報(bào)系統(tǒng)運(yùn)行變的異常慢，造成數(shù)據(jù)積壓。

　　先出個(gè)awr 報(bào)告

　　log file sync 45，755 33，981 743 59.7 Commit

　　CPU time 14，009 24.6

　　db file parallel write 63，119 11，374 180 20.0 System I/O

　　db file sequential read 736，650 3，692 5 6.5 User I/O

　　log file parallel write 9，148 3，081 337 5.4 System I/O

　　絕大部分為IO引起的。

　　先檢查 log日志情況

　　select * from v$logfile;

　　有64個(gè)50m的在線日志組。明顯不合理先

　　增加5個(gè)2g 的日志組\

　　alter databae add logfile group 66 ‘/filepath/redolog66.log’ size 2g;

　　。

　　alter database drop logfile group 1;

　　alter database drop logfile group 2;

　　。。

　　alter database drop logfile group 64;

　　alter database drop logfile group 65;

　　觀察問(wèn)題仍然存在。

　　比較幸運(yùn)的是找到了一個(gè)前個(gè)月的awr 報(bào)告，一比較負(fù)載遠(yuǎn)不如從前。

　　觀察系統(tǒng)IO情況

　　device r/s w/s kr/s kw/s wait actv svc_t %w %b

　　md0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0

　　md1 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0

　　md3 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0

　　md5 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0

　　md10 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0

　　md11 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0

　　md13 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0

　　md15 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0

　　md20 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0

　　md21 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0

　　md23 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0

　　md25 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0

　　sd0 0.0 0.2 0.0 0.1 0.0 0.0 3.9 0 0

　　sd1 0.0 0.2 0.0 0.1 0.0 0.0 4.2 0 0

　　sd2 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0

　　sd3 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0

　　sd4 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0

　　ssd5 13.0 106.0 126.4 847.7 0.0 1.8 15.4 0 100

　　ssd6 0.0 3.4 0.0 1.8 0.0 0.1 34.0 0 2

　　ssd7 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0

　　ssd8 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0

　　ssd9 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0

　　nfs1 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0

　　每秒的寫(xiě)出只有840k左右，這遠(yuǎn)不是一磁陣的應(yīng)有的性能表現(xiàn)

　　但是cp 一個(gè)大文件性能和讀的性能卻還可以。通知前線同事先檢查一下設(shè)備情況

　　磁陣的cache 特性，我會(huì)在其它的日志介紹。

　　反饋是cache 的電池已過(guò)期，cache 禁用。協(xié)調(diào)更換電池。

　　相關(guān)閱讀：系統(tǒng)變得很慢原因分析

　　第一步：登錄后臺(tái)服務(wù)器/監(jiān)控平臺(tái)，查看系統(tǒng)資源是否達(dá)到上限，例如：CPU、內(nèi)存、磁盤(pán)、I/O、網(wǎng)絡(luò)帶寬等，如果是這些問(wèn)題，先將這些問(wèn)題逐一解決：

　　如果是CPU的問(wèn)題，則需要查看一下CPU占比比較高的進(jìn)程，然后使用jstack命令生成進(jìn)程的堆棧信息，看是否發(fā)生頻繁Full GC，如果是的話，還需要看一下內(nèi)存快照，分析一下內(nèi)存情況(可以使用java自帶的或第三方工具);如果是磁盤(pán)空間滿了，及時(shí)清理磁盤(pán);如果是帶寬滿了，聯(lián)系網(wǎng)絡(luò)工程師解決。如果以上這些問(wèn)題都沒(méi)有，則進(jìn)行第二步。

　　第二步：檢查應(yīng)用服務(wù)器(Jboss/Tomcat)的線程池配置是否合理，看一下請(qǐng)求的排隊(duì)現(xiàn)象是否嚴(yán)重，如果嚴(yán)重則需要重新設(shè)置合理的線程池。同樣，檢查一下數(shù)據(jù)庫(kù)的連接池設(shè)置是否合理，增大連接池設(shè)置，同時(shí)檢查一下是否有慢sql，如果有慢sql，則進(jìn)行優(yōu)化(優(yōu)化方案是查看執(zhí)行計(jì)劃，設(shè)置合理的索引等)。

　　第三步：查看訪問(wèn)慢的服務(wù)的調(diào)用鏈，查看一下調(diào)用鏈中的每一步響應(yīng)時(shí)間是否合理，如果不合理，則聯(lián)系相關(guān)系統(tǒng)的負(fù)責(zé)人進(jìn)行排查和解決。

　　第四步：檢查web服務(wù)器的請(qǐng)求日志，看一下是否存在Doss攻擊，如果有Doss攻擊，則將攻擊者的IP添加到防火墻的黑名單里。