1. 项目概述当你的Linux服务器“发烧”了最近在线上处理一个告警一台跑着核心服务的CentOS服务器CPU使用率突然飙到了95%以上并且持续不下。告警邮件滴滴响个不停业务方已经开始反馈接口响应变慢了。这种场景相信无论是运维、开发还是系统管理员都或多或少遇到过。服务器CPU“发烧”就像人发高烧一样是系统内部出现问题的强烈信号。如果处理不及时轻则服务卡顿重则直接宕机影响线上业务。Linux系统以其稳定高效著称但正因为其复杂性当CPU使用率异常飙升时定位问题的根源往往不像看仪表盘那么简单。你可能看到top命令里某个进程的CPU占用率很高但它是罪魁祸首吗还是说它只是一个“受害者”高CPU使用率的背后可能是糟糕的代码逻辑、失控的线程、死循环、锁竞争甚至是外部攻击。盲目地重启进程或服务器虽然可能暂时解决问题但无异于“头痛医头脚痛医脚”根本原因没有找到问题迟早会卷土重来。因此掌握一套系统性的、层层递进的CPU使用率排查方法是每一个Linux使用者的必备技能。这不仅仅是运行几个命令更是一种解决问题的逻辑和思路。今天我就结合自己多次“救火”的经验从头到尾梳理一遍在Linux下当CPU使用率过高时我们应该如何像侦探一样抽丝剥茧找到真正的“元凶”。整个过程我们会从宏观到微观从现象到本质使用最经典也最有效的工具链。2. 排查思路与工具总览建立你的诊断工具箱面对CPU高负载最忌讳的就是毫无章法地乱试命令。一个清晰的排查思路能让你事半功倍。我的排查逻辑通常遵循以下路径确认现象 - 定位进程 - 深入线程 - 分析调用 - 结合日志。2.1 核心排查逻辑首先我们需要明确一点top或htop命令中看到的“%CPU”超过100%是正常的吗对于多核CPU来说这个百分比是“CPU时间片”的占用率。如果一个单线程进程在一个核上跑满了它的CPU占用率就是100%。如果一个多线程进程的多个线程分别在多个核上跑满那么它的总CPU占用率可能就是 核数 * 100%。例如在4核CPU上一个进程的CPU占用率达到400%意味着它几乎吃满了所有CPU资源。所以看到超过100%的数字不要惊慌先除以CPU核心数看看是否真的“过载”。整个排查过程可以形象地比喻成一次“医疗诊断”量体温确认全局状态使用top、uptime、vmstat快速查看系统整体负荷确认是不是CPU的问题以及问题的严重程度。拍X光定位问题器官/进程使用top、ps、pidstat找出是哪个或哪些进程消耗了最多的CPU资源。做CT深入细胞/线程对于可疑进程使用top -H、pidstat -t或ps -eLf查看其内部的线程情况因为往往是某个线程在“作怪”。血管造影分析血液流动/函数调用使用perf、strace、pstack等工具分析高CPU线程到底在执行什么代码卡在哪个函数调用上。查病历结合日志最后将上述工具的分析结果与应用程序日志、系统日志/var/log/messagesjournalctl进行交叉验证形成完整的证据链。2.2 工具选型与准备工欲善其事必先利其器。以下是我排查时最常用的一套工具大多数都默认集成在主流Linux发行版中少数需要简单安装。工具名称主要用途安装方式如未预装关键特点top / htop实时监控系统整体状态和进程列表。通常预装。htop需安装yum install htop或apt install htoptop经典全能htop界面更友好支持鼠标操作和树状视图。vmstat查看系统虚拟内存、进程、CPU等整体状态。预装属于procps或procps-ng包。可以间隔采样观察变化趋势特别适合看上下文切换cs和中断in。pidstat监控进程及线程的详细资源统计CPU、内存、IO等。属于sysstat工具包yum install sysstat或apt install sysstat功能强大可以按时间间隔输出便于记录和分析。ps显示当前进程快照。预装。命令选项组合千变万化是获取进程详细信息的基础。perfLinux性能分析神器可以进行函数级采样。通常预装或在内核工具包中yum install perf或apt install linux-tools-common linux-tools-$(uname -r)功能极强可以生成火焰图直观展示CPU时间消耗在哪些函数上。strace跟踪进程的系统调用和信号。通常预装yum install strace或apt install strace适用于分析进程为什么卡住、频繁进行何种系统调用如频繁读文件。pstack/gstack打印进程的线程堆栈信息。通常预装pstack可能是gdb包的一部分。快速查看进程所有线程在做什么但可能需进程带有调试符号。sar系统活动报告器查看历史性能数据。属于sysstat工具包。需要配置并启动sadc服务来收集数据用于事后回顾分析。journalctl查询systemd日志系统。预装systemd系统。统一查看系统和服务日志与性能问题时间点关联。提示在生产环境操作前如果条件允许最好在测试环境熟悉这些命令。某些命令如perf、strace可能会带来轻微的性能开销或在某些安全策略严格的环境下执行受限。3. 第一步全局监控与初步定位当告警响起我们首先需要登录服务器对系统的健康状况做一个快速的“全身检查”。这一步的目标是确认CPU高使用的现象并初步判断问题的类型和范围。3.1 使用 top/htop 进行实时总览第一个命令十有八九是top。直接输入top你会看到类似下面的动态界面top - 14:30:01 up 30 days, 1:45, 2 users, load average: 8.32, 5.21, 3.15 Tasks: 256 total, 1 running, 255 sleeping, 0 stopped, 0 zombie %Cpu(s): 95.6 us, 3.2 sy, 0.0 ni, 1.0 id, 0.0 wa, 0.0 hi, 0.2 si, 0.0 st MiB Mem : 15982.8 total, 1024.5 free, 8192.3 used, 6765.9 buff/cache MiB Swap: 2048.0 total, 2048.0 free, 0.0 used. 6988.4 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME COMMAND 12345 appuser 20 0 12.3g 2.1g 1.8g S 450.2 13.5 300:15.89 java 6789 mysql 20 0 15.6g 5.2g 4.8g S 25.5 33.3 200:45.12 mysqld ...以下省略...这里我们需要关注几个关键信息第一行load average: 系统平均负载。三个值分别代表过去1分钟、5分钟、15分钟的平均负载。如果这个值持续高于你的CPU核心数可以用nproc命令查看说明系统负载过重。例如4核机器负载长期在8以上肯定有问题。第三行%Cpu(s):这是黄金指标。us(user): CPU在用户态运行的时间百分比。高us通常意味着应用程序自身的代码逻辑消耗了大量CPU比如业务计算、序列化/反序列化。sy(system): CPU在内核态运行的时间百分比。高sy可能意味着系统调用频繁或者内核自身在处理某些任务如网络包处理、内存管理。如果sy异常高需要警惕。wa(iowait): CPU等待I/O通常是磁盘I/O完成的时间百分比。高wa说明磁盘可能是瓶颈CPU在空等。这时虽然CPU使用率数字可能不高但系统响应已经非常慢了。id(idle): CPU空闲百分比。这个值越低说明CPU越忙。进程列表: 默认按CPU使用率降序排序。一眼就能看到哪个进程是“消耗大户”。比如上面的例子一个Java进程占用了450%的CPU这在一个4核机器上几乎吃满了所有资源它就是首要怀疑对象。实操心得我强烈推荐使用htop替代默认的top。它颜色分明支持鼠标点击表头排序更重要的是按F2进入设置可以直观地添加或删除监控列如线程数、进程状态等。按F5还可以以树状形式显示进程关系这对于分析像Java这类会派生很多子进程/线程的应用特别有用。3.2 使用 vmstat 观察系统整体指标top给了我们一个瞬间的快照而vmstat则能提供一个随时间变化的趋势视图。命令vmstat 1 5表示每秒采样一次共采样5次。$ vmstat 1 5 procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 8 0 0 1024524 204800 5668900 0 0 0 12 1056 89045 92 8 0 0 0 7 0 0 1024500 204800 5668904 0 0 0 8 1201 93456 90 9 1 0 0 ...后续几行类似...重点关注这些列procs部分的r(runable): 运行队列的长度即正在运行和等待CPU的进程数。如果这个值长期大于CPU核心数说明CPU资源严重不足进程在排队。system部分的cs(context switch): 每秒上下文切换的次数。上下文切换本身有开销如果这个值异常高例如每秒几十万次可能意味着有大量线程在争抢CPU或者发生了不必要的中断。cpu部分: 和top中的含义一致可以动态观察ussywa的变化。3.3 使用 uptime 和 mpstat 快速验证uptime命令输出信息简洁主要看平均负载。mpstat -P ALL 1则可以查看每个CPU核心的详细使用情况这在排查CPU使用不均比如某个核被跑满其他核却很闲的问题时非常有用可能指向了线程调度或程序并发设计的问题。通过以上几步我们基本可以回答CPU是不是真的高了高在用户态还是内核态有没有I/O等待哪个进程嫌疑最大有了这些答案我们就可以进入下一步对嫌疑进程进行“解剖”。4. 第二步深入嫌疑进程与线程分析找到了消耗CPU最多的进程假设PID是12345但这只是开始。一个现代应用尤其是Java、Nginx、数据库等服务都是多线程的。我们需要知道是这个进程的所有线程都在忙还是其中某一个或几个“野马”线程脱缰了。4.1 使用 top 监控特定进程的线程在top界面中按ShiftH可以切换显示线程模式在htop中按F2设置在“显示选项”里打开“树状视图”和“显示用户进程线程”会更直观。或者直接启动top时指定进程IDtop -H -p 12345。这样显示的就是进程12345内部的所有线程并按CPU使用率排序。top - 14:35:01 up 30 days, 1:50, 2 users, load average: 8.10, 5.85, 3.45 Threads: 45 total, 8 running, 37 sleeping, 0 stopped, 0 zombie %Cpu(s): 94.5 us, 4.1 sy, 0.0 ni, 1.4 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st KiB Mem : 16366208 total, 1048568 free, 8388608 used, 6929032 buff/cache KiB Swap: 2097148 total, 2097148 free, 0 used. 7159804 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME COMMAND 12367 appuser 20 0 12.3g 2.1g 1.8g R 99.8 13.5 150:30.15 java 12368 appuser 20 0 12.3g 2.1g 1.8g R 99.5 13.5 149:45.22 java 12345 appuser 20 0 12.3g 2.1g 1.8g S 0.0 13.5 0:00.01 java ...其他线程...看我们发现这个Java进程下有两个线程PID 12367和12368各自占用了近100%的CPU。这很可能就是问题的直接根源。记下这两个高CPU线程的PID。4.2 使用 pidstat 进行更专业的进程/线程监控pidstat是sysstat工具包里的利器它能提供更丰富和周期性的数据。监控特定进程的CPU使用包括其线程$ pidstat -p 12345 1 5 Linux 5.4.0-... 2024-05-20 _x86_64_ (4 CPU) 14:36:01 UID PID %usr %system %guest %wait %CPU CPU Command 14:36:02 1000 12345 85.00 10.00 0.00 0.00 95.00 2 java ...每秒输出一行...如果想看该进程下所有线程的详细情况加上-t参数$ pidstat -t -p 12345 1 3 ...输出会显示每个线程的TID和CPU占用...pidstat的输出可以很方便地重定向到文件用于后续分析。4.3 使用 ps 命令获取线程快照ps命令虽然是一次性快照但在某些环境下可能更便捷。要查看一个进程的所有线程可以使用$ ps -eLf | grep 12345或者更精确地$ ps -T -p 12345 PID SPID TTY TIME CMD 12345 12345 ? 00:00:00 java 12345 12367 ? 02:30:30 java 12345 12368 ? 02:29:45 java ...其中SPID列就是线程IDLWP, Light Weight Process对应我们在top -H里看到的PID。TIME列显示了该线程累积占用的CPU时间长时间运行且TIME很高的线程值得怀疑。4.4 将线程ID转换为可读信息针对Java应用对于Java应用我们拿到了高CPU线程的ID如12367但这只是一个数字。我们需要知道这个线程在Java世界里是做什么的。这里需要一个关键转换将操作系统线程IDOS PID转换为Java线程ID或名称。首先用jstack命令获取Java进程的线程堆栈信息$ jstack 12345 /tmp/jstack.12345.log然后在输出的堆栈文件中线程的nidnative thread ID是十六进制的。我们需要将十进制的操作系统线程ID12367转换为十六进制。$ printf %x\n 12367 3047现在在jstack.12345.log文件中搜索nid0x3047你就能找到对应的Java线程堆栈看到它正在执行哪个类的哪个方法。例如你可能会发现它卡在某个while(true)循环或者正在执行一个非常耗时的计算操作。注意jstack可能会因为安全管理器配置或进程挂起如进入GC而执行失败或卡住。在生产环境要小心使用并考虑使用jcmdJDK 7作为替代jcmd 12345 Thread.print。通过这一步我们成功地将问题从“某个Java进程CPU高”缩小到了“该Java进程中nid0x3047的‘某业务计算线程’CPU高”。接下来就需要用更精细的工具看看这个线程到底在执行什么。5. 第三步代码级剖析与根因定位知道了是哪个线程在疯狂消耗CPU我们还需要知道它为什么消耗这么多CPU。是陷入了死循环是在进行密集计算还是在频繁地进行某种系统调用这时候就需要用到更底层的分析工具。5.1 使用 perf 进行性能采样与火焰图分析perf是Linux内核自带的性能分析工具功能非常强大。对于分析高CPU问题最常用的命令是perf top和perf record。实时热点分析 (perf top): 像top一样实时显示系统中消耗CPU最多的函数。执行sudo perf top -p 12345可以只监控特定进程。你会看到类似下面的输出直接告诉你CPU周期用在了哪个内核函数或用户态函数上。这对于快速定位是应用代码问题还是内核问题非常有效。采样记录与火焰图 (perf recordperf report): 这是更精确的分析方法。# 对进程12345采样30秒 $ sudo perf record -F 99 -g -p 12345 -- sleep 30 # 查看报告 $ sudo perf report -n --stdio这个报告会展示一个调用链你可以清晰地看到CPU时间从入口函数开始是如何层层分配下去的。消耗时间占比最大的函数链就是性能热点。为了更直观我们可以生成火焰图Flame Graph。火焰图是性能分析的“核武器”它通过可视化的方式将perf采集的堆栈信息呈现出来横向表示时间占比纵向表示调用栈深度。一个又宽又平的“平板”通常就是热点。生成火焰图需要Brendan Gregg的脚本大致步骤是perf record采集数据。perf script将数据转换为中间格式。使用stackcollapse-perf.pl脚本折叠堆栈。使用flamegraph.pl脚本生成SVG格式的火焰图。 打开SVG图用浏览器即可交互式查看鼠标悬浮在任何一块“火焰”上都能看到对应的函数名和采样占比。一眼就能找到最宽的那块“火焰”那就是CPU消耗的罪魁祸首。5.2 使用 strace 跟踪系统调用如果perf显示热点在某个系统调用如read,write,poll,futex上或者你怀疑进程因为频繁的I/O或锁竞争导致CPU高表现为sy或us高那么strace就派上用场了。strace可以跟踪进程执行的所有系统调用和接收到的信号。跟踪一个高CPU线程$ sudo strace -p 12367 -c运行一段时间后按CtrlC它会统计这段时间内各种系统调用的次数、耗时和错误。如果你看到某个系统调用比如futex被调用了数百万次平均每次调用时间也很短但总耗时却很长这就可能意味着存在激烈的锁竞争。或者看到大量的read/write在一个小文件上可能意味着配置错误或日志输出过于频繁。警告strace会显著拖慢被跟踪进程的速度因为它需要拦截每个系统调用。在生产环境对核心服务长时间使用要极其谨慎最好在流量低峰期或测试环境进行。5.3 使用 pstack/gstack 获取即时线程堆栈pstack或gstack命令可以立即打印出指定进程中所有线程的调用堆栈。它相当于给进程拍了一张“X光片”。$ sudo pstack 12345或者对于线程$ sudo gstack 12345输出会显示每个线程正在执行的函数调用链。如果某个线程卡在同一个函数上比如pthread_cond_wait或某个自旋锁循环那么它的堆栈信息在多次执行pstack后可能变化不大。这对于诊断死锁、死循环或长时间等待非常有用。它的优点是开销极小速度快缺点是需要进程带有调试符号debug symbols否则看到的可能是内存地址而不是函数名。5.4 结合应用程序日志与系统日志工具给出的都是技术指标而日志则提供了业务上下文。在发现高CPU线程对应的Java线程名后例如pool-1-thread-3立刻去翻看应用日志在那个时间点附近这个线程在做什么是不是在处理一个特别大的请求是不是触发了某个有问题的算法同时查看系统日志/var/log/messages或使用journalctl -f实时查看看看同一时间点有没有相关的错误或警告信息比如磁盘错误、网络超时、内存不足等这些都可能间接引发CPU问题。将工具分析结果如线程nid0x3047在频繁执行com.example.service.ExpensiveCalc.calculate()与日志信息如该时间点正在处理用户IDXXX的请求结合起来你就能完整地还原出问题现场“在14:30分左右处理用户XXX的请求时ExpensiveCalc.calculate方法陷入了某种低效循环或复杂计算导致两个线程持续满负载运行进而拖垮了整个服务的CPU。”6. 常见问题场景与实战排查技巧理论讲完了我们来点“实战干货”。下面是我在多年运维和开发工作中遇到的几种典型的高CPU场景及其排查思路。你可以把它们当作一个速查手册。6.1 场景一用户态CPU使用率 (us) 异常高现象top显示%Cpu(s)行us值长期在80%以上某个应用进程如Java PythonCPU占用率极高。可能原因业务逻辑存在低效算法或死循环例如未经优化的多层嵌套循环、正则表达式灾难性回溯、大列表的线性查找等。频繁的序列化/反序列化在处理JSON、XML或Protobuf数据时如果数据量巨大或操作频繁。垃圾回收GC过于频繁对于Java应用如果GC算法不当或内存配置不合理会导致GC线程频繁工作消耗大量CPU。这时us和sy可能都高。代码中的“忙等待”Busy Waiting线程通过循环不断检查某个条件而不是通过等待/通知机制白白浪费CPU。排查技巧首要步骤使用top -H找到该进程下的高CPU线程。针对Java用jstack获取线程堆栈将线程ID转换为十六进制后搜索。重点查找RUNNABLE状态的线程看其堆栈是否停留在某个业务方法内。同时使用jstat -gcutil pid 1s观察GC情况如果FGCFull GC次数或FGCTFull GC时间在短时间内快速增长则GC是元凶。通用方法使用perf record采样该进程生成火焰图。火焰图上最宽的那块“平顶山”就是消耗CPU最多的函数链。结合代码审查优化该函数。一个快速命令sudo perf top -p pid可以实时观察进程内的函数热点快速定位。6.2 场景二系统态CPU使用率 (sy) 异常高现象%Cpu(s)行sy值异常高例如超过30%可能伴随us不高。可能原因频繁的系统调用应用过于频繁地执行read/write特别是小文件、stat、gettimeofday等调用。上下文切换过多vmstat中cs值极高。可能是进程/线程数过多超过CPU核心数太多或者不合理的锁竞争导致线程频繁挂起和唤醒。中断处理特别是网络或磁盘I/O中断。如果服务器正在处理大量网络小包或磁盘随机读写内核中断处理会消耗不少CPU。内存管理开销如果系统内存不足频繁的页交换swap会导致sy升高同时waiowait也会升高。排查技巧查看上下文切换vmstat 1看cs列pidstat -w 1看进程级别的自愿cswch/s和非自愿nvcswch/s上下文切换次数。非自愿切换过多通常意味着CPU资源竞争激烈。使用strace统计系统调用sudo strace -c -p pid结束后看哪种系统调用次数最多。优化代码减少不必要的系统调用如缓存文件状态、批量读写。使用perf看内核热点sudo perf top可以看到内核函数的消耗。如果看到_raw_spin_lock、schedule等函数排名靠前说明锁竞争或调度开销大。检查中断cat /proc/interrupts可以查看各CPU核心的中断分布。如果某个网卡中断特别集中可以考虑使用irqbalance服务或手动设置中断亲和性SMP affinity来平衡负载。6.3 场景三I/O等待高 (wa) 导致系统慢但CPU使用率不高现象系统响应极慢但top看CPU的id空闲可能还不低而waiowait却很高如超过20%。可能原因磁盘性能瓶颈磁盘读写速度跟不上请求速度可能是磁盘本身慢如机械硬盘也可能是RAID卡策略问题或者是某个进程在进行大量顺序/随机写。内存不足频繁交换当物理内存不足时系统会使用swap分区导致磁盘I/O飙升。此时siswap in和soswap out也会很高。同步写入日志应用程序配置了同步写日志如MySQL的innodb_flush_log_at_trx_commit1在高并发写入时会导致磁盘I/O等待。排查技巧使用iostat查看磁盘I/Oiostat -x 1关注%util设备利用率接近100%表示饱和和await平均每次I/O等待时间。找到是哪个磁盘如sda忙。使用iotop定位I/O大户进程类似top但是看进程的I/O读写情况。sudo iotop可以快速找到哪个进程在疯狂读写磁盘。检查内存和Swapfree -h看内存使用vmstat 1看si/so。如果si/so持续大于0说明正在发生交换需要优化应用内存使用或增加物理内存。检查文件系统缓存Linux会利用空闲内存做文件缓存buff/cache。有时free内存显示很少但大部分是缓存这是正常且有益的。真正的压力指标是available内存。6.4 场景四僵尸进程与短时进程风暴现象load average很高但top里看不到明显的高CPU进程。或者看到大量进程不断产生和消失。可能原因僵尸进程Zombie子进程退出后父进程没有正确调用wait()回收其资源导致进程描述符残留。少量僵尸进程影响不大但大量僵尸进程会占用进程ID资源。短时进程风暴例如Shell脚本中错误地在循环里频繁调用外部命令如grep,awk或者Web服务器配置错误对每个请求都fork一个新进程来处理而不是使用线程或复用进程。排查技巧查看僵尸进程top命令中Tasks一行会显示zombie的数量。使用ps aux | grep Z或ps -ef | grep defunct可以列出僵尸进程及其父进程IDPPID。解决方法是终止其父进程需要谨慎让init进程回收僵尸。使用execsnoop或perf跟踪进程创建execsnoop来自bcc-tools可以实时跟踪exec()系统调用发现那些瞬间启动又退出的短命进程。perf也可以用来跟踪sched_process_exec和sched_process_exit事件。检查进程树使用pstree -p pid或htop的树状视图查看是否有异常的进程派生模式。7. 性能问题排查工具箱的日常维护与进阶思考排查CPU问题不是一锤子买卖而应该是一种常态化的能力建设。除了事后的“救火”我们更应该注重事前的“防火”和事中的“监控”。7.1 建立性能基准与监控告警在系统健康的时候就应该建立性能基准。使用像node_exporter、collectd这样的代理配合Prometheus和Grafana持续采集关键指标CPU使用率分us/sy等、负载、内存、磁盘I/O、网络流量、关键进程资源占用等。为这些指标设置合理的告警阈值例如CPU使用率持续5分钟85%或负载持续高于核心数的2倍。这样问题在变得严重之前就能被发现。7.2 使用更高级的BPF/eBPF工具对于现代Linux内核4.x以上eBPF技术提供了更强大、更高效的内核追踪能力。Brendan Gregg创建的bcc和bpftrace工具集包含了许多现成的利器开销极低非常适合生产环境cpuunclaimed: 查看CPU空闲时间在哪。runqlat: 分析进程在运行队列中等待调度的时间。offcputime: 分析进程不在CPU上运行的时间即被阻塞或等待的时间并以火焰图形式展示对于查找性能延迟瓶颈非常有用。biolatency,biosnoop: 分析块设备I/O的延迟和请求。学习和使用这些工具能将你的排查能力提升到一个新的维度。7.3 容器化环境下的排查差异在Docker或Kubernetes环境中排查思路不变但命令的执行环境需要注意。进入容器docker exec -it container_id /bin/bash或kubectl exec -it pod_name -- /bin/bash。查看容器进程在宿主机上容器的进程是可见的。你可以用top、ps等工具查看但需要注意PID命名空间。更简单的是在容器内执行这些命令。工具安装容器镜像通常很精简可能没有perf、strace等工具。需要构建包含这些工具的自定义镜像或者在宿主机上使用nsenter命令进入容器的命名空间进行调试需要特权。资源限制容器可能设置了CPU限额cgroups。即使容器内进程显示CPU使用率100%它可能只占用了宿主机一个核心的50%。需要结合docker stats或kubectl top命令查看容器级别的资源使用情况。7.4 编写自动化排查脚本对于反复出现的某类问题可以编写简单的Shell脚本来自动化初步排查。例如一个脚本可以自动执行top、vmstat、pidstat并将结果输出到文件甚至通过邮件发送。这能在问题发生时为你保留第一时间的现场信息。排查CPU高使用率问题是一个从宏观到微观、从现象到本质的推理过程。它考验的不仅是命令的熟悉程度更是对系统原理、应用架构的深入理解。每一次成功的排查都是对系统认知的一次深化。记住没有“银弹”最好的工具是你的逻辑思维和对系统的好奇心。多实践多总结下次再遇到服务器“发烧”你就能从容应对手到病除。 1. 项目概述当你的Linux服务器“发烧”了最近在线上处理一个告警一台跑着核心服务的CentOS服务器CPU使用率突然飙到了95%以上并且持续不下。告警邮件滴滴响个不停业务方已经开始反馈接口响应变慢了。这种场景相信无论是运维、开发还是系统管理员都或多或少遇到过。服务器CPU“发烧”就像人发高烧一样是系统内部出现问题的强烈信号。如果处理不及时轻则服务卡顿重则直接宕机影响线上业务。Linux系统以其稳定高效著称但正因为其复杂性当CPU使用率异常飙升时定位问题的根源往往不像看仪表盘那么简单。你可能看到top命令里某个进程的CPU占用率很高但它是罪魁祸首吗还是说它只是一个“受害者”高CPU使用率的背后可能是糟糕的代码逻辑、失控的线程、死循环、锁竞争甚至是外部攻击。盲目地重启进程或服务器虽然可能暂时解决问题但无异于“头痛医头脚痛医脚”根本原因没有找到问题迟早会卷土重来。因此掌握一套系统性的、层层递进的CPU使用率排查方法是每一个Linux使用者的必备技能。这不仅仅是运行几个命令更是一种解决问题的逻辑和思路。今天我就结合自己多次“救火”的经验从头到尾梳理一遍在Linux下当CPU使用率过高时我们应该如何像侦探一样抽丝剥茧找到真正的“元凶”。整个过程我们会从宏观到微观从现象到本质使用最经典也最有效的工具链。2. 排查思路与工具总览建立你的诊断工具箱面对CPU高负载最忌讳的就是毫无章法地乱试命令。一个清晰的排查思路能让你事半功倍。我的排查逻辑通常遵循以下路径确认现象 - 定位进程 - 深入线程 - 分析调用 - 结合日志。2.1 核心排查逻辑首先我们需要明确一点top或htop命令中看到的“%CPU”超过100%是正常的吗对于多核CPU来说这个百分比是“CPU时间片”的占用率。如果一个单线程进程在一个核上跑满了它的CPU占用率就是100%。如果一个多线程进程的多个线程分别在多个核上跑满那么它的总CPU占用率可能就是 核数 * 100%。例如在4核CPU上一个进程的CPU占用率达到400%意味着它几乎吃满了所有CPU资源。所以看到超过100%的数字不要惊慌先除以CPU核心数看看是否真的“过载”。整个排查过程可以形象地比喻成一次“医疗诊断”量体温确认全局状态使用top、uptime、vmstat快速查看系统整体负荷确认是不是CPU的问题以及问题的严重程度。拍X光定位问题器官/进程使用top、ps、pidstat找出是哪个或哪些进程消耗了最多的CPU资源。做CT深入细胞/线程对于可疑进程使用top -H、pidstat -t或ps -eLf查看其内部的线程情况因为往往是某个线程在“作怪”。血管造影分析血液流动/函数调用使用perf、strace、pstack等工具分析高CPU线程到底在执行什么代码卡在哪个函数调用上。查病历结合日志最后将上述工具的分析结果与应用程序日志、系统日志/var/log/messagesjournalctl进行交叉验证形成完整的证据链。2.2 工具选型与准备工欲善其事必先利其器。以下是我排查时最常用的一套工具大多数都默认集成在主流Linux发行版中少数需要简单安装。工具名称主要用途安装方式如未预装关键特点top / htop实时监控系统整体状态和进程列表。通常预装。htop需安装yum install htop或apt install htoptop经典全能htop界面更友好支持鼠标操作和树状视图。vmstat查看系统虚拟内存、进程、CPU等整体状态。预装属于procps或procps-ng包。可以间隔采样观察变化趋势特别适合看上下文切换cs和中断in。pidstat监控进程及线程的详细资源统计CPU、内存、IO等。属于sysstat工具包yum install sysstat或apt install sysstat功能强大可以按时间间隔输出便于记录和分析。ps显示当前进程快照。预装。命令选项组合千变万化是获取进程详细信息的基础。perfLinux性能分析神器可以进行函数级采样。通常预装或在内核工具包中yum install perf或apt install linux-tools-common linux-tools-$(uname -r)功能极强可以生成火焰图直观展示CPU时间消耗在哪些函数上。strace跟踪进程的系统调用和信号。通常预装yum install strace或apt install strace适用于分析进程为什么卡住、频繁进行何种系统调用如频繁读文件。pstack/gstack打印进程的线程堆栈信息。通常预装pstack可能是gdb包的一部分。快速查看进程所有线程在做什么但可能需进程带有调试符号。sar系统活动报告器查看历史性能数据。属于sysstat工具包。需要配置并启动sadc服务来收集数据用于事后回顾分析。journalctl查询systemd日志系统。预装systemd系统。统一查看系统和服务日志与性能问题时间点关联。提示在生产环境操作前如果条件允许最好在测试环境熟悉这些命令。某些命令如perf、strace可能会带来轻微的性能开销或在某些安全策略严格的环境下执行受限。3. 第一步全局监控与初步定位当告警响起我们首先需要登录服务器对系统的健康状况做一个快速的“全身检查”。这一步的目标是确认CPU高使用的现象并初步判断问题的类型和范围。3.1 使用 top/htop 进行实时总览第一个命令十有八九是top。直接输入top你会看到类似下面的动态界面top - 14:30:01 up 30 days, 1:45, 2 users, load average: 8.32, 5.21, 3.15 Tasks: 256 total, 1 running, 255 sleeping, 0 stopped, 0 zombie %Cpu(s): 95.6 us, 3.2 sy, 0.0 ni, 1.0 id, 0.0 wa, 0.0 hi, 0.2 si, 0.0 st MiB Mem : 15982.8 total, 1024.5 free, 8192.3 used, 6765.9 buff/cache MiB Swap: 2048.0 total, 2048.0 free, 0.0 used. 6988.4 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME COMMAND 12345 appuser 20 0 12.3g 2.1g 1.8g S 450.2 13.5 300:15.89 java 6789 mysql 20 0 15.6g 5.2g 4.8g S 25.5 33.3 200:45.12 mysqld ...以下省略...这里我们需要关注几个关键信息第一行load average: 系统平均负载。三个值分别代表过去1分钟、5分钟、15分钟的平均负载。如果这个值持续高于你的CPU核心数可以用nproc命令查看说明系统负载过重。例如4核机器负载长期在8以上肯定有问题。第三行%Cpu(s):这是黄金指标。us(user): CPU在用户态运行的时间百分比。高us通常意味着应用程序自身的代码逻辑消耗了大量CPU比如业务计算、序列化/反序列化。sy(system): CPU在内核态运行的时间百分比。高sy可能意味着系统调用频繁或者内核自身在处理某些任务如网络包处理、内存管理。如果sy异常高需要警惕。wa(iowait): CPU等待I/O通常是磁盘I/O完成的时间百分比。高wa说明磁盘可能是瓶颈CPU在空等。这时虽然CPU使用率数字可能不高但系统响应已经非常慢了。id(idle): CPU空闲百分比。这个值越低说明CPU越忙。进程列表: 默认按CPU使用率降序排序。一眼就能看到哪个进程是“消耗大户”。比如上面的例子一个Java进程占用了450%的CPU这在一个4核机器上几乎吃满了所有资源它就是首要怀疑对象。实操心得我强烈推荐使用htop替代默认的top。它颜色分明支持鼠标点击表头排序更重要的是按F2进入设置可以直观地添加或删除监控列如线程数、进程状态等。按F5还可以以树状形式显示进程关系这对于分析像Java这类会派生很多子进程/线程的应用特别有用。3.2 使用 vmstat 观察系统整体指标top给了我们一个瞬间的快照而vmstat则能提供一个随时间变化的趋势视图。命令vmstat 1 5表示每秒采样一次共采样5次。$ vmstat 1 5 procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 8 0 0 1024524 204800 5668900 0 0 0 12 1056 89045 92 8 0 0 0 7 0 0 1024500 204800 5668904 0 0 0 8 1201 93456 90 9 1 0 0 ...后续几行类似...重点关注这些列procs部分的r(runable): 运行队列的长度即正在运行和等待CPU的进程数。如果这个值长期大于CPU核心数说明CPU资源严重不足进程在排队。system部分的cs(context switch): 每秒上下文切换的次数。上下文切换本身有开销如果这个值异常高例如每秒几十万次可能意味着有大量线程在争抢CPU或者发生了不必要的中断。cpu部分: 和top中的含义一致可以动态观察ussywa的变化。3.3 使用 uptime 和 mpstat 快速验证uptime命令输出信息简洁主要看平均负载。mpstat -P ALL 1则可以查看每个CPU核心的详细使用情况这在排查CPU使用不均比如某个核被跑满其他核却很闲的问题时非常有用可能指向了线程调度或程序并发设计的问题。通过以上几步我们基本可以回答CPU是不是真的高了高在用户态还是内核态有没有I/O等待哪个进程嫌疑最大有了这些答案我们就可以进入下一步对嫌疑进程进行“解剖”。4. 第二步深入嫌疑进程与线程分析找到了消耗CPU最多的进程假设PID是12345但这只是开始。一个现代应用尤其是Java、Nginx、数据库等服务都是多线程的。我们需要知道是这个进程的所有线程都在忙还是其中某一个或几个“野马”线程脱缰了。4.1 使用 top 监控特定进程的线程在top界面中按ShiftH可以切换显示线程模式在htop中按F2设置在“显示选项”里打开“树状视图”和“显示用户进程线程”会更直观。或者直接启动top时指定进程IDtop -H -p 12345。这样显示的就是进程12345内部的所有线程并按CPU使用率排序。top - 14:35:01 up 30 days, 1:50, 2 users, load average: 8.10, 5.85, 3.45 Threads: 45 total, 8 running, 37 sleeping, 0 stopped, 0 zombie %Cpu(s): 94.5 us, 4.1 sy, 0.0 ni, 1.4 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st KiB Mem : 16366208 total, 1048568 free, 8388608 used, 6929032 buff/cache KiB Swap: 2097148 total, 2097148 free, 0 used. 7159804 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME COMMAND 12367 appuser 20 0 12.3g 2.1g 1.8g R 99.8 13.5 150:30.15 java 12368 appuser 20 0 12.3g 2.1g 1.8g R 99.5 13.5 149:45.22 java 12345 appuser 20 0 12.3g 2.1g 1.8g S 0.0 13.5 0:00.01 java ...其他线程...看我们发现这个Java进程下有两个线程PID 12367和12368各自占用了近100%的CPU。这很可能就是问题的直接根源。记下这两个高CPU线程的PID。4.2 使用 pidstat 进行更专业的进程/线程监控pidstat是sysstat工具包里的利器它能提供更丰富和周期性的数据。监控特定进程的CPU使用包括其线程$ pidstat -p 12345 1 5 Linux 5.4.0-... 2024-05-20 _x86_64_ (4 CPU) 14:36:01 UID PID %usr %system %guest %wait %CPU CPU Command 14:36:02 1000 12345 85.00 10.00 0.00 0.00 95.00 2 java ...每秒输出一行...如果想看该进程下所有线程的详细情况加上-t参数$ pidstat -t -p 12345 1 3 ...输出会显示每个线程的TID和CPU占用...pidstat的输出可以很方便地重定向到文件用于后续分析。4.3 使用 ps 命令获取线程快照ps命令虽然是一次性快照但在某些环境下可能更便捷。要查看一个进程的所有线程可以使用$ ps -eLf | grep 12345或者更精确地$ ps -T -p 12345 PID SPID TTY TIME CMD 12345 12345 ? 00:00:00 java 12345 12367 ? 02:30:30 java 12345 12368 ? 02:29:45 java ...其中SPID列就是线程IDLWP, Light Weight Process对应我们在top -H里看到的PID。TIME列显示了该线程累积占用的CPU时间长时间运行且TIME很高的线程值得怀疑。4.4 将线程ID转换为可读信息针对Java应用对于Java应用我们拿到了高CPU线程的ID如12367但这只是一个数字。我们需要知道这个线程在Java世界里是做什么的。这里需要一个关键转换将操作系统线程IDOS PID转换为Java线程ID或名称。首先用jstack命令获取Java进程的线程堆栈信息$ jstack 12345 /tmp/jstack.12345.log然后在输出的堆栈文件中线程的nidnative thread ID是十六进制的。我们需要将十进制的操作系统线程ID12367转换为十六进制。$ printf %x\n 12367 3047现在在jstack.12345.log文件中搜索nid0x3047你就能找到对应的Java线程堆栈看到它正在执行哪个类的哪个方法。例如你可能会发现它卡在某个while(true)循环或者正在执行一个非常耗时的计算操作。注意jstack可能会因为安全管理器配置或进程挂起如进入GC而执行失败或卡住。在生产环境要小心使用并考虑使用jcmdJDK 7作为替代jcmd 12345 Thread.print。通过这一步我们成功地将问题从“某个Java进程CPU高”缩小到了“该Java进程中nid0x3047的‘某业务计算线程’CPU高”。接下来就需要用更精细的工具看看这个线程到底在执行什么。5. 第三步代码级剖析与根因定位知道了是哪个线程在疯狂消耗CPU我们还需要知道它为什么消耗这么多CPU。是陷入了死循环是在进行密集计算还是在频繁地进行某种系统调用这时候就需要用到更底层的分析工具。5.1 使用 perf 进行性能采样与火焰图分析perf是Linux内核自带的性能分析工具功能非常强大。对于分析高CPU问题最常用的命令是perf top和perf record。实时热点分析 (perf top): 像top一样实时显示系统中消耗CPU最多的函数。执行sudo perf top -p 12345可以只监控特定进程。你会看到类似下面的输出直接告诉你CPU周期用在了哪个内核函数或用户态函数上。这对于快速定位是应用代码问题还是内核问题非常有效。采样记录与火焰图 (perf recordperf report): 这是更精确的分析方法。# 对进程12345采样30秒 $ sudo perf record -F 99 -g -p 12345 -- sleep 30 # 查看报告 $ sudo perf report -n --stdio这个报告会展示一个调用链你可以清晰地看到CPU时间从入口函数开始是如何层层分配下去的。消耗时间占比最大的函数链就是性能热点。为了更直观我们可以生成火焰图Flame Graph。火焰图是性能分析的“核武器”它通过可视化的方式将perf采集的堆栈信息呈现出来横向表示时间占比纵向表示调用栈深度。一个又宽又平的“平板”通常就是热点。生成火焰图需要Brendan Gregg的脚本大致步骤是perf record采集数据。perf script将数据转换为中间格式。使用stackcollapse-perf.pl脚本折叠堆栈。使用flamegraph.pl脚本生成SVG格式的火焰图。 打开SVG图用浏览器即可交互式查看鼠标悬浮在任何一块“火焰”上都能看到对应的函数名和采样占比。一眼就能找到最宽的那块“火焰”那就是CPU消耗的罪魁祸首。5.2 使用 strace 跟踪系统调用如果perf显示热点在某个系统调用如read,write,poll,futex上或者你怀疑进程因为频繁的I/O或锁竞争导致CPU高表现为sy或us高那么strace就派上用场了。strace可以跟踪进程执行的所有系统调用和接收到的信号。跟踪一个高CPU线程$ sudo strace -p 12367 -c运行一段时间后按CtrlC它会统计这段时间内各种系统调用的次数、耗时和错误。如果你看到某个系统调用比如futex被调用了数百万次平均每次调用时间也很短但总耗时却很长这就可能意味着存在激烈的锁竞争。或者看到大量的read/write在一个小文件上可能意味着配置错误或日志输出过于频繁。警告strace会显著拖慢被跟踪进程的速度因为它需要拦截每个系统调用。在生产环境对核心服务长时间使用要极其谨慎最好在流量低峰期或测试环境进行。5.3 使用 pstack/gstack 获取即时线程堆栈pstack或gstack命令可以立即打印出指定进程中所有线程的调用堆栈。它相当于给进程拍了一张“X光片”。$ sudo pstack 12345或者对于线程$ sudo gstack 12345输出会显示每个线程正在执行的函数调用链。如果某个线程卡在同一个函数上比如pthread_cond_wait或某个自旋锁循环那么它的堆栈信息在多次执行pstack后可能变化不大。这对于诊断死锁、死循环或长时间等待非常有用。它的优点是开销极小速度快缺点是需要进程带有调试符号debug symbols否则看到的可能是内存地址而不是函数名。5.4 结合应用程序日志与系统日志工具给出的都是技术指标而日志则提供了业务上下文。在发现高CPU线程对应的Java线程名后例如pool-1-thread-3立刻去翻看应用日志在那个时间点附近这个线程在做什么是不是在处理一个特别大的请求是不是触发了某个有问题的算法同时查看系统日志/var/log/messages或使用journalctl -f实时查看看看同一时间点有没有相关的错误或警告信息比如磁盘错误、网络超时、内存不足等这些都可能间接引发CPU问题。将工具分析结果如线程nid0x3047在频繁执行com.example.service.ExpensiveCalc.calculate()与日志信息如该时间点正在处理用户IDXXX的请求结合起来你就能完整地还原出问题现场“在14:30分左右处理用户XXX的请求时ExpensiveCalc.calculate方法陷入了某种低效循环或复杂计算导致两个线程持续满负载运行进而拖垮了整个服务的CPU。”6. 常见问题场景与实战排查技巧理论讲完了我们来点“实战干货”。下面是我在多年运维和开发工作中遇到的几种典型的高CPU场景及其排查思路。你可以把它们当作一个速查手册。6.1 场景一用户态CPU使用率 (us) 异常高现象top显示%Cpu(s)行us值长期在80%以上某个应用进程如Java PythonCPU占用率极高。可能原因业务逻辑存在低效算法或死循环例如未经优化的多层嵌套循环、正则表达式灾难性回溯、大列表的线性查找等。频繁的序列化/反序列化在处理JSON、XML或Protobuf数据时如果数据量巨大或操作频繁。垃圾回收GC过于频繁对于Java应用如果GC算法不当或内存配置不合理会导致GC线程频繁工作消耗大量CPU。这时us和sy可能都高。代码中的“忙等待”Busy Waiting线程通过循环不断检查某个条件而不是通过等待/通知机制白白浪费CPU。排查技巧首要步骤使用top -H找到该进程下的高CPU线程。针对Java用jstack获取线程堆栈将线程ID转换为十六进制后搜索。重点查找RUNNABLE状态的线程看其堆栈是否停留在某个业务方法内。同时使用jstat -gcutil pid 1s观察GC情况如果FGCFull GC次数或FGCTFull GC时间在短时间内快速增长则GC是元凶。通用方法使用perf record采样该进程生成火焰图。火焰图上最宽的那块“平顶山”就是消耗CPU最多的函数链。结合代码审查优化该函数。一个快速命令sudo perf top -p pid可以实时观察进程内的函数热点快速定位。6.2 场景二系统态CPU使用率 (sy) 异常高现象%Cpu(s)行sy值异常高例如超过30%可能伴随us不高。可能原因频繁的系统调用应用过于频繁地执行read/write特别是小文件、stat、gettimeofday等调用。上下文切换过多vmstat中cs值极高。可能是进程/线程数过多超过CPU核心数太多或者不合理的锁竞争导致线程频繁挂起和唤醒。中断处理特别是网络或磁盘I/O中断。如果服务器正在处理大量网络小包或磁盘随机读写内核中断处理会消耗不少CPU。内存管理开销如果系统内存不足频繁的页交换swap会导致sy升高同时waiowait也会升高。排查技巧查看上下文切换vmstat 1看cs列pidstat -w 1看进程级别的自愿cswch/s和非自愿nvcswch/s上下文切换次数。非自愿切换过多通常意味着CPU资源竞争激烈。使用strace统计系统调用sudo strace -c -p pid结束后看哪种系统调用次数最多。优化代码减少不必要的系统调用如缓存文件状态、批量读写。使用perf看内核热点sudo perf top可以看到内核函数的消耗。如果看到_raw_spin_lock、schedule等函数排名靠前说明锁竞争或调度开销大。检查中断cat /proc/interrupts可以查看各CPU核心的中断分布。如果某个网卡中断特别集中可以考虑使用irqbalance服务或手动设置中断亲和性SMP affinity来平衡负载。6.3 场景三I/O等待高 (wa) 导致系统慢但CPU使用率不高现象系统响应极慢但top看CPU的id空闲可能还不低而waiowait却很高如超过20%。可能原因磁盘性能瓶颈磁盘读写速度跟不上请求速度可能是磁盘本身慢如机械硬盘也可能是RAID卡策略问题或者是某个进程在进行大量顺序/随机写。内存不足频繁交换当物理内存不足时系统会使用swap分区导致磁盘I/O飙升。此时siswap in和soswap out也会很高。同步写入日志应用程序配置了同步写日志如MySQL的innodb_flush_log_at_trx_commit1在高并发写入时会导致磁盘I/O等待。排查技巧使用iostat查看磁盘I/Oiostat -x 1关注%util设备利用率接近100%表示饱和和await平均每次I/O等待时间。找到是哪个磁盘如sda忙。使用iotop定位I/O大户进程类似top但是看进程的I/O读写情况。sudo iotop可以快速找到哪个进程在疯狂读写磁盘。检查内存和Swapfree -h看内存使用vmstat 1看si/so。如果si/so持续大于0说明正在发生交换需要优化应用内存使用或增加物理内存。检查文件系统缓存Linux会利用空闲内存做文件缓存buff/cache。有时free内存显示很少但大部分是缓存这是正常且有益的。真正的压力指标是available内存。6.4 场景四僵尸进程与短时进程风暴现象load average很高但top里看不到明显的高CPU进程。或者看到大量进程不断产生和消失。可能原因僵尸进程Zombie子进程退出后父进程没有正确调用wait()回收其资源导致进程描述符残留。少量僵尸进程影响不大但大量僵尸进程会占用进程ID资源。短时进程风暴例如Shell脚本中错误地在循环里频繁调用外部命令如grep,awk或者Web服务器配置错误对每个请求都fork一个新进程来处理而不是使用线程或复用进程。排查技巧查看僵尸进程top命令中Tasks一行会显示zombie的数量。使用ps aux | grep Z或ps -ef | grep defunct可以列出僵尸进程及其父进程IDPPID。解决方法是终止其父进程需要谨慎让init进程回收僵尸。使用execsnoop或perf跟踪进程创建execsnoop来自bcc-tools可以实时跟踪exec()系统调用发现那些瞬间启动又退出的短命进程。perf也可以用来跟踪sched_process_exec和sched_process_exit事件。检查进程树使用pstree -p pid或htop的树状视图查看是否有异常的进程派生模式。7. 性能问题排查工具箱的日常维护与进阶思考排查CPU问题不是一锤子买卖而应该是一种常态化的能力建设。除了事后的“救火”我们更应该注重事前的“防火”和事中的“监控”。7.1 建立性能基准与监控告警在系统健康的时候就应该建立性能基准。使用像node_exporter、collectd这样的代理配合Prometheus和Grafana持续采集关键指标CPU使用率分us/sy等、负载、内存、磁盘I/O、网络流量、关键进程资源占用等。为这些指标设置合理的告警阈值例如CPU使用率持续5分钟85%或负载持续高于核心数的2倍。这样问题在变得严重之前就能被发现。7.2 使用更高级的BPF/eBPF工具对于现代Linux内核4.x以上eBPF技术提供了更强大、更高效的内核追踪能力。Brendan Gregg创建的bcc和bpftrace工具集包含了许多现成的利器开销极低非常适合生产环境cpuunclaimed: 查看CPU空闲时间在哪。runqlat: 分析进程在运行队列中等待调度的时间。offcputime: 分析进程不在CPU上运行的时间即被阻塞或等待的时间并以火焰图形式展示对于查找性能延迟瓶颈非常有用。biolatency,biosnoop: 分析块设备I/O的延迟和请求。学习和使用这些工具能将你的排查能力提升到一个新的维度。7.3 容器化环境下的排查差异在Docker或Kubernetes环境中排查思路不变但命令的执行环境需要注意。进入容器docker exec -it container_id /bin/bash或kubectl exec -it pod_name -- /bin/bash。查看容器进程在宿主机上容器的进程是可见的。你可以用top、ps等工具查看但需要注意PID命名空间。更简单的是在容器内执行这些命令。工具安装容器镜像通常很精简可能没有perf、strace等工具。需要构建包含这些工具的自定义镜像或者在宿主机上使用nsenter命令进入容器的命名空间进行调试需要特权。资源限制容器可能设置了CPU限额cgroups。即使容器内进程显示CPU使用率100%它可能只占用了宿主机一个核心的50%。需要结合docker stats或kubectl top命令查看容器级别的资源使用情况。7.4 编写自动化排查脚本对于反复出现的某类问题可以编写简单的Shell脚本来自动化初步排查。例如一个脚本可以自动执行top、vmstat、pidstat并将结果输出到文件甚至通过邮件发送。这能在问题发生时为你保留第一时间的现场信息。排查CPU高使用率问题是一个从宏观到微观、从现象到本质的推理过程。它考验的不仅是命令的熟悉程度更是对系统原理、应用架构的深入理解。每一次成功的排查都是对系统认知的一次深化。记住没有“银弹”最好的工具是你的逻辑思维和对系统的好奇心。多实践多总结下次再遇到服务器“发烧”你就能从容应对手到病除。 
