找回密码
立即注册
搜索
热搜: Java Python Linux Go
发回帖 发新帖

3216

积分

0

好友

436

主题
发表于 2 小时前 | 查看: 5| 回复: 0

在之前的文章中,我们已经探讨了CPU的平均负载与使用率概念,并详细说明了CPU使用率的计算和获取方法。那么,当我们真正遇到CPU使用率过高的性能问题时,该如何着手排查呢?今天,我们就来系统地梳理一下这个问题的排查思路。

一、 整体判断:快速定位问题方向

当系统出现明显卡顿或监控告警提示CPU使用率过高时,第一步通常是进行整体状态的快速检查。

  1. 查看系统负载
    使用 uptime 命令可以立即看到系统的平均负载。对负载高低最直接的判断依据,是与当前服务器的CPU核心数进行对比。

  2. 使用 top 命令观察全局
    运行 top 命令,可以直观地看到CPU使用率的整体分布情况。

    top - 20:12:00 up 70 days,  3:49,  1 user,  load average: 0.10, 0.18, 0.14
    Tasks: 2229 total,   1 running, 332 sleeping,   0 stopped,   0 zombie
    %Cpu(s):  0.0 us,  0.0 sy,  0.0 ni, 99.9 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
    KiB Mem : 52468537+total, 47777491+free, 36061900 used, 10848532 buff/cache
    KiB Swap:  31250428 total,  31250428 free,        0 used. 48045312+avail Mem
    
     PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
    29973 root      20   0   42728   5972   3136 R   0.7  0.0   0:00.16 top
        9 root      20   0       0      0      0 I   0.3  0.0  43:13.52 rcu_sched
    22809 root      20   0 1024352  88780  19280 S   0.3  0.0  56:53.22 zk_proxy

    你可以按下数字 1 键,来查看所有CPU核心的详细使用情况。

    • 解读 %Cpu(s):这一行是分析的关键,你需要重点关注以下几个指标:

      • us (用户态):数值偏高通常意味着应用程序进程消耗了大量CPU,需要重点排查下文列出的高消耗进程。
      • sy (内核态):数值偏高可能由频繁的系统调用或上下文切换引起。这时可以观察系统是否在运行大量I/O密集型或频繁调用硬件驱动的程序。
      • wa (I/O等待):数值偏高说明CPU在等待I/O操作(通常是磁盘或网络),这往往暗示着存储性能或网络可能存在瓶颈。
      • id (空闲):这个值越高,说明CPU越空闲。
    • 定位高CPU使用率进程:在 top 界面中,进程默认就是按CPU使用率降序排列的。记下排名靠前的几个进程PID和名称。你也可以使用 ps 命令快速筛查:

      ps aux --sort=-%cpu | head -20

      这条命令会列出消耗CPU最高的前20个进程。

    • 观察僵尸进程:在 top 输出的第二行(Tasks行)可以看到 zombie 的数量。出现少量僵尸进程通常问题不大,但如果数量持续大量增长,可能意味着父进程未能正确回收子进程,这本身也可能消耗系统资源。

二、 寻找关联信息:探查深层诱因

在分析具体的高CPU进程之前,我们还需要查看一些关联的系统指标。CPU使用率高有时只是表象,其根源可能在其他地方。根据上一步对 %Cpu(s) 行的初步判断,可以按图索骥:

  • 若怀疑上下文切换频繁:可以使用 vmstat 命令(例如 vmstat 1),观察 cs(context switch,上下文切换)指标。如果该值异常高,可能意味着内核进程异常或进程间竞争激烈。
  • wa (I/O等待) 值偏高:使用 iostat -x 1 命令查看磁盘I/O状况。重点关注 %util(设备利用率)和 await(平均I/O响应时间)等指标。如果这些指标异常,则磁盘I/O很可能已成为瓶颈。这类问题就涉及到运维/DevOps/SRE中常见的性能监控范畴。
  • 检查内存与Swap:使用 free -htop 查看内存使用情况,观察是否因物理内存不足导致系统频繁使用交换分区(Swap)。频繁的Swap in/out会引发大量磁盘I/O,间接导致CPU使用率升高。
  • 排查网络异常:网络流量过大或遭受攻击(如DDoS)也可能导致CPU使用率飙升。特别是在没有启用网络硬件卸载(offload)功能的场景下,CPU需要亲自处理大量的网络数据包计算。

三、 使用 perf 进行进程级深度剖析

通过前两步,我们可能已经锁定了导致CPU使用率过高的“嫌疑进程”。但如果仍不清楚该进程内部到底在做什么,就需要更精细的工具进行深入分析。perf 是Linux内核自带的一款功能强大的性能剖析工具。

1. 安装 perf
大多数主流Linux发行版都可以通过包管理器安装:

# 安装perf
sudo apt update
sudo apt install linux-tools-common
sudo apt install linux-tools-$(uname -r)
# 对于CentOS/RHEL系统,通常使用 yum install perf

2. 常用命令与解读

  • 实时剖析perf top -g -p <PID>
    这条命令可以实时查看指定进程内哪些函数消耗CPU最多。

    root@node:~# perf top -p 747
    
    Samples: 61 of event 'cpu-clock:pppH', 4000 Hz, Event count (approx.): 4813878 lost: 0/0 drop: 0/1
    Overhead  Shared Object     Symbol
     16.68%  [kernel]          [k] finish_task_switch
      5.66%  gapd              [.] 0x0000000000056be5
      5.62%  [kernel]          [k] __lock_text_start
      5.19%  gapd              [.] 0x0000000000007602
      4.54%  [kernel]          [k] _warn_unseeded_randomness
      4.51%  [kernel]          [k] release_task
      4.29%  [kernel]          [k] __handle_mm_fault
      4.29%  [kernel]          [k] copy_page
      3.98%  [kernel]          [k] __slab_alloc
      3.98%  [kernel]          [k] rw_verify_area

    输出中,Overhead 列表示该函数占用的CPU比例,Shared Object 指出函数所属模块(如应用程序本身gapd,或内核[kernel]),Symbol 是函数名或地址。使用方向键选中高占用的函数,按回车可以展开其调用关系链,这有助于快速定位到问题源码。

  • 记录与报告
    你也可以将性能数据记录下来,供后续详细分析。

    # 记录全局性能事件,持续约15秒后按 Ctrl+C 停止
    perf record -g
    # 或者记录特定进程
    perf record -g -p <pid>
    
    # 生成并查看分析报告
    perf report
    # 或将报告输出到文本文件
    perf report -n --stdio > perf_report.txt

    这些数据对于理解计算机基础层面如CPU调度、内核函数调用等原理非常有帮助。更详细的使用方法可以查阅 perf --helpman perf

总结

CPU使用率过高的排查是一个由面到点、逐步收敛的过程:先从整体负载和全局视角(top)锁定方向,再结合关联系统指标(内存、I/O、网络)排除外部诱因,最后利用高级工具(perf)深入问题进程内部进行函数级剖析。掌握这个思路,再结合具体的系统知识,你就能更从容地应对生产环境中的CPU性能问题。

Linux性能调优系列




上一篇:深入解析:synchronized 关键字如何通过内存屏障保证多线程可见性
下一篇:大学生独立开发SBTI人格测试走红,创意技术背后的暖心劝诫
您需要登录后才可以回帖 登录 | 立即注册

手机版|小黑屋|网站地图|云栈社区 ( 苏ICP备2022046150号-2 )

GMT+8, 2026-4-15 05:41 , Processed in 0.745013 second(s), 39 queries , Gzip On.

Powered by Discuz! X3.5

© 2025-2026 云栈社区.

快速回复 返回顶部 返回列表