《告警:IO利用率飚至60%+,請及時排查優(yōu)化!》要點:
本文介紹了告警:IO利用率飚至60%+,請及時排查優(yōu)化!,希望對您有用。如果有疑問,可以聯(lián)系我們。
導讀:通常引起IO升高的因素很多,比如高并發(fā)或大字段寫入、硬盤老化有壞塊、Raid卡電池損壞或充放電、硬件自檢等都會引起IO升高.本文主要對硬件自檢導致的IO問題排查做簡要說明.
監(jiān)控報警,IO最大利用率達60%+,應(yīng)用TP99超時,成功率降低,如下為當時監(jiān)控圖:
第一, 定時任務(wù)導致.
先看時間,是否為定時任務(wù)導致,比如備份.如果binlog之前生成較多,過期后自動清理也會導致IO升高,可以通過磁盤空間監(jiān)控查看.
第二,并發(fā)較大寫磁盤頻繁.
一般此問題不會造成IO util 50%以上.如果事物較大或者并發(fā)較大,general log或slow log會有記錄,我們可以先看下當前線程連接情況,再結(jié)合general log或slow log查看是哪些SQL導致.是否需要優(yōu)化SQL還是控制并發(fā),以及調(diào)整數(shù)據(jù)庫刷新頻率置成雙0模式.
第三,硬件因素導致.
IO util 50%以上,很大幾率是硬件問題導致,磁盤是否有壞塊.最常見的就是Raid卡電池損壞(充放電),如果電池損壞沒有開啟寫緩存,則會直接寫磁盤,IO會升高.我們可以通過如下命令檢查,除HP服務(wù)器外其他采用MegaCli查看硬件信息,HP采用自帶hpssacli命令查看,切記不要使用老命令hpacucli,此命令會導致部分HP型號服務(wù)器操作系統(tǒng)直接Hang.
查看磁盤壞塊:
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損壞時不寫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查看電池狀態(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
查看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
這種情況,如果沒有修改默認WriteCache OK if Bad BBU模式或者No-Battery Write Cache: Enabled,在電池損壞時會轉(zhuǎn)換成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卡電池保護,即突然斷電或者主板故障時會造成數(shù)據(jù)丟失風險.數(shù)據(jù)庫服務(wù)器一般采用雙電模式,掉電風險較低,但是主板故障相對較高,所以BBU壞時是否要打開Write Cache,需要根據(jù)業(yè)務(wù)情況綜合取舍.
首先我們先了解BBU充放電原理:
BBU由鋰離子電池和電子控制電路組成.鋰離子電池的壽命取決于其老化程度,從出廠之后,無論它是否被充電及它的充放電次數(shù)多與少,鋰離子電池的容量將慢慢的減少.這意味著一個老電池無法像新電池那么持久.也就決定了BBU的相對充電狀態(tài)(Relative State of Charge)不會等于絕對充電狀態(tài)(Absolute State of Charge).
為了記錄電池的放電曲線,以便控制器了解電池的狀態(tài),例如最大和最小電壓等,同時為了延長電池的壽命,默認會啟用自動校準模式(AutoLearn Mode).在learn cycle期間,Raid卡控制器不會啟用BBU直到它完成校準.整個過程大概1小時左右.這個過程中,會禁用WriteBack模式,以保證數(shù)據(jù)完整性,同時會造成性能的降低.
整個Learn Cycle分為三個步驟:
注意:如果第二或第三階段被中斷,重新校準的任務(wù)會停止,而不會重新執(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卡還都采用的是鋰電池.
鎳氫電池、超級電容,它沒有惰性,并且特性和鋰電池不同,它并不需要通過完全放電來校準電量.
當鎳氫電池由于自放電而導致電量降低時到一定程度時(比如80%),陣列卡控制器會感知到這一信息并對電池進行娟流充電以補充失去的電量,整個過程對用戶是透明的,也不需要關(guān)閉緩存,因此并不會影響IO性能.
各品牌服務(wù)器充放電周期:
產(chǎn)品類型 | 默認周期 |
DELL | 90天 |
ThinkServer | 28天 |
IBM | 30天 |
RH(華為) | 27天 |
HP | 電容不進行例行充放電 |
所以,Raid卡電池充放電階段,會禁用WriteBack模式,以保證數(shù)據(jù)完整性,同時會造成性能的降低.
通過下面命令生成日志,可以查看充放電詳細信息:
/opt/MegaRAID/MegaCli/MegaCli64 -FwTermLog -Dsply -f log.txt -aALL
除了Raid卡電池外,還有一個影響IO的重要因素那就是硬件自檢.回到文章前面提到的監(jiān)控圖,同一業(yè)務(wù)的8臺服務(wù)器于11月12日凌晨3:00開始IO開始升高,4:00左右達到最高峰IO利用率達70%左右,之后開始下降直至平穩(wěn)正常.此系統(tǒng)已經(jīng)平穩(wěn)運行了很長時間,并沒有做什么上線操作.
因為是凌晨3:00出現(xiàn),而且備份正好是凌晨3:00開始,首先想到可能是備份導致的IO上升,但是登上服務(wù)器檢查發(fā)現(xiàn)這幾組機器并沒有部署備份.
那么接下來可能會認為這段時間事物量較大,通過監(jiān)控發(fā)現(xiàn)這個時間段并沒有大量并發(fā),而且此時間段為業(yè)務(wù)低峰期,相對訪問操作較少.
開始著手分析硬件,懷疑為Raid卡電池導致,通過命令生成硬件自檢及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),此時Raid卡電池運行正常,也沒有進行充放電.而是系統(tǒng)進行了硬件自檢,時間是每周六凌晨3:00開始.而且這幾臺為同一批機器,再查看更久的監(jiān)控,發(fā)現(xiàn)每周六凌晨3:00 都會出現(xiàn)IO較高現(xiàn)象.自檢期間IO消耗比較大,如果期間有事物處理,會出現(xiàn)慢SQL、超時等現(xiàn)象,導致TP99報警.
問題原因找到了,該如何優(yōu)化?
如果調(diào)整的話需進入BIOs修改,因為服務(wù)器產(chǎn)品不同,修改方法可能不一樣.
以DELL、ThinkServer為例:
通過ILO F1進入BIOS,首先需要把BIOS的Legacy修改成UEFI模式:
杜絕以上問題,需要從服務(wù)器初始化就做好:
1.調(diào)整硬件一致性自檢策略,由每周調(diào)整為每月,并根據(jù)業(yè)務(wù)情況修改日期.但有一點需要注意,這里的月指的是固定30天,即使調(diào)整日期以后還是會錯亂.不知道服務(wù)器廠商以后是否會修改.
2.針對電商來說,618和雙11是最大的兩個大促,日期相對固定,所以在大促前最好計算一下,是否會趕上,提前做好調(diào)整,相對影響更小、更安全.
3.修改Raid卡緩存策略
WriteBack,ReadAdaptive,Direct,Write Cache if Bad BBU模式:
此模式下存在在BBU有問題時(如電池失效)期間,突然斷電或者主板故障都會導致數(shù)據(jù)丟失風險.
WriteBack,ReadAdaptive,Direct,No Write Cache if Bad BBU模式:
在BBU有問題時, 不使用Write Cache.但是可能發(fā)生Write Cache策略變更的情況(由WriteBack變成WriteThrough),導致IO性能急劇下降.
所以,修改成哪種模式需要結(jié)合實際業(yè)務(wù)來定,建議無論是否有raid卡電池都改成WriteBack,ReadAdaptive,Direct,Write Cache if Bad BBU模式.
4.不建議關(guān)閉硬件自檢,可以適當延長自檢周期,通過自檢可以及時發(fā)現(xiàn)硬件問題,監(jiān)控更及時.
5.不建議關(guān)閉Raid卡電池Auto Learn模式,通過這個校準,能延長電池壽命,不作電池校準的Raid卡,電池壽命將從正常的2年降為8個月.
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模式也會提升IO性能,但數(shù)據(jù)安全性會大打折扣,所以不到萬不得已建議不要調(diào)成雙0.
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