《告警：IO利用率飚至60%+，請及時排查優化！》要點：
本文介紹了告警：IO利用率飚至60%+，請及時排查優化！，希望對您有用。如果有疑問，可以聯系我們。

導讀：通常引起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性能.

各品牌服務器充放電周期：

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

所以,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

轉載請注明本頁網址：
http://www.snjht.com/jiaocheng/4291.html