排行
数据库百科
核心案例
行业报告
月度解读
大事记
产业图谱
中国数据库
向量数据库
时序数据库
实时数据库
搜索引擎
空间数据库
图数据库
数据仓库
大调查
2021年报告
2022年报告
年度数据库
2020年openGauss
2021年TiDB
2022年PolarDB
2023年OceanBase
首页
资讯
活动
大会
学习
课程中心
推荐优质内容、热门课程
学习路径
预设学习计划、达成学习目标
知识图谱
综合了解技术体系知识点
课程库
快速筛选、搜索相关课程
视频学习
专业视频分享技术知识
电子文档
快速搜索阅览技术文档
文档
问答
服务
智能助手小墨
关于数据库相关的问题,您都可以问我
数据库巡检平台
脚本采集百余项,在线智能分析总结
SQLRUN
在线数据库即时SQL运行平台
数据库实训平台
实操环境、开箱即用、一键连接
数据库管理服务
汇聚顶级数据库专家,具备多数据库运维能力
数据库百科
核心案例
行业报告
月度解读
大事记
产业图谱
我的订单
登录后可立即获得以下权益
免费培训课程
收藏优质文章
疑难问题解答
下载专业文档
签到免费抽奖
提升成长等级
立即登录
登录
注册
登录
注册
首页
资讯
活动
大会
课程
文档
排行
问答
我的订单
首页
专家团队
智能助手
在线工具
SQLRUN
在线数据库即时SQL运行平台
数据库在线实训平台
实操环境、开箱即用、一键连接
AWR分析
上传AWR报告,查看分析结果
SQL格式化
快速格式化绝大多数SQL语句
SQL审核
审核编写规范,提升执行效率
PLSQL解密
解密超4000字符的PL/SQL语句
OraC函数
查询Oracle C 函数的详细描述
智能助手小墨
关于数据库相关的问题,您都可以问我
精选案例
新闻资讯
云市场
登录后可立即获得以下权益
免费培训课程
收藏优质文章
疑难问题解答
下载专业文档
签到免费抽奖
提升成长等级
立即登录
登录
注册
登录
注册
首页
专家团队
智能助手
精选案例
新闻资讯
云市场
微信扫码
复制链接
新浪微博
分享数说
采集到收藏夹
分享到数说
首页
/
评价CPU负载用average LOAD一定没问题吗??
评价CPU负载用average LOAD一定没问题吗??
白鳝的洞穴
2021-02-20
1132
昨天刚刚讲过“运维人员应该多学习一些理论知识”,实际上很多理论知识的学习并不是看几本书或者上几堂课就可以解决的。很多知识必须是深入研究后才能获得真知的。一些似是而非的知识可能会影响我们对真知的理解。
早期大家都是通过cpu usage%来评价CPU负载的,随着CPU技术的发展,我们发现有时候cpu usage% 达到100%也不一定说明CPU存在瓶颈了。这些年来,做运维的人更多的会使用load来评估CPU的负载。从Oracle 11g开始,AWR报告也提供了关于CPU load的信息。
我们可以很方便的使用uptime命令来获得Load average的数据。
以前我也是用AWR中的LOAD来初步判断服务器的负载的。不过有一次一个朋友让我看一份AWR报告,这份报告中CPU使用率不高,但是LOAD却很高。当时那个朋友很不理解,在他一贯的认知中,load一般来说是和CPU使用率紧密关联的。后来通过分析我们发现在他的系统中的NFS文件系统出现问题了,因此有不少处于D状态的进程HANG死,从uptime中可以看到load确实比较高,不过实际上CPU很空闲。
除了这种情况外,有时候我们也会发现似乎load average的值和我们从vmstat 看到的r队列的数据会略有不同。下面是一个例子。
从1秒钟监视一次的vmstat命令上看,r队列的深度平均下来应该不到40,而从uptime上我们看到了一个很高的值。
而有的时候,我们看到实际当前的r队列很高,但是最近1分钟的平均负载又偏小。这是怎么回事呢?如果你遇到了这个问题,但是觉得无法理解,那么就说明你还没有真正理解load average的计算方法。load average 中的三个值分别是最近1分钟,5分钟和15分钟的平均值。字面上的意思就是这样的,实际上真的如此吗?
首先我们来理解一下uptime中的1分钟平均负载的含义,从字面的理解我们肯定很容易理解为最近1分钟的负载。实际上并不是这样的,根据https://en.wikipedia.org/wiki/Load_(computing)上的描述,uptime在统计最近1分钟负载的时候,还考虑了衰减的问题。在1分钟平均值中,1-1/e的权重是最近1分钟的LOAD统计值(大约是63%),还有另外37%的权重是系统启动以来(不包含最近1分钟)的LOAD的平均值。 5分钟与15分钟的average load值也是类似的。因此,如果我们的系统是一个在一天内负载变化很大的系统,那么从uptime中看到的average load有可能是偏低的,并不能十分精准的反映出实际的当前负载。
如果是这样,那么为什么我们有时候看到的average load会高于实际的runable队列深度呢?这种现象只会在LINUX上看到,在其他的UNIX系统上是看不到这种情况的。其他的LINUX系统在统计LOAD的时候只统计R状态的线程,而LINUX上会将状态为R和D的进程累加后统计为LOAD。D状态的进程是处于非阻断等待状态,大部分情况是在等待磁盘IO,网络IO等。Linux的开发者认为,D状态是十分短暂的,处于D状态的进程一旦完成IO后,马上就会转换为R状态,因此把D状态的进程也统计为LOAD似乎也是合理的。
确实是这样的,IO子系统处于正常状态的时候,D状态的进程很快会转变为R状态,因此LOAD的统计不会出现太大的问题。不过当我们的IO子系统出现问题的时候,比如我们的系统中的IO负载很高,IO相应速度比较慢,那么处于D状态的线程数量就会比较多,D状态的进程转换为R状态也就会比较慢,这个时候我们看到系统的LOAD就会高于实际的CPU使用情况情况,这张情况下,我们会看到CPU的使用率里WIO的比例会比较高。我曾经遇到过一个系统,CPU使用率并不高,但是LOAD特别高,客户也觉得十分奇怪。后来发现这个系统中的NFS文件系统出了问题,很多进程都处于D状态僵死了。这时候我们看到的现象就是load average比实际的CPU使用情况要高很多。在我们遇到物理IO性能较差的时候,也会看到类似的现象,实际上linux系统下,把r队列和b队列的值相加,作为load指标,而在其他的UNIX系统下,不存在这个问题。因此在LINUX下,我们如果发现LOAD比较高的时候,不要只是去分析CPU的使用情况,还需要排除是IO阻塞引起的LOAD变大的问题,这样才不会出现明显的偏差。
从上面老白的分析可以看出,如果我们不能真正的理解average load,那么这个指标可能会给我们带来很多的误解,但是一旦我们真的理解了average load的含义,我们再去使用这个指标的时候不仅不会产生误解,甚至还能从这个指标的异常判断出一些系统可能存在的隐患。
老白曾经多次提过,准确的指标是自动化运维的基石,准确的理解指标的真正含义,才能真这个的发挥指标的作用。
数据库
文章转载自
白鳝的洞穴
,如果涉嫌侵权,请发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。
评论
领墨值
有奖问卷
意见反馈
客服小墨