CPU 性能指标

CPU的主要指标:

CPU Utilization

CPU 使用率,CPU的使用时间百分比,75%以上就比较高了。

在任意时间内,CPU有7个状态:
1.idle,表示CPU闲置并等待工作分配.
2.user,表示CPU在运行用户的进程
3.system,表示CPU在执行kernel工作
4.nice,表示CPU花费在被nice改变过优先级的process上的时间(注意:被nice命令改变优先级的process仅指那些nice值为负的process.花费在被nice命令改变优先级的任务上的时间也将被计算在系统和用户时间内,因此整个时间加起来可能会超过百分之百)
5.iowait,表示CPU等待IO操作完成的时间
6.irq,表示CPU开销在响应硬中断上的时间
7.softirq,表示CPU开销在响应软中断上的时间.
我们一般用vmstat看到的都是四个状态:sy,us,id,wa,通过他和load avg结合,基本可以知道cpu的状态

大部分的性能工具用百分比表示CPU时间.当system时间占用很高的时候,你可以用"oprofile"工具发现时间都花费在哪里.当iowait很高的时候,你需要分析你的IO设备,比如磁盘,网卡.

 

Average load

平均负载,上一分钟同时处于“就绪”状态的平均进程数。

Load这个东西怎么理解呢,就像一条马路,有N个车道,如果N个进程进入车道,那么正好一人一个,再多一辆车就占不到车道,要等有一个车空出车道。
在CPU中可以理解为CPU可以并行处理的任务数,那么就是“CPU个数 * 核数”,如果CPU Load = CPU个数 * 核数 那么就是说CPU正好满负载,再多一点,可能就要出问题了,有任务不能被及时分配处理器,那么保证性能的话,最好是小于CPU个数 * 核数 *0.7。

Load Average是 CPU的 Load,它所包含的信息是在一段时间内 CPU正在处理以及等待 CPU处理的进程数之和的统计信息,也就是 CPU使用队列的长度的统计信息。

Load Average 的值应该小于“CPU个数 * 核数 *0.7 ” ,否则就高了。

比如:
1个1核CPU,Load Average < 1 * 1 * 0.7 = 0.7;
1个4核的CPU,Load Average必须 < 1 * 4 * 0.7 = 2.8。
查看cpu的信息:grep ‘model name’/proc/cpuinfo

使用 vmstat 看到的数据中也有这个数据,vmstat 查看r(Load Average)。

另外,top命令应该是把每个核的CPU占用率加起来,算一个和,于是多核情况下会top命令会计算出超过100%。

在linux中,process有两种状态:
1.runnable
2.blocked waiting for an event to complete
一个blocked状态的process可能在等待一个I/O操作获取的数据,或者是一个系统调用的结果。
如果一个process在runnable状态,这就意味着它将同其他runnable状态的process等待CPU时间,而不是立即获得CPU时间,一个runnable状态的process不需要消耗CPU时间,只有当Linux调度进程从runnable队列中选择哪个process下次执行。
当 process在runnable状态,当时等待CPU时间时,他们形成的等待队列称作Run Queue.Run Queue越大,表示等待的队列越长。
性能工具通常显示runnable processes的数目和blocked processes的数目。
还有一个很常见的系统状态是load average,系统的load是指running和runnable process的总和。
例如:如果有两个processes在running和有三个在等待运行(runnable),那么系统的load为五。
load average是指在指定时间内load的平均值。一般load average显示的三个数字的时间分别为1分钟,五分钟和十五分钟。

 

Interrupt rate

每秒内的设备中断数。CPU接收硬件驱动发出的中断请求数。

这种中断通常是下面请看被触发:

当一个驱动器有一个时间需要被kernel操作时。例如:如果一个磁盘控制器从磁盘上取得了一个数据块,kernel需要读取使用这个块,那么磁盘控制器会触发一个中断;
kernel接收每个中断,一个中断处理器运行如果这个中断被注册,否则,这个中断被忽略。
在系统中,中断处理器的优先级非常高,而且执行速度非常快。
很多时候,有些中断处理并不需要很高的处理优先级,所以也有soft- interrupt handler。

如果有很多的中断,kernel需要花费大量的时间去处理中断。

可以检查/proc/interrupts能够知道中断发生在哪个CPU 上.

 

Interrupt Rate中包括内核由于进程的时间片中断。
在 Linux 2.6 中,系统时钟每 1 毫秒中断一次时钟频率,用 HZ 单位表示(即每秒中断 1000 次)。
系统不一样,内核不一样的配置100、250的都有。

内核的时钟频率可以通过如下命令知道: 

cat /boot/config-`uname -r` | grep ‘^CONFIG_HZ=’

CONFIG_HZ=100

每秒总的时钟中断数就是 = cpu个数 * 核数 * CONFIG_HZ

cat /proc/interrupts   可以查看中断的类型以及次数

         CPU0      CPU1      CPU2      CPU3      
LOC:   97574747   52361843  105207680  69447653   Local timer interrupts
RES:     107368    257510      98635    186294   Rescheduling interrupts
CAL:      14174     14206     14164        194   function callinterrupts
TLB:    1007949    853117     992546    591410   TLB shootdowns

用vmstat查看的 in(Interrupt)就是这个参数

Context Switch Rate

大部分现在的CPU在同一时间只能运行一个process。
虽然也有一些CPU,例如超线程技术的CPU,能实现同时运行超过一个process。linux把这种CPU看作多个单线程CPU。
linux内核不断的在不同process间切换,造成一个错觉,让人感觉一个单CPU同时处理多个任务。
不同process之间的切换称作 Context Switch。
当系统做Context Switch时,CPU保存所有old process的context信息并获得new process的所有context信息。
Context信息包括大量的linux追踪每个process信息,尤其是一些资源:
那些process正在执行,被分配了哪些内存,它打开了那些文件,等等。
切换Context会触发大量的信息移动,这是比较高的开销。
如果可能的话尽量保持很小的 context switches。

为了尽可能的减小context switches,你首先需要知道它们是怎么产生的。
首先,kernel调度触发context switches。为了保证每个process平等的共享CPU时间,kernel周期性中断running的process,如果合适,
kernel调度器会开始一个其他的process而不是让当前的process继续执行,每次的周期性中断或者定时中断都可能触发context switch。
每秒定时中断的次数因不同架构和不同的kernel版本而不同。
获取每秒中断次数的一个简单办法是通过监控 /proc/interrupts文件,看下面的例子:
root@localhost asm-i386]# cat /proc/interrupts | grep timer; sleep 10 ; cat/proc/interrupts | grep timer
0: 24060043 XT-PIC timer
0: 24070093 XT-PIC timer
上面可以看到在指定的时间内timer次数的变化,每秒产生的中断次数为1000次。
如果你的context switch比timer中断大很多。那么context switch更多的可能是I/O请求或者其他长时间的系统调用(比如sleep)产生。
当一个应用请求一个操作不能立即实现时,kernel开始 context switch操作:
存入请求的process并且试着切换到其他runnable process。这将使得CPU保持工作状态.

 

Context Switch大体上由两个部分组成:
中断和进程(包括线程)切换,一次中断(Interrupt)会引起一次切换,进程(线程)的创建、激活之类的也会引起一次切换。
Context Switch 的值也和TPS(Transaction Per Second)相关的,假设每次调用会引起N次CS,那么就可以得出

     Context Switch Rate = Interrupt Rate + TPS* N

CSR减掉IR,就是进程/线程的切换,假如主进程收到请求交给线程处理,线程处理完毕归还给主进程,这里就是2次切换。也可以用CSR、IR、TPS的值代入公式中,得出每次事物导致的切换数。因此,要降低CSR,就必须在每个TPS引起的切换上下功夫,只有N这个值降下去,CSR就能降低,理想情况下N=0,但是无论如何如果N >= 4,则要好好检查检查。

用vmstat查看 cs(Context Switch)就是这个参数

参考资料:

Loadrunner 监控Unix系统性能指标的解释
http://blog.youkuaiyun.com/marising/archive/2010/01/08/5160210.aspx

压力测试衡量CPU的三个指标:CPU Utilization、Load Average和Context Switch Rate
http://blog.youkuaiyun.com/marising/archive/2010/01/12/5182771.aspx

LoadRunner压力测试时监控服务器Linux的资源情况
http://blog.youkuaiyun.com/marising/archive/2010/01/08/5160210.aspx

理解Load Average做好压力测试
http://www.blogjava.net/cenwenchu/archive/2008/06/30/211712.html

CPU负载的分析
http://www.penglixun.com/tech/system/cpu_load_analyse.html

linux cpu相关性能指标
http://www.51testing.com/?uid-3787-action-viewspace-itemid-5527

 

<think>好的,用户现在想了解CPU性能指标。之前他们问过磁盘读写速率的问题,现在转向CPU,说明他们在系统性能分析方面有需求,可能是运维人员或者开发者。需要先回忆之前的回答结构,用户喜欢详细的分类和实际例子,比如表格、指标组合和命令示例。 首先,CPU性能指标有哪些呢?主频、核心数、缓存、IPC、架构这些基础参数。然后性能指标如使用率、负载、上下文切换、中断、CPI、分支预测等。用户可能需要知道如何判断CPU是否瓶颈,以及如何优化。 还要考虑用户可能的深层需求,比如如何监控这些指标,常用的工具是什么。比如top、vmstat、perf等。需要结合场景分析,比如高使用率是否正常,低使用率是否异常,就像之前磁盘的回答那样。 要确保回答结构清晰,分点列出,有实际命令示例和指标解释。可能需要对比不同情况下的正常与异常,比如高负载但低使用率可能是IO等待,或者多线程竞争。还要注意关联其他指标,比如结合内存和磁盘IO来判断瓶颈。 用户可能没有提到的但重要的点,比如温度对性能的影响,或者虚拟化环境中的CPU调度。还有云环境中的vCPU和物理核的区别。需要涵盖这些方面,但不要太过深入,保持实用。 最后给出优化建议,比如调整优先级、绑定CPU、代码优化等。确保语言简洁,用例子和命令帮助用户实际操作。检查是否覆盖了所有主要指标,没有遗漏重要的点,比如超线程的影响或者CPI的计算方法。</think>--- ### CPU性能指标深度解析 CPU性能评估需从**硬件能力**、**系统调度**和**应用特征**三个维度综合分析。以下是核心指标体系及诊断方法: --- ### 一、基础硬件指标 | 指标 | 典型值/特征 | 性能影响 | |------------------|-------------------------------------|------------------------------| | 主频 | 2.4GHz~5.8GHz (睿频) | 单线程性能核心指标 | | 核心/线程数 | 物理核数×超线程数(如8C16T) | 并行计算能力上限 | | 缓存层级 | L1(32-64KB), L2(256KB-1MB), L3(16MB+) | 减少内存延迟的关键 | | IPC(每周期指令数) | 现代CPU约1.5~3.0 | 架构效率的直接体现 | | 制程工艺 | 7nm/5nm/3nm | 影响功耗和发热曲线 | > **示例**:Intel i9-13900K:5.8GHz/24C32T/36MB L3,IPC较12代提升约15% --- ### 二、核心性能指标 #### 1. **使用率指标** - **用户态%us**:应用代码执行时间占比 - **内核态%sy**:系统调用耗时 - **等待I/O%wa**:CPU空闲但等待IO完成 - **空闲%id**:完全空闲时间 **诊断规则**: - 持续`%us + %sy > 80%` → CPU瓶颈 - `%wa > 30%` → 可能存在存储瓶颈 #### 2. **负载指标** - **Load Average**:1/5/15分钟平均就绪队列长度 理想值:≤ CPU线程数(如16线程CPU负载≤16) - **运行队列(r)**:`vmstat 1`中`r`列显示当前等待CPU的任务数 #### 3. **上下文切换** - **voluntary_ctxt_switches**:主动让出CPU(如IO等待) - **nonvoluntary_ctxt_switches**:强制调度(时间片耗尽) 异常标准:>10000次/秒/核心可能引发性能问题 #### 4. **中断与软中断** - **硬中断(INTR)**:来自硬件设备的中断请求 - **软中断(softirq)**:内核网络/块设备处理 网络密集型场景需关注`NET_RX`软中断占比 #### 5. **高级指标** | 指标 | 测量工具 | 健康范围 | |----------------------|----------------|-------------------| | CPI(每指令周期数) | `perf stat` | <1.0 (优化良好) | | 分支预测失败率 | `perf annotate`| <5% | | 缓存命中率(L3) | `perf record` | >95% (理想状态) | --- ### 三、指标组合诊断 通过`top`+`pidstat`+`perf`联合分析: #### 场景1:CPU高使用率 ```bash # 显示CPU密集型进程 $ pidstat -u 1 11:30:01 UID PID %usr %system %CPU CPU Command 11:30:02 0 25632 88.3 2.1 90.4 3 ffmpeg ``` **结论**:ffmpeg进程占用90% CPU,需确认是否预期转码任务 #### 场景2:高负载但低使用率 ```bash $ vmstat 1 procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 24 0 0 158432 10240 890244 0 0 4500 120 1234 5678 10 15 20 55 0 ``` **结论**:24个任务等待CPU(r=24),但55%时间在IO等待(%wa),需排查存储性能 --- ### 四、性能优化方向 #### 硬件层优化 - 升级CPU:提升IPC或核心数(计算密集型 vs 并行任务) - 开启超线程:对虚拟化/容器场景效果显著 - 调整CPU亲和性:`taskset -c 0-3 java -jar app.jar` #### 系统层调优 - 调整调度策略:`chrt -f 1 <pid>` (设置FIFO实时优先级) - 中断平衡:`irqbalance`服务优化中断分配 - 关闭节能模式:`cpupower frequency-set -g performance` #### 应用层优化 - 减少系统调用:批量处理代替频繁小IO - 锁优化:将自旋锁改为读写锁 - SIMD指令优化:使用AVX-512指令集加速计算 --- ### 五、特殊场景注意事项 1. **虚拟化环境**: - 监控`steal time`(%st):反映物理CPU被宿主机抢占的时间 - vCPU绑定:避免跨NUMA节点访问内存 2. **容器环境**: - Cgroup限制:检查`cpu.cfs_quota_us`是否过小 - 避免CPU Throttling:`docker stats`显示容器CPU限制状态 3. **云服务器**: - 突发性能实例:AWS t3系列有CPU积分机制 - 睿频限制:部分云厂商限制最大睿频持续时间 --- ### 六、监控工具矩阵 | 工具 | 核心功能 | 输出示例 | |---------------|-----------------------------|------------------------------| | `top` | 实时进程监控 | %CPU, %us/%sy, 负载 | | `perf` | 指令级性能分析 | CPI, 缓存命中率, 热点函数 | | `vmstat` | 系统级综合指标 | r, b, in, cs, us/sy/id/wa | | `pidstat` | 进程级详细统计 | %usr/%system, 上下文切换次数 | | `turbostat` | 监控CPU频率/C状态 | GHz, Busy%, C1/C6状态占比 | --- **黄金法则**:当CPU指标异常时,必须结合**应用响应时间**、**业务吞吐量**和**资源饱和度**进行三角验证,避免单一指标误判。例如:高CPU使用率但业务吞吐同步增长属于正常负载,而高使用率伴随吞吐下降则需立即介入排查。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值