193
京東網上商城
告警：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兼容服務器命令
查看磁盤壞塊：
查看緩存策略：
此種狀態為BBU損壞時不寫Raid卡緩存
修改為BBU損壞時寫Raid卡緩存：
生成自檢及電池充放電日誌：
打開物理磁盤緩存：
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卡電池狀態：
這種情況，如果沒有修改默認WriteCache OK if Bad BBU模式或者No-Battery Write Cache: Enabled，在電池損壞時會轉換成WT模式。從而導致IO非常高。
修改成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分為三個步驟：
-
控製器把BBU電池充滿電(該步驟可能是放電後充電或直接充電，如果電池剛好滿電，則直接進入第二階段)；
-
開始校準, 對BBU電池執行放電；
-
放電完成後，完成校準，並重新開始充電，直接達到最大電量，整個Learn Cycle才算完成 。
注意：如果第二或第三階段被中斷，重新校準的任務會停止，而不會重新執行。
再來說超級電容：
超級電容優於鋰電池，采用電容+Flash子板的方式來將非正常掉電後的髒數據刷入Flash中永久保存。超級電容在50℃環境下可以使用5年，而且故障率低，不用例行充放電。目前大部分raid卡廠商也轉向使用超級電容+Flash的備電方案。
采用MegaCli方式查看電池充放電周期：
查看充電狀態：
HP查看電容狀態：
惠普服務器為何沒有同類問題？
-
目前服務器除了HP服務器Raid卡采用鎳氫電池、超級電容外，大部分服務器Raid卡還都采用的是鋰電池。
-
鎳氫電池、超級電容，它沒有惰性，並且特性和鋰電池不同，它並不需要通過完全放電來校準電量。
-
當鎳氫電池由於自放電而導致電量降低時到一定程度時（比如80%），陣列卡控製器會感知到這一信息並對電池進行娟流充電以補充失去的電量，整個過程對用戶是透明的，也不需要關閉緩存，因此並不會影響IO性能。
各品牌服務器充放電周期：
所以，Raid卡電池充放電階段，會禁用WriteBack模式，以保證數據完整性，同時會造成性能的降低。
通過下麵命令生成日誌，可以查看充放電詳細信息：
-
服務器硬件自檢
除了Raid卡電池外，還有一個影響IO的重要因素那就是硬件自檢。回到文章前麵提到的監控圖，同一業務的8台服務器於11月12日淩晨3:00開始IO開始升高，4:00左右達到最高峰IO利用率達70%左右，之後開始下降直至平穩正常。此係統已經平穩運行了很長時間，並沒有做什麼上線操作。
因為是淩晨3:00出現，而且備份正好是淩晨3:00開始，首先想到可能是備份導致的IO上升，但是登上服務器檢查發現這幾組機器並沒有部署備份。
那麼接下來可能會認為這段時間事物量較大，通過監控發現這個時間段並沒有大量並發，而且此時間段為業務低峰期，相對訪問操作較少。
開始著手分析硬件，懷疑為Raid卡電池導致，通過命令生成硬件自檢及raid卡電池充放電日誌1.log和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即可看到一致性檢查項：
5.修改後，選擇Apply Changes，務必執行這一步，選擇應用生效
6.再把前麵的UEFI修改回Legacy模式，否則無法進入操作係統，重啟即可
7.調整後，結合監控和日誌檢查，沒有再出現淩晨3:00 IO升高現象
8.這裏的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。
原文發布時間為：2017-03-30
本文來自雲棲社區合作夥伴DBAplus
最後更新：2017-05-16 11:32:19