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

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

　　OS ：solaris 10

　　DBMS:Oracle 10.2.0.3.0

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

　　先出個awr 報告

　　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個50m的在線日志組。明顯不合理先

　　增加5個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;

　　觀察問題仍然存在。

　　比較幸運的是找到了一個前個月的awr 報告，一比較負(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

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

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

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

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

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

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

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

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

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

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