導讀：通常引起IO升高的因素很多，比如高併發或大欄位寫入、硬碟老化有壞塊、Raid卡電池損壞或充放電、硬體自檢等都會引起IO升高。本文主要對硬體自檢導致的IO問題排查做簡要說明。

現象

監控報警，IO最大利用率達60%+，應用TP99超時，成功率降低，如下為當時監控圖：

遇到此問題的排查方向

第一， 定時任務導致。
先看時間，是否為定時任務導致，比如備份。如果binlog之前生成較多，過期後自動清理也會導致IO升高，可以通過磁碟空間監控檢視。

第二，併發較大寫磁碟頻繁。
一般此問題不會造成IO util 50%以上。如果事物較大或者併發較大，general log或slow log會有記錄，我們可以先看下當前執行緒連線情況，再結合general log或slow log檢視是哪些SQL導致。是否需要優化SQL還是控制併發，以及調整資料庫重新整理頻率置成雙0模式。

第三，硬體因素導致。
IO util 50%以上，很大機率是硬體問題導致，磁碟是否有壞塊。最常見的就是Raid卡電池損壞（充放電），如果電池損壞沒有開啟寫快取，則會直接寫磁碟，IO會升高。我們可以通過如下命令檢查，除HP伺服器外其他採用MegaCli檢視硬體資訊，HP採用自帶hpssacli命令檢視，切記不要使用老命令hpacucli，此命令會導致部分HP型號伺服器作業系統直接Hang。

伺服器大多是LSI的MegaRAID卡，MegaCli相容伺服器命令

檢視磁碟壞塊：
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

此種狀態為BBU損壞時不寫Raid卡快取

修改為BBU損壞時寫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伺服器hpssacli命令

HP檢視電池狀態：
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需要注意：（開啟邏輯快取需要先關閉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

設定讀寫百分比：
hpssacli ctrl slot=0 modify cacheratIO=10/90

瞭解以上伺服器命令後，分析三種情況：

• 情況一：無Raid卡電池（損壞）

檢視Raid卡電池狀態：
/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

這種情況，如果沒有修改預設WriteCache OK if Bad BBU模式或者No-Battery Write Cache: Enabled，在電池損壞時會轉換成WT模式。從而導致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%左右，效果十分顯著。

但這種情況下存在一個問題：因為沒有Raid卡電池保護，即突然斷電或者主機板故障時會造成資料丟失風險。資料庫伺服器一般採用雙電模式，掉電風險較低，但是主機板故障相對較高，所以BBU壞時是否要開啟Write Cache，需要根據業務情況綜合取捨。

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

首先我們先了解BBU充放電原理：
BBU由鋰離子電池和電子控制電路組成。鋰離子電池的壽命取決於其老化程度，從出廠之後，無論它是否被充電及它的充放電次數多與少，鋰離子電池的容量將慢慢的減少。這意味著一個老電池無法像新電池那麼持久。也就決定了BBU的相對充電狀態(Relative State of Charge)不會等於絕對充電狀態(Absolute State of Charge)。

為了記錄電池的放電曲線，以便控制器瞭解電池的狀態，例如最大和最小電壓等，同時為了延長電池的壽命，預設會啟用自動校準模式(AutoLearn Mode)。在learn cycle期間，Raid卡控制器不會啟用BBU直到它完成校準。整個過程大概1小時左右。這個過程中，會禁用WriteBack模式，以保證資料完整性，同時會造成效能的降低。

整個Learn Cycle分為三個步驟：

1. 控制器把BBU電池充滿電(該步驟可能是放電後充電或直接充電，如果電池剛好滿電，則直接進入第二階段)；
2. 開始校準, 對BBU電池執行放電；
3. 放電完成後，完成校準，並重新開始充電，直接達到最大電量，整個Learn Cycle才算完成 。

注意：如果第二或第三階段被中斷，重新校準的任務會停止，而不會重新執行。

再來說超級電容：
超級電容優於鋰電池，採用電容+Flash子板的方式來將非正常掉電後的髒資料刷入Flash中永久儲存。超級電容在50℃環境下可以使用5年，而且故障率低，不用例行充放電。目前大部分raid卡廠商也轉向使用超級電容+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

檢視充電狀態：
/opt/MegaRAID/MegaCli/MegaCli64 -AdpBbuCmd -GetBbuStatus -aALL |grep “Charge”
Relative State of Charge: 50 %
Charger Status: Recharging
Full Charge Capacity: 509 mAh

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

惠普伺服器為何沒有同類問題？
目前伺服器除了HP伺服器Raid卡採用鎳氫電池、超級電容外，大部分伺服器Raid卡還都採用的是鋰電池。
鎳氫電池、超級電容，它沒有惰性，並且特性和鋰電池不同，它並不需要通過完全放電來校準電量。
當鎳氫電池由於自放電而導致電量降低時到一定程度時（比如80%），陣列卡控制器會感知到這一資訊並對電池進行娟流充電以補充失去的電量，整個過程對使用者是透明的，也不需要關閉快取，因此並不會影響IO效能。

各品牌伺服器充放電週期：

所以，Raid卡電池充放電階段，會禁用WriteBack模式，以保證資料完整性，同時會造成效能的降低。

通過下面命令生成日誌，可以檢視充放電詳細資訊：
/opt/MegaRAID/MegaCli/MegaCli64 -FwTermLog -Dsply -f log.txt -aALL

• 情況三：伺服器硬體自檢

除了Raid卡電池外，還有一個影響IO的重要因素那就是硬體自檢。回到文章前面提到的監控圖，同一業務的8臺伺服器於11月12日凌晨3:00開始IO開始升高，4:00左右達到最高峰IO利用率達70%左右，之後開始下降直至平穩正常。此係統已經平穩運行了很長時間，並沒有做什麼上線操作。

因為是凌晨3:00出現，而且備份正好是凌晨3:00開始，首先想到可能是備份導致的IO上升，但是登上伺服器檢查發現這幾組機器並沒有部署備份。

那麼接下來可能會認為這段時間事物量較大，通過監控發現這個時間段並沒有大量併發，而且此時間段為業務低峰期，相對訪問操作較少。

開始著手分析硬體，懷疑為Raid卡電池導致，通過命令生成硬體自檢及raid卡電池充放電日誌1.log和2.log，部分日誌內容如下：

/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

通過分析日誌發現，此時Raid卡電池執行正常，也沒有進行充放電。而是系統進行了硬體自檢，時間是每週六凌晨3:00開始。而且這幾臺為同一批機器，再檢視更久的監控，發現每週六凌晨3:00 都會出現IO較高現象。自檢期間IO消耗比較大，如果期間有事物處理，會出現慢SQL、超時等現象，導致TP99報警。

問題原因找到了，該如何優化？

如果調整的話需進入BIOs修改，因為伺服器產品不同，修改方法可能不一樣。

以DELL、ThinkServer為例：

通過ILO F1進入BIOS，首先需要把BIOS的Legacy修改成UEFI模式：

1. 進入boot manage修改 boot mode為UEFI Only
2. 進入Miscellaneous Boot Settings修改Storage OpROM Policy為UEFI Only
3. F10儲存後重啟再進入Boot manage裡面可以看到Adapters and UEFI Drivers 選項
4. 依次進入Controller Management—>Asvanced Controller Management—>Schedule Consistency Check即可看到一致性檢查項：

1. 修改後，選擇Apply Changes，務必執行這一步，選擇應用生效
2. 再把前面的UEFI修改回Legacy模式，否則無法進入作業系統，重啟即可
3. 調整後，結合監控和日誌檢查，沒有再出現凌晨3:00 IO升高現象
4. 這裡的Monthly指的是30天，而不是正常月，所以日期還是不固定9) 調整觀察一段時間後，每週六的IO升高現象不再出現，不建議關閉此功能

總結

杜絕以上問題，需要從伺服器初始化就做好：

1.調整硬體一致性自檢策略，由每週調整為每月，並根據業務情況修改日期。但有一點需要注意，這裡的月指的是固定30天，即使調整日期以後還是會錯亂。不知道伺服器廠商以後是否會修改。

2.針對電商來說，618和雙11是最大的兩個大促，日期相對固定，所以在大促前最好計算一下，是否會趕上，提前做好調整，相對影響更小、更安全。

3.修改Raid卡快取策略

WriteBack，ReadAdaptive，Direct，Write Cache if Bad BBU模式：
此模式下存在在BBU有問題時(如電池失效)期間，突然斷電或者主機板故障都會導致資料丟失風險。

WriteBack，ReadAdaptive，Direct，No Write Cache if Bad BBU模式：
在BBU有問題時, 不使用Write Cache。但是可能發生Write Cache策略變更的情況（由WriteBack變成WriteThrough），導致IO效能急劇下降。

所以，修改成哪種模式需要結合實際業務來定，建議無論是否有raid卡電池都改成WriteBack，ReadAdaptive，Direct，Write Cache if Bad BBU模式。

4.不建議關閉硬體自檢，可以適當延長自檢週期，通過自檢可以及時發現硬體問題，監控更及時。

5.不建議關閉Raid卡電池Auto Learn模式，通過這個校準，能延長電池壽命，不作電池校準的Raid卡，電池壽命將從正常的2年降為8個月。

6.另外mysql innodb_flush_method建議設成O_DIRECT模式：資料檔案的寫入操作是直接從mysql innodb buffer到磁碟（raid卡快取）的，並不用通過OS緩衝，而真正的完成也是在flush這步，日誌還是要經過OS快取。

innodb_flush_log_at_trx_commit、sync_binlog改成0模式也會提升IO效能，但資料安全性會大打折扣，所以不到萬不得已建議不要調成雙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