前几天有个客户的系统存在性能问题，从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. GaussDB(DWS)：非侵入式备份及其在NBU上的应用

    摘要:Netbackup软件必须要有该集群所支持的OS的安装包,一种新的非侵入式备份架构呼之欲出. 1. 通用的备份方案介绍 除Netbackup深度定制的厂商外,通常数据库厂商都按XBSA接口来实现 ...

  2. 一分钟带你了解Huawei LiteOS组件开发指南

    摘要:本文将基于Huawei LiteOS系统,从组件定义开始带你走进组件开发指南. 本文分享自华为云社区<一分钟带你了解Huawei LiteOS之组件开发指南>,作者: Lionlac ...

  3. 一文了解如何使用移动应用安全组件Soot和Flowdroid

    摘要:移动应用安全检测,soot.flowdroid分别作为静态分析.污点分析主要工具,能我们能够快速高效的进行检测分析.本文主要介绍两个工具的基本操作及相应的使用场景 本文分享自华为云社区<移 ...

  4. 数据分析引擎百花齐放，为什么要大力投入ClickHouse？

    更多技术交流.求职机会.试用福利,欢迎关注字节跳动数据平台微信公众号,回复[1]进入官方交流群 近年来,OLAP产品的竞争日渐激烈,目前企业间流行的既有Impala.Greenplum等上一代较为成熟 ...

  5. A/B 实验避坑指南：为什么不建议开 AABB 实验

    更多技术交流.求职机会,欢迎关注字节跳动数据平台微信公众号,回复[1]进入官方交流群 本文将针对日常开设 A/B 实验过程中一个不太合理的使用方法--AABB 实验进行详细的解释,告诉大家为什么不建议 ...

  6. 剖析字节案例，火山引擎 A/B 测试 DataTester 如何“嵌入”技术研发流程

    更多技术交流.求职机会,欢迎关注字节跳动数据平台微信公众号,回复[1]进入官方交流群 日前,在 WOT 全球创新技术大会上,火山引擎 DataTester 技术负责人韩云飞做了关于字节跳动 A/B 测 ...

  7. MongoDB 副本模式，会映射到本地 127.0.0.1 错误

    基于 MongoDB 读写分离--Windows MongoDB 副本集配置 ,里面配置了一个坑,导致出现下列错误 [2021-05-10 10:06:11.981] [cluster-Cluster ...

  8. No Feign Client for loadBalancing defined. Did you forget to include spring-cloud-starter-loadbalanc

    No Feign Client for loadBalancing defined. Did you forget to include spring-cloud-starter-loadbalanc ...

  9. JVM学习-自动内存管理

    文章原文:https://gaoyubo.cn/blogs/6997cf1f.html 一.运行时数据区 Java虚拟机在执行Java程序的过程中会把它所管理的内存划分为若干个不同的数据区域.这些区域 ...

  10. Spring 学习笔记（2）框架介绍

    本篇文章主要对 Spring 框架进行整体介绍,包括其核心功能模块与体系结构,让大家对该框架有个大体的认识. 1. 前景提要 如果你之前学过 Servlet 的话,那么一定会对 MVC 分层概念有所了 ...