理解linux cpu load

理解linux cpu load

译文原文

你可能已经很熟悉linux的平均load. 平均load是3个数 (可以用uptime或者top命令查看), 他们看着像下面这样:
load average: 0.09, 0.05, 0.01

我们对这些数都有一个模糊的概念:三个数分别代表了一个随着更长时间上的一个平均值(1分钟, 5分钟, 15分钟). 并且值越小越好. 越大的数可能就表明有问题或者已经高负载了. 但是这个阈值是多少? 什么是状态好的/坏的负载?什么时候我们需要关心这个平均值, 什么时候我们需要赶紧起来修复它?

流量

这里先讨论单核处理器:
一个单核单处理器的CPU就像一个只有一条车道.假想下你是一个桥梁的工作人员, 有时候,车辆太多了,所以有车辆都排成一条线通过.你想让后面的人知道这条路上的流量到底是多少.一个相当好的指标就是:某一时间有多少车在等待. 如果没有车在等待, 那么来的车就知道,他们可以直接通过. 如果有车在排队了,司机就知道他们要被延迟通过了.

所以,对收费员而言,用什么数字来表示呢?

  • 0表示没有任何流量
  • -1.00表示达到最大流量
  • 大于1.00表示已经有排队等待了

这就是CPU load的基本含义. 这里的汽车就是进程 (用cpu的时间片, 也就是通过这座桥 或者排队等待使用cpu). unix使用类似的概念runqueue length来表示:当前有多个正在等待的进程和正在执行的进程的个数总和;
作为桥梁操作员, 你肯定不希望你的汽车/进程有任何的等待. 所以你的cpu load理想情况下应该是低于1. 偶尔一下的超过1也是可以的. 但是如果一直超过1, 我们就需要担心了.

理想值

那么理想的cpu load是1.00么
好吧, 并不是. 问题是当load是1.00的时候, 已经没有任何空闲空间了. 实际上, 许多系统管理员有一个经验值:0.70

  • 经验1:需要看下 - 0.70. 如果你的load一直大于0.70, 那么需要抽时间调查下了。
  • 经验2:修复它 - 1.00. 如果你的load一直大于1.0,那么赶紧找到问题原因并修复它。
  • 经验3:如果你的load一直大于5.00,你可能真的遇上事了.你的任务可能被挂起了,或者放慢了.并且这会不可预期;

多核处理器

对于一个4核处理器的系统, 一个load为3.00的时候 依然很健康

在一个多处理器系统上, load是相对处理器核数来说的. 100%的使用率在一个单核处理器系统上load是1.00, 在一个双核处理器上就是2.00, 在一个4核处理器上就是4.00.

回到我们前面的桥梁操作员的例子中, 1.00 表示只有一条道有流量. 在一个只有一条道的桥梁上,意味着它被填满了. 在一个两条道的桥梁上, 1.00 表示只有50%的容量 - 只有一条道满了,另外一条道完全可以继续通行(空的).

CPU 也是如此: load 1.00表示: 在单核CPU上100%的占用率, 在一个双核CPU 上, load 2.00代表100%的占用率.

多核心(multi-core)vs多处理器(multi-processor)

多核心和多处器的区别. 对性能而言, 一个双核处理器和2个单核处理器是差不多的. 当然也有些微妙的关系比如(cache, 进程在多个处理器上的切换). 除开这些,对于load而言, 核心的个数才是最重要, 有多少个物理处理器不重要,也不管他们如何分布

  • 核心个数=最大load: 在一个多核系统中, 你的load不应该超过的你的核心数.
  • 核心就是核心: 这些核心在CPU中是如何分布的是不关心的. 2个4核处理器=4个双核处理器=1个八核处理器. 这都是8个核心

示例

让我们来看下uptime的输出:

# uptime
 15:37:12 up 183 days,  5:06,  1 user,  load average: 0.00, 0.01, 0.05

0.00是最近1分钟的平均load, 0.01 是最近5分钟的平均load, 0.05是最近15分钟的平均负载.
我们应该关心的当然是15分钟的这个数值,因为CPU 偶尔有spike是比较正常的, 而且一般都会正常工作. 如果最近15分钟这个值都很高, 那就真的要调查下了;

  • 查看核心数
# cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 85
model name      : Intel(R) Xeon(R) Platinum 8163 CPU @ 2.50GHz
stepping        : 4
microcode       : 0x1
cpu MHz         : 2499.996
cache size      : 33792 KB
physical id     : 0
siblings        : 1
core id         : 0
cpu cores       : 1
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl eagerfpu pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx avx512f avx512dq rdseed adx smap avx512cd avx512bw avx512vl xsaveopt xsavec xgetbv1
bogomips        : 4999.99
clflush size    : 64
cache_alignment : 64
address sizes   : 46 bits physical, 48 bits virtual
power management:

这里cpu cores : 1就是我们服务器的核心数了;

猜你喜欢

转载自blog.csdn.net/cb905259982/article/details/80913940