记一次硬件问题导致IO较高分析

通常遇到此问题可能原因

第一、并发较大刷磁盘频繁

一般此问题不会造成io util 90%以上。如果事物较大或者并发较大,slow log会有记录,我们可以先看下当前线程连接情况,再结合slow log查看是哪些sql导致。

第二、Raid卡电池处于充放电阶段或者损坏

io util 90%以上,很大几率是硬件问题导致,我们可以通过如下命令检查,除HP服务器外其他采用MegaCli查看硬件信息,HP采用自带hpssacli命令查看,切记不要使用老命令hpacucli,此命令会导致部分HP型号服务器操作系统系统直接hang住。

MegaCli所兼容的服务器命令

查看缓存策略:

/opt/MegaRAID/MegaCli/MegaCli64 -cfgdsply -aALL |grep Policy

Default Cache Policy: WriteBack, ReadAhead, Direct, No Write Cache if Bad BBUCurrent Cache Policy: WriteBack, ReadAhead, Direct, No Write Cache if Bad BBUAccess Policy : Read/WriteDisk 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 BBUCurrent Cache Policy: WriteBack, ReadAhead, Direct, Write Cache OK if Bad BBUAccess Policy : Read/WriteDisk Cache Policy : Disk's Default

生成自检及电池充放电日志:

/opt/MegaRAID/MegaCli/MegaCli64 -AdpEventLog -GetEvents -aALL -f 1.log

/opt/MegaRAID/MegaCli/MegaCli64 -FwTermLog -Dsply -aALL -f 2.log

打开物理磁盘缓存:

/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 detail|grep 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.

这种情况,如果没有修改默认WriteCache OK if Bad BBU模式,在电池损坏时会转换成WT模式。从而导致IO非常高。

Default Cache Policy: WriteBack, ReadAdaptive, Direct, No Write Cache if Bad BBUCurrent Cache Policy: WriteThrough, ReadAdaptive, Direct, No Write Cache if Bad BBU

修改成WC模式后监控如下:可见io使用率从99.6%降到8%左右,效果显著。

但是这种情况下存在一个问题:因为没有raid卡电池保护,即突然断电或者主板故障时会造成数据丢失风险。数据库服务器一般采用双电模式,掉电风险较低,但是主板故障相对较高,所以BBU坏时是否要打开Write Cache,需要根据业务情况综合取舍。

二、Raid卡电池充放电

目前服务器除了HP服务器Raid卡采用电容外,大部分服务器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才算完成 注意: 如果第二或第三阶段被中断,重新校准的任务会停止,而不会重新执行。

不推荐关闭Auto Learn模式,通过这个校准,能延长电池寿命,不作电池校准的Raid卡,电池寿命将从正常的2年降为8个月。

再来说超级电容:

超级电容优于锂电池,采用电容+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: TransparentHP查看电容状态:hpssacli ctrl all show status Smart Array P440ar in Slot 0 (Embedded) Controller Status: OK Cache Status: OK Battery/Capacitor Status: OK

各品牌服务器充放电周期:

产品类型

默认周期

DELL

90天

ThinkServer

28天

IBM

30天

RH(华为)

27天

HP

电容不进行例行充放电

所以,Raid卡电池充放电阶段,会禁用WriteBack模式,以保证数据完整性,同时会造成性能的降低。

通过下面命令生成日志,可以查看充放电详细信息:

/opt/MegaRAID/MegaCli/MegaCli64 -FwTermLog -Dsply -aALL -f log.txt

三、硬件自检

首先看一个监控图,同一业务的8台服务器于11月12日凌晨3:00开始io开始升高,4:00左右达到最高峰io利用率达70%左右,之后开始下降直至平稳正常。此系统已经平稳运行了很长时间,并没有做什么上线操作。

因为是凌晨3:00出现,而且备份正好是凌晨3:00开始,首先想到可能是备份导致的io上升,但是登上服务器检查发现这几组机器并没有部署备份。

那么接下来可能会认为这段时间事物量较大,通过监控发现这个时间段并没有大量并发,而且此时间段为业务低峰期,相对访问操作较少。

开始着手分析硬件,通过命令生成硬件自检及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

通过分析日志发现,系统会进行硬件自检,时间是每周六凌晨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升高现象

总结

杜绝以上问题,需要从服务器初始化就做好:

  1. 调整硬件一致性自检策略,由每周调整为每月,并根据业务情况修改日期,针对电商来来说,618和双11是最大的两个大促,日期相对固定,但是赶到周几就不一定了,所以会尽量调到月末,相对影响更小、更安全。
  2. 修改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模式。
  3. 不建议关闭硬件自检,可以适当延长自检周期,通过自检可以及时发现硬件问题,监控更及时。
  4. 不建议关闭raid卡电池Auto Learn模式,通过这个校准,能延长电池寿命,不作电池校准的Raid卡,电池寿命将从正常的2年降为8个月。
  5. 另外mysql innodb_flush_method建议设成O_DIRECT模式:数据文件的写入操作是直接从mysql innodb buffer到磁盘(raid卡缓存)的,并不用通过操作系统的缓冲,而真正的完成也是在flush这步,日志还是要经过OS缓存。

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

原文发布于微信公众号 - MYSQL轻松学(learnmysql)

原文发表时间:2017-01-21

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏睿哥杂货铺

基于Go Packet实现网络数据包的捕获与分析

Packet capture is a computer networking term for intercepting a data packet that...

85910
来自专栏一枝花算不算浪漫

[全文检索]Lucene基础入门.

3658
来自专栏Golang语言社区

使用Go开发一个简单的服务器程序

最近有个小项目,需要一个简单的后台程序来支撑,本来想用Nodejs来做,但是由于本人js一直很菜,并且很讨厌callback,虽然我也很喜欢异步模型,但我一直都...

3149
来自专栏hotqin888的专栏

engineercms利用pdf.js制作连续看图功能

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/hotqin888/article/det...

941
来自专栏潇涧技术专栏

Gradle Plugin for Android Development User Guide 2

Gradle Plugin for Android Development User Guide (2)

621
来自专栏Java成神之路

分布式_事务_02_2PC框架raincat源码解析

上一节已经将raincat demo工程运行起来了,这一节来分析下raincat的源码

891
来自专栏函数式编程语言及工具

Akka(10): 分布式运算:集群-Cluster

   Akka-Cluster可以在一部物理机或一组网络连接的服务器上搭建部署。用Akka开发同一版本的分布式程序可以在任何硬件环境中运行,这样我们就可以确定以...

4209
来自专栏向治洪

android PakageManagerService启动流程分析

PakageManagerService的启动流程图 ? 1.PakageManagerService概述 PakageManagerService是andro...

35910
来自专栏嵌入式程序猿

Modbus RTU驱动程序开发指引

Modbus RTU 驱动开发 摘要 这篇笔记主要介绍基于飞思卡尔kv4x系列MCU的modbus RTU(Remote Terminal Unit)驱动程序开...

3165
来自专栏Golang语言社区

使用Go开发一个简单的服务器程序

最近有个小项目,需要一个简单的后台程序来支撑,本来想用Nodejs来做,但是由于本人js一直很菜,并且很讨厌callback,虽然我也很喜欢异步模型,但我一直都...

3466

扫码关注云+社区