CPU 使用率低高负载的原因,看看这篇!

标签: linux centos | 发表时间:2019-09-22 16:12 | 作者:民工哥技术之路
出处:https://segmentfault.com/blogs

原因总结

产生的原因一句话总结就是:等待磁盘I/O完成的进程过多,导致进程队列长度过大,但是cpu运行的进程却很少,这样就体现到负载过大了,cpu使用率低。

下面内容是具体的原理分析:
在分析负载为什么高之前先介绍下什么是负载、多任务操作系统、进程调度等相关概念。

什么是负载

什么是负载:负载就是cpu在一段时间内正在处理以及等待cpu处理的进程数之和的统计信息,也就是cpu使用队列的长度统计信息,这个数字越小越好(如果超过CPU核心*0.7就是不正常)

负载分为两大部分:CPU负载、IO负载

例如,假设有一个进行大规模科学计算的程序,虽然该程序不会频繁地从磁盘输入输出,但是处理完成需要相当长的时间。因为该程序主要被用来做计算、逻辑判断等处理,所以程序的处理速度主要依赖于cpu的计算速度。此类cpu负载的程序称为“计算密集型程序”。

还有一类程序,主要从磁盘保存的大量数据中搜索找出任意文件。这个搜索程序的处理速度并不依赖于cpu,而是依赖于磁盘的读取速度,也就是输入输出(input/output,I/O).磁盘越快,检索花费的时间就越短。此类I/O负载的程序,称为“I/O密集型程序”。

什么是多任务操作系统

Linux操作系统能够同时处理几个不同名称的任务。但是同时运行多个任务的过程中,cpu和磁盘这些有限的硬件资源就需要被这些任务程序共享。即便很短的时间间隔内,需要一边在这些任务之间进行切换到一边进行处理,这就是多任务。

运行中的任务较少的情况下,系统并不是等待此类切换动作的发生。但是当任务增加时,例如任务A正在CPU上执行计算,接下来如果任务B和C也想进行计算,那么就需要等待CPU空闲。也就是说,即便是运行处理某任务,也要等到轮到他时才能运行,此类等待状态就表现为程序运行延迟。

  uptime输出中包含“load average”的数字
[root@localhost ~]# uptime
 11:16:38 up  2:06, 4 users, load average: 0.00, 0.02, 0.05

Load average从左边起依次是过去1分钟、5分钟、15分钟内,单位时间的等待任务数,也就是表示平均有多少任务正处于等待状态。在load average较高的情况下,这就说明等待运行的任务较多,因此轮到该任务运行的等待时间就会出现较大的延迟,即反映了此时负载较高。

进程调度

什么是进程调度:

进程调度也被一些人称为cpu上下文切换意思是:CPU切换到另一个进程需要保存当前进程的状态并恢复另一个进程的状态:当前运行任务转为就绪(或者挂起、中断)状态,另一个被选定的就绪任务成为当前任务。进程调度包括保存当前任务的运行环境,恢复将要运行任务的运行环境。
在linux内核中,每一个进程都存在一个名为“进程描述符”的管理表。该进程描述符会调整为按照优先级降序排序,已按合理的顺序运行进程(任务)。这个调整即为进程调度器的工作。
调度器划分并管理进程的状态,如:

  • 等待分配cpu资源的状态。
  • 等待磁盘输入输出完毕的状态。

下面在说一下进程的状态区别:

clipboard.png

下面举例来说明进程状态转变:

这里有三个进程A、B、C同时运行。首先,每个进程在生成后都是可运行状态,也就是running状态的开始,而不是现在运行状态,由于在linux内核中无法区别正在运行的状态和可运行的等待状态,下面将可运行状态和正在运行状态都称为running状态。

  • 进程A:running
  • 进程B:running
  • 进程C:running

running的三个进程立即成为调度对象。此时,假设调度器给进程A分配了CPU的运行权限。

  • 进程A:running (正在运行)
  • 进程B:running
  • 进程C:running

进程A分配了CPU,所以进程A开始处理。进程B和C则在此等待进程A迁出CPU。假设进程A进行若干计算之后,需要从磁盘读取数据。那么在A发出读取磁盘数据的请求之后,到请求数据到达之前,将不进行任何工作。此状态称为“因等待I/O操作结束而被阻塞”。在I/O完成处理前,进程A就一直处于等待中,就会转为不可中断睡眠状态(uninterruptible),并不使用CPU。于是调度器查看进程B和进程C的优先级计算结果,将CPU运行权限交给优先级较高的一方。这里假设进程B的优先级高于进程C。

  • 进程A:uninterruptible (等待磁盘输入输出/不可中断状态)
  • 进程B:running (正在运行)
  • 进程C:running

进程B刚开始运行,就需要等待用户的键盘输入。于是B进入等待用户键盘输入状态,同样被阻塞。结果就变成了进程A和进程B都是等待输出,运行进程C。这时进程A和进程B都是等待状态,但是等待磁盘输入输出和等待键盘输入为不同的状态。等待键盘输入是无限期的事件等待,而读取磁盘则是必须短时间内完成的事件等待,这是两种不同的等待状态。各进程状态如下所示:
进程A:uninterruptible (等待磁盘输入输出/不可中断状态)
进程B:interruptible (等待键盘输入输出/可中断状态)
进程C:running (正在运行)

这次假设进程C在运行的过程中,进程A请求的数据从磁盘到达了缓冲装置。紧接着硬盘对内核发起中断信号,内核知道磁盘读取完成,将进程A恢复为可运行状态。

  • 进程A:running (正在运行)
  • 进程B:interruptible (等待键盘输入输出/可中断状态)
  • 进程C:running (正在运行)

此后进程C也会变为某种等待状态。如CPU的占用时间超出了上限、任务结束、进入I/O等待。一旦满足这些条件,调度器就可以完成从进程C到进程A的进程状态切换。

负载的意义

负载表示的是“等待进程的平均数”。在上面的进程状态变换过程中,除了running状态,其他都是等待状态,那么其他状态都会加入到负载等待进程中吗?

事实证明,只有进程处于运行态(running)和不可中断状态(interruptible)才会被加入到负载等待进程中,也就是下面这两种情况的进程才会表现为负载的值。

  • 即便需要立即使用CPU,也还需等待其他进程用完CPU
  • 即便需要继续处理,也必须等待磁盘输入输出完成才能进行

下面描述一种直观感受的场景说明为什么只有运行态(running)和可中断状态(interruptible)才会被加入负载。

如:在很占用CPU资源的处理中,例如在进行动画编码的过程中,虽然想进行其他相同类型的处理,结果系统反映却变得很慢,还有从磁盘读取大量数据时,系统的反映也同样会变的很慢。但是另一方面,无论有多少等待键盘输入输出操作的进程,也不会让系统响应变慢。

什么场景会造成CPU低而负载确很高呢?

通过上面的具体分析负载的意义就很明显了,负载总结为一句话就是:需要运行处理但又必须等待队列前的进程处理完成的进程个数。具体来说,也就是如下两种情况:

  • 等待被授权予CPU运行权限的进程
  • 等待磁盘I/O完成的进程

cpu低而负载高也就是说等待磁盘I/O完成的进程过多,就会导致队列长度过大,这样就体现到负载过大了,但实际是此时cpu被分配去执行别的任务或空闲,具体场景有如下几种。

场景一:磁盘读写请求过多就会导致大量I/O等待

上面说过,cpu的工作效率要高于磁盘,而进程在cpu上面运行需要访问磁盘文件,这个时候cpu会向内核发起调用文件的请求,让内核去磁盘取文件,这个时候会切换到其他进程或者空闲,这个任务就会转换为不可中断睡眠状态。当这种读写请求过多就会导致不可中断睡眠状态的进程过多,从而导致负载高,cpu低的情况。

场景二:MySQL中存在没有索引的语句或存在死锁等情况

我们都知道MySQL的数据是存储在硬盘中,如果需要进行sql查询,需要先把数据从磁盘加载到内存中。当在数据特别大的时候,如果执行的sql语句没有索引,就会造成扫描表的行数过大导致I/O阻塞,或者是语句中存在死锁,也会造成I/O阻塞,从而导致不可中断睡眠进程过多,导致负载过大。
具体解决方法可以在MySQL中运行show full processlist命令查看线程等待情况,把其中的语句拿出来进行优化。

场景三:外接硬盘故障,常见有挂了NFS,但是NFS server故障

比如我们的系统挂载了外接硬盘如NFS共享存储,经常会有大量的读写请求去访问NFS存储的文件,如果这个时候NFS Server故障,那么就会导致进程读写请求一直获取不到资源,从而进程一直是不可中断状态,造成负载很高。

结束语:大概内容就是这样,如果有朋友遇到其他场景,欢迎留言补充。

作者:西门飞冰,一名90后it男,一直在北京工作,热爱运动,热爱冒险,热爱旅行。

关注 民工哥技术之路 微信公众号对话框回复关键字:1024 可以获取一份最新整理的技术干货。

图片描述

相关 [cpu 负载 原因] 推荐:

CPU 使用率低高负载的原因,看看这篇!

- - SegmentFault 最新的文章
产生的原因一句话总结就是:等待磁盘I/O完成的进程过多,导致进程队列长度过大,但是cpu运行的进程却很少,这样就体现到负载过大了,cpu使用率低. 下面内容是具体的原理分析:. 在分析负载为什么高之前先介绍下什么是负载、多任务操作系统、进程调度等相关概念. 什么是负载:负载就是cpu在一段时间内正在处理以及等待cpu处理的进程数之和的统计信息,也就是cpu使用队列的长度统计信息,这个数字越小越好(如果超过CPU核心*0.7就是不正常).

java问题导致linux负载、cpu过高如何定位

- - CSDN博客推荐文章
1.用top找到最耗资源的进程id. 2.查询最消耗资源的java进程. 3.打印java 栈 信息. 4.将耗资源的javaPID转换为16进制(5920转1720<16进制>  去百度找 :十进制转十六进制). PID 对应 堆栈中的nid(16进制). 去stack.txt 中查找nid=1720的问题.

又一次生产 CPU 高负载排查实践

- - crossoverJie's Blog
前几日早上打开邮箱收到一封监控报警邮件:某某 ip 服务器 CPU 负载较高,请研发尽快排查解决,发送时间正好是凌晨. 其实早在去年我也处理过类似的问题,并记录下来: 《一次生产 CPU 100% 排查优化实践》. 不过本次问题产生的原因却和上次不太一样,大家可以接着往下看. 收到邮件后我马上登陆那台服务器,看了下案发现场还在(负载依然很高).

小改动大效果:记一次CPU负载高问题排查和解决

- We_Get - 博客园-首页原创精华区
      问题缘起:收到运维同事发来的邮件,说自上次网站更新后,CPU使用率上升趋势明显(下图中红框部分所示),但网站访问数并没有增加.       问题排查:是什么原因导致CPU使用率上升呢. 肯定是某个访问量比较大的页面进行了耗CPU的操作,如文件读写、内存中的一些复杂运算等. 结合上次网站更新内容,将问题锁定在了房源详情页.

[MySQL优化案例]系列 — 典型性索引引发CPU负载飙升问题

- - MySQL中文网 - 叶金荣的技术和生活
收到一个mysql服务器负载告警,上去一看,load average都飙到280多了,用top一看,CPU跑到了336%,不过IO和内存的负载并不高,根据经验,应该又是一起索引引起的惨案了. 看下processlist以及slow query情况,发现有一个SQL经常出现,执行计划中的扫描记录数看着还可以,单次执行耗时为 0.07s,还不算太大.

数据库服务器CPU 突然持续100%后自动下降原因诊断

- - CSDN博客推荐文章
1、CPU接近100% nmon数据. 8月5日在9:20—9:40之间,出现CPU接近100%的情况,特点表现为9:20左右CPU急剧攀升,在9:45左右又快速下降. 2.1 持续时间与恢复方式. 此次CPU攀高时间持续约20分钟,在无人工干预的情况下自动恢复. 经过分析,原因为:4条SQL语句ORACLE优化器对LB_T_XXXVIDER视图、LB_T_XXXJECT_PROVIDER表、LA_XXCKAGE表的基数数据评估发生了巨大的差错,导致选择了错误的执行计划,消耗大量的CPU资源.

8086 CPU 寄存器简介

- 田野 - 博客园-首页原创精华区
打算写几篇稍近底层或者说是基础的博文,浅要介绍或者说是回顾一些基础知识,. 自然,还是得从最基础的开始,那就从汇编语言开刀吧,. 从汇编语言开刀的话,我们必须还先要了解一些其他东西,. 像  CPU ,内存这些知识点还是理解深刻一点的比较好,. 所以这一篇博文就绕着 80x86  CPU 中寄存器的基础部分下手,至于其他的一些将会在后续的博文中介绍.

CPU架构:i386,x86,AMD64

- - 脚本爱好者
IA32 : 32 bits Intel Architecture (32位带宽Intel构架). IA64 : 64 bits Intel Architecture (64位带宽Intel构架). i386 : Intel 386 ( 老的386机器,也泛指IA32体系的CPU). i586 : Intel 586 ( Pentium ,K6 级别CPU ).

从Java视角理解CPU缓存(CPU Cache)

- - 淘宝网通用产品团队博客
从Java视角理解系统结构连载, 关注我的微博( 链接)了解最新动态众所周知, CPU是计算机的大脑, 它负责执行程序的指令; 内存负责存数据, 包括程序自身数据. 同样大家都知道, 内存比CPU慢很多. 其实在30年前, CPU的频率和内存总线的频率在同一个级别, 访问内存只比访问CPU寄存器慢一点儿.

GPU对战CPU,试验出真知

- nasachn - IFLONELY
MythBusters的两个科学怪才的牛做. 新奇图片搜索引擎Sprixi.