【2025最新面试操作系统八股】CPU利用率和load(负载)的区别,CPU利用率怎么算。
总结
负载(Load)和 CPU 利用率是衡量系统性能的两个不同的指标,它们从不同的角度反映了系统的状态。
CPU 利用率表示 CPU 正在执行指令的时间比例,即 CPU 忙碌的程度。它是一个百分比值,表示在某个时间间隔内,CPU 处于非闲置状态的时间比例。例如,如果 CPU 利用率为 70%,这意味着在观察的时间间隔内,有 70% 的时间 CPU 正在处理任务,而 30% 的时间处于空闲状态。
负载(Load)通常指的是一段时间内系统等待处理的工作量。在 Unix-like 系统中,负载平均(Load Average)通常表示在过去 1 分钟、5 分钟和 15 分钟内运行队列的平均长度。运行队列长度是指在某一时刻,处于就绪状态和运行状态的进程数量的和。这个数值包括了正在使用 CPU 的进程和等待 CPU 的进程。
所以:
●CPU 利用率关注的是 CPU 的忙碌程度,而负载关注的是系统中等待运行的工作量。
●高 CPU 利用率表示 CPU 正在积极工作,而低 CPU 利用率可能意味着 CPU 大部分时间处于空闲。
●高负载意味着有很多进程等待使用 CPU,可能会导致系统响应变慢。
CPU 利用率关注的是资源的使用效率,而负载则关注的是服务的压力大小。
CPU利用率与系统负载(Load)的区别及计算方法
一、核心概念区别
指标 | CPU利用率 (CPU Usage) | 系统负载 (Load Average) |
---|---|---|
定义 | CPU时间片的使用比例 | 系统处于可运行或不可中断状态的平均进程数 |
关注点 | CPU资源的繁忙程度 | 系统整体的资源压力 |
计算范围 | 仅CPU时间 | 包含CPU、磁盘I/O、锁等待等所有资源等待 |
单位 | 百分比(0%-100%) | 无单位数值(如1.23表示1.23个活跃进程) |
时间维度 | 瞬时值或短周期采样 | 1分钟/5分钟/15分钟移动平均值 |
二、CPU利用率的计算方法
现在我们用到操作系统,无论是Windows、Linux还是MacOS等其实都是多用户多任务分时操作系统。
使用这些操作系统的用户是可以“同时”干多件事的,这已经是日常习惯了,并没觉得有什么特别。 但是实际上,对于单CPU的计算机来说,在CPU中,同一时间是只能干一件事儿的。
为了看起来像是“同时干多件事”,分时操作系统是把CPU的时间划分成长短基本相同的时间区间,即"时间片",通过操作系统的管理,把这些时间片依次轮流地分配给各个用户使用。
如果某个作业在时间片结束之前,整个任务还没有完成,那么该作业就被暂停下来,放弃CPU,等待下一轮循环再继续做.此时CPU又分配给另一个作业去使用。 由于计算机的处理速度很快,只要时间片的间隔取得适当,那么一个用户作业从用完分配给它的一个时间片到获得下一个CPU时间片,中间有所"停顿",但用户察觉不出来,好像整个系统全由它"独占"似的。
而我们说到的CPU的占用率,一般指的就是对时间片的占用情况。
1. 基础计算公式
CPU利用率 = (1 - 空闲时间 / 总时间) × 100%
2. 从/proc/stat获取原始数据(Linux)
cat /proc/stat//top命令也可以用来查看CPU的利用率,除此之外,还可以使用vmstat来查看cpu的利用率。
//第一个参数是采样的时间间隔数,单位是秒,第二个参数是采样的次数
vmstat 2 2
top
输出示例:
cpu 1000 200 300 5000 0 100 50 0 0 0
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 1 0 2446260 0 3202312 0 0 201 16304 1 6 0 0 84 5 1
//%us:用户进程执行时间百分比
//%sy:内核系统进程执行时间百分比
//%id:空闲时间百分比
//%wa:IO等待时间百分比
//%st:虚拟 CPU 等待实际 CPU 的时间的百分比
//us的值比较高时,说明用户进程消耗的CPU时间多,但是如果长期超50%的使用,那么我///们就该考虑优化程序算法或者进行加速。
//sy的值高时,说明系统内核消耗的CPU资源多,这并不是良性表现,我们应该检查原因。
//wa的值高时,说明IO等待比较严重,这可能由于磁盘大量作随机访问造成,也有可能磁盘出现瓶颈(块操作)。
Cpu(s): 0.1%us, 0.2%sy, 0.0%ni, 92.8%id, 0.1%wa, 0.0%hi, 0.0%si, 6.8%st
各字段含义(单位:jiffies,通常1 jiffies=10ms):
-
user(1000):用户态运行时间
-
nice(200):低优先级用户态时间
-
system(300):内核态运行时间
-
idle(5000):空闲时间
-
iowait(0):I/O等待时间
-
irq(100):硬件中断时间
-
softirq(50):软件中断时间
-
steal(0):虚拟化环境下被偷取的时间
3. 计算示例
python
# 第一次采样 cpu_data1 = [1000, 200, 300, 5000, 0, 100, 50, 0]# 第二次采样(间隔1秒后) cpu_data2 = [1500, 250, 450, 5500, 0, 150, 80, 0]# 计算总时间差 total_diff = sum(cpu_data2) - sum(cpu_data1) # 8000-6650=1350# 计算空闲时间差 idle_diff = cpu_data2[3] - cpu_data1[3] # 5500-5000=500# CPU利用率 usage = (1 - idle_diff / total_diff) * 100 # (1-500/1350)*100 ≈ 63%
4. 细分利用率类型
-
用户态利用率:
(user + nice) / total * 100%
-
内核态利用率:
system / total * 100%
-
I/O等待率:
iowait / total * 100%
-
总利用率:
(total - idle) / total * 100%
CPU利用率是对一个时间段内CPU使用状况的统计,通过这个指标可以看出在某一个时间段内CPU被占用的情况。
Java Web应用CPU使用率飙高排查思路
当发现系统的CPU使用率飙高时,首先要定位到是哪个进程占用的CPU较高。一般情况下,对于Java代码来说,导致CPU飙高可能由以下几个原因引起:
1、内存泄露、导致大量Full GC(如典型的Java 1.7之前的String.subString导致的内存泄露问题)
2、代码存在死循环(如典型的多线程场景使用HashMap导致死循环的问题)
基本都是先定位到占用CPU较多的进程和线程,然后通过命令在查看这条线程执行情况。通过分析代码来定位其中的问题。
最重要的是熟练的使用jstack、jstat以及jmap等命令来定位及解决Java进程的问题。
三、系统负载(Load Average)详解
CPU的Load是在一段时间内CPU正在处理以及等待CPU处理的进程数之和的统计信息,也就是CPU使用队列的长度的统计信息。
主要是由于CPU使用、内存使用、IO消耗三部分构成。任意一项使用过多,都将导致服务器负载的急剧攀升。
1. 负载值的含义
-
负载=1.0:CPU刚好满负荷(1个CPU核心100%忙碌)
-
负载>1.0:有进程在等待资源
-
负载<1.0:系统有空闲资源
2. 多核CPU的解读
对于4核CPU:
-
负载4.0表示所有核心100%忙碌
-
负载6.0表示有2个进程在等待
3. 查看方法
# uptime、top、w等命令可以在Linux查看系统的负载情况
uptime # 输出:14:30:01 up 10 days, 1:23, 3 users, load average: 0.75, 1.20, 1.35 #1.74 1.87 1.97 这三个数字的意思分别是1分钟、5分钟、15分钟内系统的平均负荷。我们一#般表示为load1、load5、load15。
~ w
14:08 up 23:41, 3 users, load averages: 1.74 1.87 1.97
USER TTY FROM LOGIN@ IDLE WHAT
hollis console - 六14 23:40 -
hollis s000 - 六14 20:24 -zsh
hollis s001 - 六15 - w
#系统在近1分钟、5分钟和15分钟的平均负载分别是1.74 1.87 1.97
~ top
Processes: 244 total, 3 running, 9 stuck, 232 sleeping, 1484 threads 14:16:01
Load Avg: 1.74, 1.87, 1.97 CPU usage: 8.0% user, 6.79% sys, 85.19% idle SharedLibs: 116M resident, 16M data, 14M linkedit. MemRegions: 66523 total, 2152M resident, 50M private, 930M shared.
PhysMem: 7819M used (1692M wired), 370M unused. VM: 682G vsize, 533M framework vsize, 6402060(0) swapins, 7234356(0) swapouts. Networks: packets: 383006/251M in, 334448/60M out.
Disks: 1057821/38G read, 350852/40G written.
最后三个数字分别代表1分钟、5分钟、15分钟平均负载
load正常标准
基于单核情况下
当系统负荷持续大于0.7,你必须开始调查了,问题出在哪里,防止情况恶化。
当系统负荷持续大于1.0,你必须动手寻找解决办法,把这个值降下来。
当系统负荷达到5.0,就表明你的系统有很严重的问题,长时间没有响应,或者接近死机了。你不应该让系统达到这个值。
推出基于多核情况下
0.7算是单核机器负载的安全线,所以多核情况下的安全线 == cpu核数 * 0.7
合理分析
1分钟系统负荷表示最近的暂时现象。15分钟系统负荷表示是持续现象,并非暂时问题。如果load15较高,而load1较低,可以认为情况有所好转。反之,情况可能在恶化。
load过高可能的原因
1、是否有内存泄露导致频繁GC
2、是否有死锁发生
3、是否有大字段的读写
4、会不会是数据库操作导致的,排查SQL语句问题。
这里还有个建议,如果发现线上机器Load飙高,可以考虑先把堆栈内存dump下来后,进行重启,暂时解决问题,然后再考虑回滚和排查问题。
Java Web应用Load飙高排查思路
1、使用uptime查看当前load,发现load飙高
2、使用top命令,查看占用CPU较高的进程ID。
3、使用 top命令,查看具体是哪个线程占用率较高
4、使用printf命令查看这个线程的16进制
5、使用jstack命令查看当前线程正在执行的方法。
6、还可以使用jstat来查看GC情况,看看是否有频繁FGC,然后再使用jmap来dump内存,查看是否存在内存泄露。
四、关键差异场景分析
场景1:CPU密集型应用
-
高CPU利用率(如90%)
-
高负载(如4.0/4核)
-
现象:CPU是瓶颈,进程排队等待CPU时间片
场景2:I/O密集型应用
-
低CPU利用率(如30%)
-
高负载(如3.5/4核)
-
现象:进程大部分时间在等待I/O,CPU空闲但系统繁忙
场景3:健康状态
-
CPU利用率:70%-80%(留有处理突发余量)
-
负载:略低于CPU核心数(如3.5/4核)
五、监控工具对比
工具 | CPU利用率 | 系统负载 | 特点 |
---|---|---|---|
top | ✅ | ✅ | 实时视图 |
htop | ✅ | ✅ | 增强版top,彩色显示 |
vmstat | ✅ | ✅ | 包含内存和I/O统计 |
mpstat | ✅ | ❌ | 多核CPU详细统计 |
sar | ✅ | ✅ | 历史数据记录 |
glances | ✅ | ✅ | 现代化综合监控工具 |
六、性能调优启示
-
高CPU利用率+高负载:
-
优化CPU密集型代码
-
考虑增加CPU核心
-
-
低CPU利用率+高负载:
-
检查磁盘I/O瓶颈(
iostat -x 1
) -
优化数据库查询或文件操作
-
-
负载高于CPU核心数:
-
短期峰值正常
-
持续高位需扩容或优化
-
理解这两个指标的差异,能更准确地诊断系统性能瓶颈。CPU利用率告诉你"CPU有多忙",而系统负载告诉你"有多少任务在排队"。两者结合分析,才能全面把握系统健康状况。