记一次硬件问题导致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 条评论
登录 后参与评论

相关文章

来自专栏张善友的专栏

Compass: 在你的应用中集成搜索功能

驱动力 在许多应用程序中,用户总会提出搜索和查询领域实例的需求。他们或者希望构建一个进入应用程序的入口或者希望填充表单的机制。非常典型的解决方案是用浏览的方式(...

1729
来自专栏冰霜之地

Realm数据库 从入门到“放弃”

Realm是由Y Combinator公司孵化出来的一款可以用于iOS(同样适用于Swift&Objective-C)和Android的跨平台移动数据库。目前最...

522
来自专栏林欣哲

SpringBoot的微信点餐系统后台开发要点

项目设计 角色划分 买家(微信端) 卖家(PC端) 功能分析 ? 关系 ? 部署架构 ? 架构和基础框架 演进:单一应用架构->垂直应用架构->分布式服务架构-...

1.5K39
来自专栏大内老A

《我的WCF之旅》博文系列汇总

WCF是构建和运行互联系统的一系列技术的总称,它是建立在Web Service架构上的一个全新的通信平台。你可以把它看成是.NET平台上的新一代的Web Ser...

1718
来自专栏程序人生

Promise: 给我一个承诺,我还你一个承诺

处理concurrent programming,除了threading/multi-processing外,各家语言都有自己的绝活:erlang/elixir...

2664
来自专栏友弟技术工作室

ElasticSearch入门实战1

723
来自专栏A周立SpringCloud

Spring Cloud限流详解(附源码)

在高并发的应用中,限流往往是一个绕不开的话题。本文详细探讨在Spring Cloud中如何实现限流。 在 Zuul 上实现限流是个不错的选择,只需要编写一个过滤...

4097
来自专栏精讲JAVA

Netty 实现原理浅析

(点击上方公众号,可快速关注) 来源:kafka0102的博客 , www.kafka0102.com/2010/06/167.html Netty是JBoss...

2158
来自专栏Kubernetes

深度剖析Kubernetes动态准入控制之Admission Webhooks

Author: xidianwangtao@gmail.com Admission Controll的最佳配置 这部分内容,请参考我的上一篇博文深度剖析K...

3127
来自专栏Java帮帮-微信公众号-技术文章全总结

hibernate5新特性展示

摘要: 在hibernate5中,有了一些新的变动: 新引导 API Spatial/GIS 支持 Java 8 支持 扩展 AUTO id 生成支持 命名策略...

2764

扫描关注云+社区