《告警：IO利用率飚至60%+，請及時(shí)排查優(yōu)化！》要點(diǎn)：
本文介紹了告警：IO利用率飚至60%+，請及時(shí)排查優(yōu)化！，希望對您有用。如果有疑問，可以聯(lián)系我們。

導(dǎo)讀：通常引起IO升高的因素很多,比如高并發(fā)或大字段寫入、硬盤老化有壞塊、Raid卡電池?fù)p壞或充放電、硬件自檢等都會(huì)引起IO升高.本文主要對硬件自檢導(dǎo)致的IO問題排查做簡要說明.

現(xiàn)象

監(jiān)控報(bào)警,IO最大利用率達(dá)60%+,應(yīng)用TP99超時(shí),成功率降低,如下為當(dāng)時(shí)監(jiān)控圖：

遇到此問題的排查方向

第一, 定時(shí)任務(wù)導(dǎo)致.
先看時(shí)間,是否為定時(shí)任務(wù)導(dǎo)致,比如備份.如果binlog之前生成較多,過期后自動(dòng)清理也會(huì)導(dǎo)致IO升高,可以通過磁盤空間監(jiān)控查看.

第二,并發(fā)較大寫磁盤頻繁.
一般此問題不會(huì)造成IO util 50%以上.如果事物較大或者并發(fā)較大,general log或slow log會(huì)有記錄,我們可以先看下當(dāng)前線程連接情況,再結(jié)合general log或slow log查看是哪些SQL導(dǎo)致.是否需要優(yōu)化SQL還是控制并發(fā),以及調(diào)整數(shù)據(jù)庫刷新頻率置成雙0模式.

第三,硬件因素導(dǎo)致.
IO util 50%以上,很大幾率是硬件問題導(dǎo)致,磁盤是否有壞塊.最常見的就是Raid卡電池?fù)p壞(充放電),如果電池?fù)p壞沒有開啟寫緩存,則會(huì)直接寫磁盤,IO會(huì)升高.我們可以通過如下命令檢查,除HP服務(wù)器外其他采用MegaCli查看硬件信息,HP采用自帶hpssacli命令查看,切記不要使用老命令hpacucli,此命令會(huì)導(dǎo)致部分HP型號服務(wù)器操作系統(tǒng)直接Hang.

服務(wù)器大多是LSI的MegaRAID卡,MegaCli兼容服務(wù)器命令

查看磁盤壞塊：
MegaCli64 -PDList –aALL|egrep –I ‘error|Firmware’

查看緩存策略：
/opt/MegaRAID/MegaCli/MegaCli64 -cfgdsply -aALL |grep Policy
Default Cache Policy: WriteBack, ReadAhead, Direct, No Write Cache if Bad BBU
Current Cache Policy: WriteBack, ReadAhead, Direct, No Write Cache if Bad BBU
Access Policy : Read/Write
Disk Cache Policy : Disk’s Default

此種狀態(tài)為BBU損壞時(shí)不寫Raid卡緩存

修改為BBU損壞時(shí)寫Raid卡緩存：
/opt/MegaRAID/MegaCli/MegaCli64 -LDSetProp CachedBadBBU -Lall -aALL
Default Cache Policy: WriteBack, ReadAhead, Direct, Write Cache OK if Bad BBU
Current Cache Policy: WriteBack, ReadAhead, Direct, Write Cache OK if Bad BBU
Access Policy : Read/Write
Disk Cache Policy : Disk’s Default

生成自檢及電池充放電日志：
/opt/MegaRAID/MegaCli/MegaCli64 -AdpEventLog -GetEvents -aALL -f 1.log
/opt/MegaRAID/MegaCli/MegaCli64 -FwTermLog -Dsply -f 2.log -aALL

打開物理磁盤緩存：
/opt/MegaRAID/MegaCli/MegaCli64 -LDGetProp -DskCache -LALL -aALL
Adapter 0-VD 0(target id: 0): Disk Write Cache : Enabled

HP服務(wù)器hpssacli命令

HP查看電池狀態(tài)：
hpssacli ctrl all show status

HP查看緩存策略：
hpssacli ctrl all show detail|grep -i Cache

查看插槽號和邏輯磁盤號：
hpssacli ctrl all show config detail|egrep -i ‘Logical Drive:|slot:’

打開物理磁盤緩存：
hpssacli ctrl slot=0 modify drivewritecache=enable

查看陣列號及SSDSmartPath：
hpssacli ctrl all show config detail|egrep -i ‘Array:|HP SSD Smart Path’

SSD需要注意：(打開邏輯緩存需要先關(guān)閉SSD Smart Path功能)
hpssacli ctrl slot=0 array A modify ssdsmartpath=disable

打開邏輯磁盤緩存：
hpssacli ctrl slot=0 logicaldrive 1 modify caching=enable

在沒有電池的情況下開啟raid寫緩存：
hpssacli ctrl slot=0 modify nobatterywritecache=enable

設(shè)置讀寫百分比：
hpssacli ctrl slot=0 modify cacheratIO=10/90

了解以上服務(wù)器命令后,分析三種情況：

• 情況一：無Raid卡電池(損壞)

查看Raid卡電池狀態(tài)：
/opt/MegaRAID/MegaCli/MegaCli64 -AdpBbuCmd -GetBbuStatus -aALL
Adapter 0: Get BBU Status Failed.
FW error descriptIOn:
The required hardware component is not present.
hpssacli ctrl all show status
Controller Status: OK
Cache Status: OK
Battery/Capacitor Status: Failed

這種情況,如果沒有修改默認(rèn)WriteCache OK if Bad BBU模式或者No-Battery Write Cache: Enabled,在電池?fù)p壞時(shí)會(huì)轉(zhuǎn)換成WT模式.從而導(dǎo)致IO非常高.

/opt/MegaRAID/MegaCli/MegaCli64 -cfgdsply -aALL |grep Policy
Default Cache Policy: WriteBack, ReadAdaptive, Direct, No Write Cache if Bad BBU
Current Cache Policy: WriteThrough, ReadAdaptive, Direct, No Write Cache if Bad BBU

修改成WC模式后,IO使用率可以從99.6%降到2%左右,效果十分顯著.

但這種情況下存在一個(gè)問題：因?yàn)闆]有Raid卡電池保護(hù),即突然斷電或者主板故障時(shí)會(huì)造成數(shù)據(jù)丟失風(fēng)險(xiǎn).數(shù)據(jù)庫服務(wù)器一般采用雙電模式,掉電風(fēng)險(xiǎn)較低,但是主板故障相對較高,所以BBU壞時(shí)是否要打開Write Cache,需要根據(jù)業(yè)務(wù)情況綜合取舍.

• 情況二：Raid卡電池處于充放電階段

首先我們先了解BBU充放電原理：
BBU由鋰離子電池和電子控制電路組成.鋰離子電池的壽命取決于其老化程度,從出廠之后,無論它是否被充電及它的充放電次數(shù)多與少,鋰離子電池的容量將慢慢的減少.這意味著一個(gè)老電池?zé)o法像新電池那么持久.也就決定了BBU的相對充電狀態(tài)(Relative State of Charge)不會(huì)等于絕對充電狀態(tài)(Absolute State of Charge).

為了記錄電池的放電曲線,以便控制器了解電池的狀態(tài),例如最大和最小電壓等,同時(shí)為了延長電池的壽命,默認(rèn)會(huì)啟用自動(dòng)校準(zhǔn)模式(AutoLearn Mode).在learn cycle期間,Raid卡控制器不會(huì)啟用BBU直到它完成校準(zhǔn).整個(gè)過程大概1小時(shí)左右.這個(gè)過程中,會(huì)禁用WriteBack模式,以保證數(shù)據(jù)完整性,同時(shí)會(huì)造成性能的降低.

整個(gè)Learn Cycle分為三個(gè)步驟：

1. 控制器把BBU電池充滿電(該步驟可能是放電后充電或直接充電,如果電池剛好滿電,則直接進(jìn)入第二階段)；
2. 開始校準(zhǔn), 對BBU電池執(zhí)行放電；
3. 放電完成后,完成校準(zhǔn),并重新開始充電,直接達(dá)到最大電量,整個(gè)Learn Cycle才算完成 .

注意：如果第二或第三階段被中斷,重新校準(zhǔn)的任務(wù)會(huì)停止,而不會(huì)重新執(zhí)行.

再來說超級電容：
超級電容優(yōu)于鋰電池,采用電容+Flash子板的方式來將非正常掉電后的臟數(shù)據(jù)刷入Flash中永久保存.超級電容在50℃環(huán)境下可以使用5年,而且故障率低,不用例行充放電.目前大部分raid卡廠商也轉(zhuǎn)向使用超級電容+Flash的備電方案.

采用MegaCli方式查看電池充放電周期：
/opt/MegaRAID/MegaCli/MegaCli64 -AdpBbuCmd -GetBbuProperties -aALL
BBU Properties for Adapter: 0
Auto Learn PerIOd: 90 Days
Next Learn time: Mar 4 2017 11:04:46
Learn Delay Interval:0 Hours
Auto-Learn Mode: Transparent

查看充電狀態(tài)：
/opt/MegaRAID/MegaCli/MegaCli64 -AdpBbuCmd -GetBbuStatus -aALL |grep “Charge”
Relative State of Charge: 50 %
Charger Status: Recharging
Full Charge Capacity: 509 mAh

HP查看電容狀態(tài)：
hpssacli ctrl all show status
Smart Array P440ar in Slot 0 (Embedded)
Controller Status: OK
Cache Status: OK
Battery/Capacitor Status: OK

惠普服務(wù)器為何沒有同類問題?
目前服務(wù)器除了HP服務(wù)器Raid卡采用鎳氫電池、超級電容外,大部分服務(wù)器Raid卡還都采用的是鋰電池.
鎳氫電池、超級電容,它沒有惰性,并且特性和鋰電池不同,它并不需要通過完全放電來校準(zhǔn)電量.
當(dāng)鎳氫電池由于自放電而導(dǎo)致電量降低時(shí)到一定程度時(shí)(比如80%),陣列卡控制器會(huì)感知到這一信息并對電池進(jìn)行娟流充電以補(bǔ)充失去的電量,整個(gè)過程對用戶是透明的,也不需要關(guān)閉緩存,因此并不會(huì)影響IO性能.

各品牌服務(wù)器充放電周期：

產(chǎn)品類型	默認(rèn)周期
DELL	90天
ThinkServer	28天
IBM	30天
RH(華為)	27天
HP	電容不進(jìn)行例行充放電

所以,Raid卡電池充放電階段,會(huì)禁用WriteBack模式,以保證數(shù)據(jù)完整性,同時(shí)會(huì)造成性能的降低.

通過下面命令生成日志,可以查看充放電詳細(xì)信息：
/opt/MegaRAID/MegaCli/MegaCli64 -FwTermLog -Dsply -f log.txt -aALL

• 情況三：服務(wù)器硬件自檢

除了Raid卡電池外,還有一個(gè)影響IO的重要因素那就是硬件自檢.回到文章前面提到的監(jiān)控圖,同一業(yè)務(wù)的8臺服務(wù)器于11月12日凌晨3:00開始IO開始升高,4:00左右達(dá)到最高峰IO利用率達(dá)70%左右,之后開始下降直至平穩(wěn)正常.此系統(tǒng)已經(jīng)平穩(wěn)運(yùn)行了很長時(shí)間,并沒有做什么上線操作.

因?yàn)槭橇璩?:00出現(xiàn),而且備份正好是凌晨3:00開始,首先想到可能是備份導(dǎo)致的IO上升,但是登上服務(wù)器檢查發(fā)現(xiàn)這幾組機(jī)器并沒有部署備份.

那么接下來可能會(huì)認(rèn)為這段時(shí)間事物量較大,通過監(jiān)控發(fā)現(xiàn)這個(gè)時(shí)間段并沒有大量并發(fā),而且此時(shí)間段為業(yè)務(wù)低峰期,相對訪問操作較少.

開始著手分析硬件,懷疑為Raid卡電池導(dǎo)致,通過命令生成硬件自檢及raid卡電池充放電日志1.log和2.log,部分日志內(nèi)容如下：

/opt/MegaRAID/MegaCli/MegaCli64 -AdpEventLog -GetEvents -aALL -f 1.log
Event DescriptIOn: Patrol Read started
Event DescriptIOn: Consistency Check started on VD 00/0
Event DescriptIOn: Patrol Read aborted on PD 1f(e0x00/s5)
Event DescriptIOn: Patrol Read aborted on PD 20(e0x00/s1)
Event DescriptIOn: Patrol Read aborted on PD 21(e0x00/s10)
Event DescriptIOn: Patrol Read aborted on PD 1e(e0x00/s3)
Event DescriptIOn: Patrol Read aborted on PD 25(e0x00/s0)
Event DescriptIOn: Patrol Read aborted on PD 22(e0x00/s2)
Event DescriptIOn: Patrol Read aborted on PD 23(e0x00/s8)
Event DescriptIOn: Patrol Read aborted on PD 26(e0x00/s6)
Event DescriptIOn: Patrol Read aborted on PD 27(e0x00/s7)
Event DescriptIOn: Patrol Read aborted on PD 24(e0x00/s4)
Event DescriptIOn: Patrol Read aborted on PD 29(e0x00/s11)
Event DescriptIOn: Patrol Read aborted on PD 28(e0x00/s9)
Event DescriptIOn: Consistency Check done on VD 00/0
/opt/MegaRAID/MegaCli/MegaCli64 -FwTermLog -Dsply -aALL -f 2.log

通過分析日志發(fā)現(xiàn),此時(shí)Raid卡電池運(yùn)行正常,也沒有進(jìn)行充放電.而是系統(tǒng)進(jìn)行了硬件自檢,時(shí)間是每周六凌晨3:00開始.而且這幾臺為同一批機(jī)器,再查看更久的監(jiān)控,發(fā)現(xiàn)每周六凌晨3:00 都會(huì)出現(xiàn)IO較高現(xiàn)象.自檢期間IO消耗比較大,如果期間有事物處理,會(huì)出現(xiàn)慢SQL、超時(shí)等現(xiàn)象,導(dǎo)致TP99報(bào)警.

問題原因找到了,該如何優(yōu)化?

如果調(diào)整的話需進(jìn)入BIOs修改,因?yàn)榉?wù)器產(chǎn)品不同,修改方法可能不一樣.

以DELL、ThinkServer為例：

通過ILO F1進(jìn)入BIOS,首先需要把BIOS的Legacy修改成UEFI模式：

1. 進(jìn)入boot manage修改 boot mode為UEFI Only
2. 進(jìn)入Miscellaneous Boot Settings修改Storage OpROM Policy為UEFI Only
3. F10保存后重啟再進(jìn)入Boot manage里面可以看到Adapters and UEFI Drivers 選項(xiàng)
4. 依次進(jìn)入Controller Management—>Asvanced Controller Management—>Schedule Consistency Check即可看到一致性檢查項(xiàng)：

1. 修改后,選擇Apply Changes,務(wù)必執(zhí)行這一步,選擇應(yīng)用生效
2. 再把前面的UEFI修改回Legacy模式,否則無法進(jìn)入操作系統(tǒng),重啟即可
3. 調(diào)整后,結(jié)合監(jiān)控和日志檢查,沒有再出現(xiàn)凌晨3:00 IO升高現(xiàn)象
4. 這里的Monthly指的是30天,而不是正常月,所以日期還是不固定9) 調(diào)整觀察一段時(shí)間后,每周六的IO升高現(xiàn)象不再出現(xiàn),不建議關(guān)閉此功能

總結(jié)

杜絕以上問題,需要從服務(wù)器初始化就做好：

1.調(diào)整硬件一致性自檢策略,由每周調(diào)整為每月,并根據(jù)業(yè)務(wù)情況修改日期.但有一點(diǎn)需要注意,這里的月指的是固定30天,即使調(diào)整日期以后還是會(huì)錯(cuò)亂.不知道服務(wù)器廠商以后是否會(huì)修改.

2.針對電商來說,618和雙11是最大的兩個(gè)大促,日期相對固定,所以在大促前最好計(jì)算一下,是否會(huì)趕上,提前做好調(diào)整,相對影響更小、更安全.

3.修改Raid卡緩存策略

WriteBack,ReadAdaptive,Direct,Write Cache if Bad BBU模式：
此模式下存在在BBU有問題時(shí)(如電池失效)期間,突然斷電或者主板故障都會(huì)導(dǎo)致數(shù)據(jù)丟失風(fēng)險(xiǎn).

WriteBack,ReadAdaptive,Direct,No Write Cache if Bad BBU模式：
在BBU有問題時(shí), 不使用Write Cache.但是可能發(fā)生Write Cache策略變更的情況(由WriteBack變成WriteThrough),導(dǎo)致IO性能急劇下降.

所以,修改成哪種模式需要結(jié)合實(shí)際業(yè)務(wù)來定,建議無論是否有raid卡電池都改成WriteBack,ReadAdaptive,Direct,Write Cache if Bad BBU模式.

4.不建議關(guān)閉硬件自檢,可以適當(dāng)延長自檢周期,通過自檢可以及時(shí)發(fā)現(xiàn)硬件問題,監(jiān)控更及時(shí).

5.不建議關(guān)閉Raid卡電池Auto Learn模式,通過這個(gè)校準(zhǔn),能延長電池壽命,不作電池校準(zhǔn)的Raid卡,電池壽命將從正常的2年降為8個(gè)月.

6.另外mysql innodb_flush_method建議設(shè)成O_DIRECT模式：數(shù)據(jù)文件的寫入操作是直接從mysql innodb buffer到磁盤(raid卡緩存)的,并不用通過OS緩沖,而真正的完成也是在flush這步,日志還是要經(jīng)過OS緩存.

innodb_flush_log_at_trx_commit、sync_binlog改成0模式也會(huì)提升IO性能,但數(shù)據(jù)安全性會(huì)大打折扣,所以不到萬不得已建議不要調(diào)成雙0.

HP官方工具集：

http://h20564.www2.hpe.com/hpsc/doc/public/display?docId=c03909334
http://h20564.www2.hpe.com/hpsc/swd/public/detail?sp4ts.oid=7252838&swItemId=MTX_38896e67ccde4fc8a752a3f0a6&swEnvOid=4124#tab3

文章原文來自微信公眾號：IPCHAT

轉(zhuǎn)載請注明本頁網(wǎng)址：
http://www.fzlkiss.com/jiaocheng/4291.html