前几天有个客户的系统存在性能问题，从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. 文心一言 VS 讯飞星火 VS chatgpt （144）-- 算法导论12.1 4题

    四.用go语言,对于一棵有 n 个结点的树,请设计在 O(n)时间内完成的先序遍历算法和后序遍历算法. 我个人喜欢 灵小智 . 文心一言: 在 Go 语言中,我们可以使用递归来实现树的前序遍历和后序遍 ...

  2. Feign源码解析5：loadbalancer

    背景 经过前面几篇的理解,我们大致梳理清楚了FeignClient的创建.Feign调用的大体流程,本篇会深入Feign调用中涉及的另一个重要组件:loadbalancer,了解loadbalance ...

  3. vue图片由小放大

    原生效果 <template> <div> <transition> <img :src="imageUrl" class="i ...

  4. JSON字符串中获取一个特定字段的值

    第一种 import com.google.gson.JsonObject; import com.google.gson.JsonParser; String json="{\" ...

  5. 以小博大外小内大,Db数据库SQL优化之小数据驱动大数据

    SQL优化中,有一条放之四海而皆准的既定方针,那就是:永远以小数据驱动大数据.其本质其实就是以小的数据样本作为驱动查询能够优化查询效率,在SQL中,涉及到不同表数据的连接.转移.或者合并,这些操作必须 ...

  6. 实战案例丨ModelArts在数据标注、数据过滤上的应用技巧：自动分组

    大量复杂.乱序的图片依次标注效率极低,如果一次可以标注一大片的图片将极大地提升标注效率. 自动分组识别并提取图像特征,通过ModelArts先进的聚类算法可以将所有图片分组:将特征相似的图片归为一类, ...

  7. 基于ModelArts进行流感患者密接排查

    摘要:针对疫情期间存在的排查实时性差.排查效率低.无法追踪密接者等问题,可以使用基于YOLOv4的行人检测.行人距离估计.多目标跟踪的方案进行解决. 本文分享自华为云社区<基于ModelArts ...

  8. DTSE Tech Talk 第18期丨统计信息大揭秘，数仓SQL执行优化之密钥

    摘要:华为云EI DTSE技术布道师王跃,针对统计信息对于查询优化器的重要性,GaussDB(DWS)最新版本的analyze当前能力,与开发者和伙伴朋友们展开交流互动,帮助开发者快速上手使用统计信息 ...

  9. 8种图数据库对 NULL 属性值支持情况

    摘要:在语义网等图模型中,遵循开放世界假设,对于数据中未包含的事实,都认为是未知的而非假的. 本文分享自华为云社区<图数据库对 NULL 属性值支持情况>,原文作者:你好_TT . NUL ...

  10. 一文带你熟知ForkJoin

    摘要:ForkJoin将复杂的计算当做一个任务,而分解的多个计算则是当做一个个子任务来并行执行. 本文分享自华为云社区<[高并发]什么是ForkJoin?看这一篇就够了!>,作者:冰 河. ...