前几天有个客户的系统存在性能问题，从AWR报告上我们看到是CPU使用率过高，同时GLOBAL CACHE方面的争用比较严重。系统中的烂SQL很多，数据库中很多几十GB的大表也没有分区，总之问题很多。不过这套系统使用了闪存盘，虽然IOPS高达3-4万，不过磁盘IO的性能还可以。USER IO平均值为2毫秒左右，SYSTEM IO平均值为1毫秒左右。
昨天一个研发单位的数据库专家很兴奋的告诉我，他从nmon的监控数据中找到系统性能问题的根因了，存储系统存在瓶颈，因此他组织开发人员去优化物理IO比较多的SQL语句了。当然这种SQL的优化工作肯定对系统是有益的，所以我也没拦住他。不过我觉得很纳闷，明明系统中看IO情况还可以，为什么从nmon上看到IO性能存在很大问题呢？
         
我当时觉得很奇怪，就说从数据库层面上看，似乎IO量虽然很大，不过使用SSD盘的后端SAN存储的性能还凑合，不至于让系统那么慢。不过他贴了一张NMON的图出来，看上去好像盘的IO延时都有70多毫秒。我想了半天，没想明白什么原因，OS上IO采集到的数据与数据库IO延时之间出现较大差异，往往是数据库十分空闲，操作系统IO数量极少的时候才会出现，对于如此高IO负载的系统不大可能出现如此大的偏差。因为岁数大了，眼睛老化了，因此在手机上也看不清楚。
回到办公室，我突然想起来，nmon监控操作系统好像在后台采集状态是不会采集IO延时的，只有实时监控才能看到IO延时。这套系统是Oracle 11.2.0.4，默认是安装了OSWBB的，我从TFA里找到OSW的IOSTAT看了一下，IO延时都在3毫秒左右。
难道是nmon和OSW采集到的数据不同？于是在电脑上打开那张图看了看，原来他看到的60+的指标并不是IO延时，而是DISK BUSY。不过他们十分确定的认为磁盘过于繁忙，说明IO负载过高，会严重影响Oracle数据库的性能。
我见过很多持此观点的DBA，nmon的DISK BUSY来判断OS的IO能力是否存在瓶颈。二十多年前，我也是采用这个方式帮用户分析操作系统IO性能的，这是因为当时对这个指标的认知存在错误。
DISK BUSY，在UNIX系统中叫DISK BUSY或者DISK USAGE，在LINUX中叫util%。不同的LUNIX/UNIX版本，在计算DISK BUSY上会有些不同，不过其主要是衡量一个设备存在IO的时间所占的比例，计算方式是排除掉无任何IO的时间段，剩下的时间段除以采样时间总长度，就是DISK BUSY。这个指标的历史十分悠久，要追溯到使用DAS的三十多年前。那时候的磁盘设备IO并发能力极弱，甚至还有一些IO设备是串行设备。在那个年代，DISK BUSY能够很好地反映出IO设备的繁忙程度。
其算法是在某个时间段内采样IO，如果IO数大于0，则计算为1，否则计算为0。最后采样为1的占比就是DISK BUSY的值。不同版本的操作系统具体采样和计算方式会有不同，不过大体上是这样计算的。比如我们在1秒钟内采样1000个点，每个采样点上都有1个IO，那么这个设备的IOPS是1000，DISK BUSY 是100%，不过这个IO负载对于一块SSD盘来说实际上只是毛毛雨。
SAN存储与现代的SSD设备都不是串行IO设备，是并行设备。在现代存储上做采样的时候，很可能出现这种情况：采样点上，50%的点是无IO的，50%的点上可能平均每个点有50个IO，那么这个设备上的IO负载是25000，负载十分高，但是DISK BUSY 的值是50%。这样就出现了DISK BUSY比较低，实际上IO负载很高的情况了。
正是因为这些年存储技术的发展，传统的DISK BUSY指标已经无法反映出存储系统的真实性能瓶颈了。因此最近这二十年，我们基本上都不用DISK BUSY来判断存储设备是否存在瓶颈了。判断存储设备IO瓶颈的最佳方法是从IOPS、IO吞吐量、IO延时这三个指标来做综合判断。当IO延时与基线数据偏差较大，比如高出5倍以上，那么很可能IO系统已经出现了瓶颈。或者说IOPS或者IO吞吐量超出后端存储设备的基线值1倍以上，就说明IO系统存在瓶颈。
对于基线，有时候我们在分析问题的时候缺乏历史数据和评测数据，不太好衡量基线。我们也可以通过一些经验值做一些估算。比如说对于Oracle数据库，单块读延时在10毫秒以内，IO性能对数据库影响还可以接受，超过10毫秒则会影响较大。对于PG数据库，因为使用DOUBLE CACHE，因此操作系统IO延时低于20毫秒，基本上还可以接受，超出则需要关注。
对于存储设备的IO能力，也可以做一些简单的估算，比如你的数据库使用SAN存储，后端使用了100块15000RPM 的SAS HDD盘，那么可以粗略估算一下每块盘的IOPS大约是300-400,以300计算，那么大约是30000 IOPS的能力，因为RAID 5损失掉30%，那就是21000 IOPS。如果存储的CACHE 命中率是60%，那么这个存储系统大约能够提供的IO能力是21000除以0.4，也就是52500。如果这个存储系统的负载达到80%以上就会出现较大延时，那么当数据库的IOPS达到4万以上的时候，就要关注IO性能是否存在瓶颈了。
对操作系统指标的理解，是要经过大量案例的磨练，并不断的通过知识学习来完成的，而实际上我们在学习这些知识的时候，往往会看到很多过时的，甚至错误的知识。还有些知识是有时代限制的，在二三十年前可能是正确的，到今天可能就不正确了。这对于DBA来说，想要正确地识别知识的真伪，确实十分困难。不过经过大量的案例的实践，不断地积累正确的知识，DBA能力就会越来越强。只要保持学习，保持参与一线技术工作，我想DBA干到五十岁是没有问题的。我今年54了，虽然已经不常在一线工作，不过偶尔还是会参与一些一线案例的分析。我也想挑战一下，DBA这行当能不能干到60岁退休。
文章转载自白鳝的洞穴，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

评论

相关阅读

墨天轮编辑部
1542次阅读
2023-05-01 12:11:25

墨天轮编辑部
1077次阅读
2023-05-10 11:09:58

多明戈教你玩狼人杀
344次阅读
2023-04-24 14:03:21

大强3008
326次阅读
2023-05-08 09:22:20

非法加冯
247次阅读
2023-05-12 10:04:39

JiekeXu
218次阅读
2023-05-18 23:51:00

科蓝SUNDB数据库
167次阅读
2023-04-24 10:46:09

％Lucky
151次阅读
2023-05-08 11:54:01

大数据技术标准推进委员会
132次阅读
2023-04-21 10:10:22

大数据技术标准推进委员会
124次阅读
2023-05-07 09:46:51

[转帖]DISK BUSY的理解误区的更多相关文章

  1. Android中一个经典理解误区的剖析

    今天,在Q群中有网友(@广州-包晴天)发出了网上的一个相对经典的问题,问题具体见下图. 本来是无意写此文的,但群里多个网友热情不好推却,于是,撰此文予以分析. 从这个问题的陈述中,我们发现,提问者明显 ...

  2. CORS跨域模型浅析及常见理解误区分析

    CORS跨域资源共享是前后端跨域十分常用的一种方案,主要依赖Access-Control-Allow(ACA)系列header来实现一种协商性的跨域交互. 基本模型 其中的具体流程大致可以分为以下几步 ...

  3. iOS 在 ARC 环境下 dealloc 的使用、理解误区

    iOS 在 ARC 环境下 dealloc 的使用.理解误区 太阳火神的漂亮人生 (http://blog.csdn.net/opengl_es) 本文遵循"署名-非商业用途-保持一致&qu ...

  4. HTTP协议GET方法传参最大长度理解误区

    结论 HTTP 协议未规定GET和POST的长度 GET的最大长度是因为浏览器和WEB服务器显示了URI的长度 不同浏览器和WEB服务器,限制的最大长度不同 若要支持IE,则最大长度为2083 byt ...

  5. 关于 HTTP GET/POST 请求参数长度最大值的一个理解误区（转载）

    1. Get方法长度限制 Http Get方法提交的数据大小长度并没有限制,HTTP协议规范没有对URL长度进行限制.这个限制是特定的浏览器及服务器对它的限制.下面就是对各种浏览器和服务器的最大处理能 ...

  6. [转帖]十分钟快速理解DPI和PPI，不再傻傻分不清！

    十分钟快速理解DPI和PPI,不再傻傻分不清! https://baijiahao.baidu.com/s?id=1605834796518990333&wfr=spider&for= ...

  7. Nginx反向代理理解误区之proxy_cookie_domain

    基本内容 Nginx做反向代理的时候,我们一般习惯添加proxy_cookie_domain配置,来做cookie的域名转换,比如 ... location /api { proxy_pass htt ...

  8. 关于 HTTP GET/POST 请求参数长度最大值的一个理解误区

    1.    Get方法长度限制 Http Get方法提交的数据大小长度并没有限制,HTTP协议规范没有对URL长度进行限制.这个限制是特定的浏览器及服务器对它的限制. 如:IE对URL长度的限制是20 ...

  9. CSS中关于margin的理解误区

    思考一 在以前,我对于margin的理解是这样的,此处用margin-top举例:指的是离相邻元素之间的距离. 但是实际是:相对于自身原来的位置偏移. 举个例子: <!DOCTYPE HTML ...

  10. [转帖]2019-03-26 发布 深入理解 MySQL ——锁、事务与并发控制

    深入理解 MySQL ——锁.事务与并发控制 https://segmentfault.com/a/1190000018658828 太长了 没看完.. 数据库 并发  mysql 639 次阅读   ...

随机推荐

  1. Cesium案例解析(七)——Layers在线地图服务

    目录 1. 概述 2. 案例 2.1. Blue Marble 2.2. ArcGIS地形 2.3. Cesium地形 2.4. Natural Earth II 2.5. Earth at Nigh ...

  2. 质效提升 ｜ 聊聊QA与业务测试

    上面一篇文章<质效提升 | QA不做业务需求测试,你怎么看>主要讨论的是QA 和业务需求测试相关的问题,文章发出后收到了很多小伙伴的反馈,这里把很多有意义的反馈放在下面,希望对你有用. 约 ...

  3. C++篇：第十三章_异常_知识点大全

    C++篇为本人学C++时所做笔记(特别是疑难杂点),全是硬货,虽然看着枯燥但会让你收益颇丰,可用作学习C++的一大利器 十三.异常 ① 函数指针与该指针所指的函数必须具有一致的noexcept异常说明 ...

  4. 4大焕新，华为云CCE带你感受容器化上云体验

    本文分享自华为云社区<华为云CCE邀您共同打造最佳容器化上云体验>,作者:云容器大未来 . 在容器化日益成为中大型企业上云主流选择的情况下,容器服务如何能帮助用户更简单快捷的上云.高效可信 ...

  5. 华为云发布CodeArts Inspector漏洞管理服务，守护产品研发安全

    本文分享自华为云社区<华为云发布CodeArts Inspector漏洞管理服务,守护产品研发安全>,作者: 华为云头条. 2023年9月7日,华为云正式发布CodeArts Inspec ...

  6. 聊聊GaussDB AP是如何执行SQL的

    本文分享自华为云社区<GaussDB AP是如何执行SQL的>,作者:yd_270088468. 前言 介绍GaussDB AP各组件是如何协调工作的,会着重介绍SQL引擎. 1.SQL引 ...

  7. 【API进阶之路】太秃然了，老板要我一周内检测并导入一万个小时的视频

    摘要:假期结束后回来上班,走进电梯都有一种特别的感觉,电梯那个植发广告里的大哥看我的眼神好像和之前不太一样- 上回说到,老板奖励7天带薪假,我就回家玩耍了几天,顺便还帮兄弟发不脱当了一回"A ...

  8. JPA 表名大小写问题

    JPA 默认会将实体中的 TABLE_NAME 转成小写如 @Entity @Table(name = "EMPLOYEE") public class Employee { @I ...

  9. Django中安装websocket

    完整代码: https://gitee.com/mom925/django-system项目结构: 先安装所需库: pip install channels下面将websocket作为插件一样的只需要 ...

  10. 【HZERO】feign调用

    feign调用 https://open.hand-china.com/community/detail/603204901962649600 # Hiam获取用户信息示例