前几天有个客户的系统存在性能问题，从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. Langchain-Chatchat项目：1.1-ChatGLM2项目整体介绍

      ChatGLM2-6B是开源中英双语对话模型ChatGLM-6B的第2代版本,引入新的特性包括更长的上下文(基于FlashAttention技术,将基座模型的上下文长度由ChatGLM-6B的2K ...

  2. 大道如青天,协程来通信,Go lang1.18入门精炼教程，由白丁入鸿儒，Go lang通道channel的使用EP14

    众所周知,Go lang的作用域相对严格,数据之间的通信往往要依靠参数的传递,但如果想在多个协程任务中间做数据通信,就需要通道(channel)的参与,我们可以把数据封装成一个对象,然后把这个对象的指 ...

  3. 云图说｜初识华为云数据库GaussDB(for openGauss)

    摘要:本文带你了解华为云华为云数据库GaussDB(for openGauss),将AI 技术融入分布式数据库的全生命周期,实现自运维.自管理.自调优.故障自诊断和自愈. 本文分享自华为云社区< ...

  4. THOR：MindSpore 自研高阶优化器源码分析和实践应用

    摘要:这篇文章跟大家分享下THOR的实践应用.THOR算法的部分内容当前已经在MindSpore中开源 本文分享自华为云社区<MindSpore 自研高阶优化器源码分析和实践应用>,原文作 ...

  5. 独家下载！突破开源Redis，华为云十年自研内核修炼之路《企业级Redis技术与应用解读》重磅发布

    摘要:互联网业务神器最新揭秘:GaussDB(for Redis)如何以自研架构,突破开源版本限制,带来企业级稳定可靠?通过入门篇.性能篇.测评篇.应用篇四个章节,聚焦问题解决.场景应用和开发实战,分 ...

  6. Shell：Lite OS在线调试工具知多少

    摘要:Shell作为Huawei Liteos在线调试工具,可以通过串口工具输入输出,支持常用的基本调试功能.同时用户可以新增定制的命令,新增命令需重新编译烧录后才能执行 本文分享自华为云社区< ...

  7. Appuploader工具让ipa上传到App Store 的最新流程和步骤

    ​ 苹果官方提供的工具xcode上架ipa非常复杂麻烦.用appuploader 可以在 mac 和windows 上制作管理 证书 ,无需钥匙串工具 条件:1.以Windows为例,创建app打包i ...

  8. PPT 放映电脑Office版本低怎么办

    转换成全图形PPT 转成图片,无法放动画 转换成全视频 转成视频,无法控制节奏 PPT VIEWEB 本地PPT播放工具

  9. 你正在调试XXX的发布版本，如果在启用 仅我的代码 的同时,使用通过编译器优化的发布版本

    仅我的代码"警告 你正在调试 XXX.dll 的发布版本.如果在启用"仅我的代码"的同时使用通过编译器优化的发布版本,调试体验会降级(例如,将不会命中断点) 停止调试禁用 ...

  10. 深挖 Rundll32.exe 的多种“滥用方式”以及其“独特”之处

    恶意软件作者通常会编写恶意软件模仿合法的Windows进程.因此,我们可能会看到恶意软件伪装成svchost.exe.rundll32.exe或lsass.exe进程,攻击者利用的就是大多数Windo ...