硬件性能 - CPU瓶颈分析

简介

本文章通过CPU各个指标项来简单分析是否出现CPU硬件性能瓶颈。其他硬件分析如下：

1. 硬件性能 - 掌握内存知识

2. 硬件性能 - 磁盘瓶颈分析

3. 硬件性能 - 网络瓶颈分析

 

目录

1. 系统负载

2. CPU利用率

3. 中断占用

4. 上下文切换

---

 

1. 系统负载

• 系统负载是指在一段时间内有多少个进程等待 CPU 资源，常用的系统负载指标是平均负载值（load average）。通过观察平均负载值，可以初步判断 CPU 是否存在瓶颈

通过 uptime 命令查看系统负载

[yt@localhost ~]$ uptime 
06:33:10 up  9:24,  3 users,  load average: 35, 43, 41

• 06:33:10：系统当前时间
• up 9:24：系统已启动9时24分（天 : 时 : 分）
• 3 users：当前系统已登录3个用户
• load average：1/5/15分钟系统平均负载

   

简单判断

        通过上述 uptime 结果，1/5/15分钟平均负载为 35/43/41，如果平均负载值持续高于 CPU 核心数量，可能表示系统中有进程无法及时获得 CPU 资源，即存在 CPU 瓶颈。例如：当前系统CPU的数量为6，每次可以完成6个任务。当前负载了35，也就是有35个任务在等待运行，按计算 35 / 6 = 5.83 表示每颗CPU后面至少有5个任务在排队等候，说明CPU已经非常繁忙。一般来说，当平均负载值高于 CPU 核心数量的 80% 时，可能存在 CPU 瓶颈。但这只是一个经验性的参考值，实际上还需考虑不同的硬件设备和应用场景。

 

 

2. CPU利用率

• CPU利用率是指CPU在一段时间内用于执行任务的时间比例或占用率。它表示了CPU在某个时间段内的工作量。CPU利用率通常使用百分比来表示，可以用来衡量CPU的繁忙程度和资源利用情况。
• CPU利用率可以反映系统对CPU的需求程度和CPU的性能状况。当CPU利用率较高时，表示CPU正被系统或进程广泛使用，可能说明系统有较大的负载或存在CPU瓶颈。而当CPU利用率较低时，可能表示系统负载较轻，或者存在其他性能瓶颈导致CPU无法充分利用。

使用 top 命令查看CPU使用率（ top 交互按 1 ）

圈红表示各个CPU的详细信息，解释如下： 

us：用户空间占用 CPU 的百分比。表示在用户进程运行的时间中，CPU 所占用的时间比例。
sy：内核空间占用 CPU 的百分比。表示在内核进程运行的时间中，CPU 所占用的时间比例。
ni：用户进程以调整过的优先级运行所占用的 CPU 百分比。这是通过用户设置的 nice 值来调整的。
id：CPU 空闲的百分比。表示 CPU 在指定时间内处于空闲状态的时间比例。
wa：等待 I/O 完成所占用 CPU 的百分比。表示 CPU 在等待 I/O 操作完成时的时间比例。
hi：处理硬件中断所占用 CPU 的百分比。表示 CPU 在处理硬件中断的时间比例。
si：处理软件中断所占用 CPU 的百分比。表示 CPU 在处理软件中断的时间比例。
st：由于在虚拟环境中存在资源竞争，被虚拟化偷窃的 CPU 时间的百分比。只有在运行在虚拟机中时才会出现该字段。

 

1. 简单观察CPU利用率

• 观察CPU利用率：关注整个系统的CPU利用率情况。如果CPU持续高于 70% 可能存在CPU性能瓶颈。需要特别注意单个进程或线程占用过高CPU，如有单个进程过度占用CPU，也可能导致性能问题。
• 分析CPU占用率过高的进程：确定CPU使用率较高的进程或线程，可以通过PID来进一步分析它们的资源消耗情况。使用命令如 ps、pidstat 等来查看进程的资源占用情况，例如内存占用、I/O操作等，以确定是否存在其他性能问题。

2. 当Linux系统负载大但CPU利用率低时，这可能表示存在其他性能瓶颈

1. I/O 瓶颈：系统中的磁盘、网络或其他I/O设备可能成为瓶颈，导致系统无法高效处理请求。这会导致负载的增加，但CPU利用率不高。通过iostat来分析系统的I/O性能，查看磁盘读写速度、I/O等待时间等。

2. 内存瓶颈：系统中的内存资源可能不足，导致操作系统频繁进行内存交换（swap）操作。这会增加系统负载，但CPU利用率较低。通过free或top等命令查看系统内存的使用情况，特别关注交换空间的使用情况。

3. 网络瓶颈：如果系统涉及网络通信，可能存在网络设备、带宽或网络堵塞等问题，导致系统负载增加。通过网络监控工具sar或tcpdump来观察网络流量、连接数、延迟等情况。

4. 进程或应用程序问题：某个进程可能有错误、死锁或资源泄露等问题，导致系统负载增加但CPU利用率较低。此外，可能存在未优化的应用程序或算法，导致系统性能下降。

   可以使用工具如ps、top、strace等来分析进程的资源占用情况，并排查可能的问题。

5. 虚拟化问题：如果系统运行在虚拟机环境中，可能存在虚拟化层面的性能问题，如物理机资源不足、过度分配等。

3. 当Linux系统的单颗CPU利用率达到100%时，表示该CPU核心正在全力运行，没有剩余的计算能力可供使用。

1. 确定高CPU利用率的进程：通过top或ps来查看系统中消耗CPU资源最多的进程。注意观察进程的PID（进程标识符），以及相应的CPU使用百分比。

2. 了解进程的性质：对于消耗大量CPU的进程，确定其是系统进程还是用户进程。查看进程的命令行参数、打开的文件、相关的系统调用等，以确定进程的用途和可能的性能问题。

3. 优化高CPU利用率的进程：对于用户进程，检查是否存在性能问题，例如无限循环、大量的计算量、不必要的资源消耗等。优化代码或调整进程的运行参数，以减少其CPU的使用。

4. 调整优先级：如果是用户进程占用了过多的CPU资源，可以使用命令如renice来调整进程的优先级，将其调整为较低的优先级，以减少其对CPU的占用。

5. 平衡负载：如果是多进程或多任务同时竞争CPU资源导致CPU饱和，可以考虑进行负载均衡。例如，使用工具如taskset来将进程绑定到不同的CPU核心，确保任务在多个核心上分布，以减少单个核心的负载。

 

 

3. 中断占用

• 中断是CPU处理外部事件的一种方式，例如设备IO、定时器和网络传输等。当系统中有大量中断发生时，可能会导致CPU过于繁忙，出现瓶颈。

通过 sar -I SUM 命令查看中断统计

• intr/s：每秒接收的中断数平均值

  

1. 观察中断统计次数

        观察中断次数是否频繁增加可以判断是否存在中断瓶颈。通常来说，每秒数百个到数千个中断可以被认为是相对频繁的。然而，这个阈值可以根据具体的硬件和应用程序需求而有所不同。一般来说，如果中断数目持续过高，并且导致系统性能下降，那么就应该考虑优化系统配置或调整应用程序来减少中断。

由于中断阈值并不是一个固定的数值，因为它取决于很多因素。比如：

• 系统负载：如果系统的CPU利用率较高且持续增长，那么中断数目的增加可能是正常的，因为系统需要处理更多的任务。在这种情况下，中断数目的增加可能不会对CPU性能产生明显的负面影响。

• 应用程序需求：特定应用程序的需求会影响中断处理的频率。某些应用程序可能需要更频繁的中断触发来处理实时数据或高速IO操作。

• 硬件能力：硬件配置直接影响中断处理能力。高性能的CPU和IO设备可以处理更高的中断负载。

 

2. 中断处理时间：当中断处理时间较长时，可能意味着CPU正在处理大量中断而导致延迟增加。

1. 比较中断处理时间和CPU利用率：观察中断处理时间与CPU利用率之间的关系。如果CPU利用率很高，但是中断处理时间较短，则可能表明CPU资源不足导致的性能瓶颈。相反，如果CPU利用率较低，但是中断处理时间较长，则可能表明中断处理本身存在问题，可能是驱动程序或硬件的限制。

2. 检查硬件驱动程序和设备：确保使用的硬件驱动程序是最新的，并且与硬件设备兼容。过时的或不完善的驱动程序可能导致中断处理时间过长。

3. 分析中断处理时间的分布：除了观察平均处理时间，还可以分析中断处理时间的分布。如果存在少数的中断处理时间异常长，可能是特定设备或驱动程序引起的问题，需要进一步调查和处理。

 

 

4. 上下文切换

• 下文切换是指CPU从一个正在运行的进程或线程切换到另一个进程或线程的过程。每当操作系统决定将CPU的控制权从一个任务转移到另一个任务时，就会发生上下文切换。
• 上下文是指进程或线程的运行状态和相关的信息，包括寄存器的内容、内存映射、打开文件等等。当操作系统切换到新的任务时，它需要保存当前任务的上下文并加载新任务的上下文，以确保进程或线程在切换后能够正确继续执行。

通过 sar -w 命令查看上下文切换次数

• procs/s: 每秒创建的进程数
• cswch/s: 每秒上下文切换的次数

        上下文切换对系统的性能有一些影响，因为它需要消耗CPU时间和资源来保存和恢复上下文信息。

        通常情况下，上下文切换数量的正常范围取决于系统。对于一个正常运行且无CPU瓶颈的系统，每秒数千次的上下文切换可能是可接受的。

        如果在观察上下文切换时发现值持续超过一万或更高，可能意味着系统存在CPU性能瓶颈。然而，这个阈值并不是绝对的。在某些情况下，高上下文切换数量可能并不一定表示性能瓶颈，特别是在运行大量并发任务或高负载的系统。这时需要结合其他性能指标和系统行为进行综合分析。

        此外，不同的系统和应用程序对上下文切换的敏感程度也有所不同。某些系统和应用程序可能对上下文切换更为敏感，要求更低的上下文切换数量，而另一些系统可能能够容忍更高的上下文切换。