1. 项目概述为什么我们需要监视CPU与GPU在Linux系统上干活无论是运维服务器、跑深度学习模型、做视频渲染还是单纯觉得电脑风扇突然狂转监视CPU和GPU的使用情况都是一项必备的基础技能。这不仅仅是看几个数字那么简单它关乎系统稳定性、性能瓶颈定位、资源成本控制甚至是排查一些诡异问题的起点。想象一下你负责的线上服务突然响应变慢用户开始抱怨老板的电话下一秒可能就要响起。这时候你是手足无措地重启服务还是能迅速打开终端通过几行命令精准定位到是某个Java进程的CPU使用率飙到了300%还是GPU内存被某个跑偏的模型吃光了答案显而易见。这个项目标题“【Linux】监视CPU、GPU使用情况”看似基础实则涵盖了从命令行工具到图形化界面从实时监控到历史数据分析的完整知识体系。它适合所有在Linux环境下工作的人从刚入门的新手到需要管理高性能计算集群的资深工程师。核心价值在于它赋予你一双“透视眼”让你对系统的运行状态了如指掌。通过本文我将带你系统性地掌握在Linux下监视CPU和GPU的各类工具与方法不仅告诉你“用什么”更深入解释“为什么用”以及“怎么用好”并分享一些实战中积累的、教科书里不会写的排查技巧和避坑指南。2. 核心监控指标与工具选型解析在动手之前我们必须先搞清楚要监控什么。不同的指标就像不同的仪表盘告诉你系统不同维度的状态。2.1 CPU监控核心指标CPU的监控远比“使用率100%”复杂。一个健康的监控视角应该包含以下层面整体使用率%CPU这是最直观的指标表示CPU时间的占用比例。但需要注意在Linux中这个值可以超过100%。因为它是所有CPU核心使用率的累加。对于一个4核CPU一个单线程进程满载一个核心其%CPU显示为100%如果一个多线程进程让所有4个核心都满载那么它的%CPU就会显示为400%。这是新手常困惑的点。用户态 vs 内核态时间%us, %sy%us是进程在用户态运行的时间占比即执行应用程序自己的代码。%sy是系统态内核态时间占比即执行操作系统内核代码如处理系统调用、中断等。如果%sy异常高可能意味着系统正在进行大量的I/O操作、上下文切换频繁或者存在某些内核驱动问题。负载平均值Load Average这是一个更宏观、也更容易被误解的指标。它显示为三个数字如0.50, 0.30, 0.10分别代表过去1分钟、5分钟、15分钟的系统平均负载。关键理解负载平均值表示的是系统中处于可运行状态R和不可中断睡眠状态D的平均进程数。对于单核CPU负载为1.0意味着CPU刚好被完全利用。对于多核CPU需要将负载值除以核心数来看。例如4核CPU上负载为8.0意味着平均有8个进程在竞争CPU时间系统已经过载。进程级指标除了系统整体我们更关心是哪个具体进程在消耗资源。需要关注进程的PID、所属用户、优先级NI、常驻内存集RES、虚拟内存VIRT以及其下的线程状态。2.2 GPU监控核心指标GPU的监控维度与CPU类似但关注点不同尤其是在进行机器学习、图形渲染或科学计算时GPU利用率Utilization类似于CPU使用率表示GPU计算引擎如CUDA核心的繁忙程度。但要注意GPU是高度并行化的一个看似不高的利用率可能只是因为任务无法充分利用所有流处理器。显存使用情况Memory Usage这是GPU监控的重中之重。显存VRAM是GPU的专用高速内存容量有限且昂贵。显存耗尽是导致CUDA “out of memory”错误的直接原因。需要监控已用显存、空闲显存以及每个进程的显存占用。温度与功耗Temperature Power Draw对于长期高负载运行或超频的GPU温度和功耗是稳定性的生命线。过热会导致降频Throttling影响性能长期则损害硬件。每个进程的GPU资源占用在多人共享的服务器或工作站上明确哪个用户、哪个进程占用了多少GPU资源是进行资源调度和问题问责的基础。2.3 工具选型从经典到现代面对不同的场景和需求工具的选择至关重要。下面这个表格梳理了主流工具的定位和特点工具类别工具名称核心特点适用场景经典命令行工具top/htop实时、交互式、系统级概览。htop是top的增强版支持颜色、鼠标操作、树状视图。快速系统状态检查进程级CPU监控。系统概览工具vmstat,mpstat,iostatvmstat报告虚拟内存、进程、CPU等统计信息mpstat汇报每个CPU核心的详细统计iostat专注CPU和I/O。性能基准测试系统级瓶颈初步分析。进程树查看pstree以树状图形式显示进程关系。理解进程父子关系排查僵尸进程或进程组问题。GPU监控NVIDIAnvidia-smiNVIDIA官方工具功能全面可查询状态、监控进程、设置功耗等。NVIDIA GPU监控的绝对主力运维和开发必备。GPU监控通用/AMDrocm-smi(AMD) /gpustatrocm-smi是AMD ROCm平台的对应工具。gpustat是一个基于nvidia-smi的Python封装输出更简洁美观。AMD GPU监控需要更友好GPU状态输出的场景。一体化监控glances,btopglances跨平台通过 curses 界面展示CPU、内存、磁盘、网络、GPU等。btop是htop的现代化继承者功能强大界面华丽。需要一个面板看全系统所有核心指标的日常运维。历史数据与可视化sar(sysstat包) / Prometheus Grafanasar是系统活动报告器可收集和回放历史数据。PrometheusGrafana是云原生时代的标准监控方案。趋势分析、容量规划、建立长期监控告警体系。实操心得对于日常快速检查我的首选组合是htopgpustat如果服务器有N卡。htop的树状视图和搜索功能在定位“罪魁祸首”进程时效率极高。而gpustat一行命令就能给出所有GPU的利用率、显存、温度和使用者比原生的nvidia-smi更一目了然。对于需要留存记录或深度分析的问题一定要学会使用sar或配置更完善的监控系统。3. 命令行工具实战从top到nvidia-smi理论说再多不如动手敲一遍。我们进入实战环节看看这些工具具体怎么用输出信息又该如何解读。3.1top与htop系统状态的仪表盘直接输入top命令你会看到一个不断刷新的全屏界面。信息很多我们拆解关键部分第一行系统概览top - 14:30:00 up 30 days, 3:15, 1 user, load average: 0.05, 0.10, 0.15load average如前所述三个负载值。这里的值很低系统非常空闲。第二行任务Tasks: 250 total, 1 running, 249 sleeping, 0 stopped, 0 zombiezombie僵尸进程数量。如果不是0需要关注可能意味着子进程退出后父进程没有正确回收资源。第三行%Cpu(s)%Cpu(s): 2.5 us, 0.5 sy, 0.0 ni, 97.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 stus用户态,sy系统态,id空闲。这里97%的空闲系统负载很轻。waI/O等待如果这个值持续很高说明磁盘或网络I/O可能成为瓶颈。stSteal Time在虚拟化环境中如云服务器被宿主机“偷走”的CPU时间。如果持续较高说明物理主机资源竞争激烈你的虚拟机分到的CPU时间不足。进程列表默认按CPU使用率排序。关键列PID进程ID。USER进程所有者。%CPUCPU使用率所有核心总和。%MEM物理内存使用百分比。COMMAND启动命令。在top界面中你可以按一些键进行交互操作P按CPU使用率排序默认。M按内存使用率排序。N按PID排序。k终止指定PID的进程会询问PID和信号。1展开显示每个CPU核心的详细状态。htop提供了更佳的体验。安装后直接运行htop。它的优势在于彩色显示更直观。支持鼠标点击表头排序。底部有功能键提示F1-F10。按F5可以树状显示进程清晰看到父子关系。按F9发送信号如终止进程更便捷。可以轻松搜索进程按F3。注意事项top和htop显示的CPU使用率是瞬时值或一个很短时间窗口内的平均值。对于CPU使用率剧烈波动的进程如某个定时任务瞬间启动又结束你可能在刷新间隙捕捉不到它。这时需要借助pidstat或历史日志工具。3.2nvidia-smiNVIDIA GPU的瑞士军刀对于装有NVIDIA显卡的Linux系统nvidia-smi是必须掌握的命令。直接运行它nvidia-smi你会看到一个格式化的表格输出包含以下核心信息----------------------------------------------------------------------------- | NVIDIA-SMI 535.161.07 Driver Version: 535.161.07 CUDA Version: 12.2 | |--------------------------------------------------------------------------- | GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC | | Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. | | | | MIG M. | || | 0 NVIDIA GeForce ... On | 00000000:01:00.0 Off | N/A | | 30% 45C P2 70W / 250W | 5678MiB / 12288MiB | 45% Default | | | | N/A | ---------------------------------------------------------------------------Driver/CUDA Version驱动和CUDA版本兼容性问题首先查这里。GPU Name, Fan, Temp, Perf, PwrGPU名称、风扇转速、温度、性能状态P0-P12P0最高、功耗当前/上限。温度是重要指标通常满载下低于85℃比较安全。Memory-Usage显存使用情况。5678MiB / 12288MiB表示已用5.6G总共12G。这是排查“CUDA out of memory”错误的第一现场。GPU-UtilGPU计算单元利用率。45%表示计算核心有近一半在工作。Processes在表格下方会列出当前使用GPU的进程包括PID、进程名、显存占用。这是定位“谁在用我的卡”的关键。nvidia-smi还支持很多有用的参数nvidia-smi -l 1每秒刷新一次类似top的实时监控。nvidia-smi -q查询所有详细信息包括ECC错误、时钟频率、电源上限等。nvidia-smi -i 0 -pm 1为0号GPU启用持久化模式减少初始化延迟常用于生产环境。nvidia-smi -i 0 -pl 200将0号GPU的功耗上限设置为200瓦。踩坑记录曾经遇到一个深度学习训练任务nvidia-smi显示GPU利用率很低10%但程序就是跑得慢。后来用nvidia-smi dmon命令查看设备级更细粒度的指标发现“SM Util”流多处理器利用率和“Tensor Core Util”张量核心利用率都很高而“GPU Util”主要反映的是图形或通用计算单元的负载。这说明我的模型很好地利用了Tensor Core进行混合精度计算而通用计算单元不忙所以整体利用率显示不高。因此不能单纯看“GPU-Util”就断定GPU没干活。3.3gpustat更优雅的GPU监控gpustat是一个第三方工具通过pip安装pip install gpustat。运行gpustat或gpustat -cp你会得到一行一个GPU的彩色简洁输出[0] NVIDIA GeForce RTX 4090 | 45°C, 45% | 5678 / 12288 MB | user(pid1234): 5678MB python信息高度浓缩GPU编号、型号、温度、利用率、显存使用、以及占用它的用户和进程。-i 1参数可以使其像top一样实时刷新。对于多卡服务器一眼扫过去就能掌握全局状态效率极高。4. 高级监控与脚本化自动化命令行工具适合临时检查但对于长期监控、自动告警或生成报告我们需要更自动化的方法。4.1 使用vmstat、mpstat、pidstat进行深入分析这些工具来自sysstat包通常需要安装。vmstat 1每隔1秒输出一次虚拟内存统计。关注r可运行进程数、b不可中断睡眠进程数、si/so内存交换入/出如果不为0且持续说明物理内存严重不足、us/sy/id/wa/st同top的CPU状态。mpstat -P ALL 1每隔1秒输出一次每个CPU核心的详细利用率。在多核系统中可以观察负载是否均衡。如果某个核心长期100%而其他核心空闲可能是程序没有做好多线程优化。pidstat 1每隔1秒报告一次进程级的统计信息CPU、内存、IO等。它可以用来追踪某个特定进程或者查看是哪些进程导致了高的%sy系统态CPU或%waitI/O等待。4.2 使用sar收集与回顾历史数据sar是系统活动报告器它依赖于sysstat服务后台收集数据。它的强大之处在于可以查看过去任意时间点的系统状态。查看今天的CPU历史sar -u查看特定日期的内存使用sar -r -f /var/log/sa/saXXXX是日期查看过去某个时间段的详细报告sar -u -s 10:00:00 -e 12:00:00配置sysstat通常已默认启用数据收集。你可以编辑/etc/sysstat/sysstat或/etc/default/sysstat来调整数据收集的频率和保存时长。4.3 编写监控脚本与设置告警将命令封装成脚本是自动化监控的第一步。例如一个简单的检查GPU显存并告警的Shell脚本#!/bin/bash # check_gpu_mem.sh THRESHOLD90 # 显存使用率阈值百分比 GPU_INFO$(nvidia-smi --query-gpumemory.used,memory.total --formatcsv,noheader,nounits) USED_MEM$(echo $GPU_INFO | awk -F, {print $1}) TOTAL_MEM$(echo $GPU_INFO | awk -F, {print $2}) USAGE_PERCENT$(( USED_MEM * 100 / TOTAL_MEM )) if [ $USAGE_PERCENT -gt $THRESHOLD ]; then echo 警告GPU显存使用率过高当前使用率: ${USAGE_PERCENT}% # 这里可以集成发送邮件、Slack消息或触发其他告警动作 # 例如curl -X POST -H Content-type: application/json --data {text:GPU内存告警} $SLACK_WEBHOOK_URL fi可以将这个脚本加入crontab每分钟执行一次实现基本的阈值告警。对于更复杂的监控需求如需要记录历史数据、绘制趋势图、设置多级告警规则建议采用成熟的监控系统如Prometheus Grafana组合。Prometheus可以抓取node_exporter负责收集主机指标和nvidia_gpu_exporter负责收集GPU指标的数据Grafana则提供强大的可视化仪表盘。这是企业级监控的标准做法。5. 常见问题排查与性能优化实战掌握了工具最终是为了解决问题。下面记录几个典型的实战场景和排查思路。5.1 场景一CPU使用率100%系统卡顿快速定位进程运行top或htop按PCPU排序。查看是哪个哪些进程的%CPU最高。分析进程状态在top中查看该进程的S状态列。如果是RRunning说明正在执行计算。如果是DUninterruptible Sleep则可能是在等待I/O如磁盘读写这时高%CPU可能伴随高waI/O等待。深入分析如果是R状态使用pidstat -p PID 1查看该进程详细的CPU使用用户态/系统态。使用strace -p PID跟踪进程的系统调用看它是否在频繁执行某些操作注意生产环境慎用影响性能。使用perf top查看系统级别的函数调用热点。线程级分析在htop中按H显示线程或按F2进入设置在“Display options”中启用“Tree view”和“Show custom thread names”。有时一个Java应用某个线程死循环会导致整个进程CPU高。优化方向如果是业务代码可能需要优化算法。如果是配置问题如Web服务器工作进程数过多调整配置。如果是外部攻击如CC攻击需要结合网络监控分析。5.2 场景二GPU显存占用高但利用率低这在深度学习训练和推理中非常常见。确认占用者nvidia-smi或gpustat查看是哪个进程占用了显存。分析原因模型加载大型模型本身参数就会占用大量显存。数据批次Batch过大输入数据在GPU内存中排队等待计算。显存泄漏程序分配了显存但没有正确释放常见于TensorFlow/PyTorch等框架使用不当或代码中存在循环创建张量而未清理。缓存占用CUDA内核、cuDNN等库会占用一些显存作为缓存。排查与解决对于PyTorch可以使用torch.cuda.empty_cache()尝试释放未使用的缓存但治标不治本。使用torch.cuda.memory_summary()或torch.cuda.memory_allocated()在代码中跟踪显存分配。减小Batch Size是立竿见影的方法。使用梯度累积Gradient Accumulation来模拟大Batch同时减少单次显存占用。考虑使用模型并行、激活值检查点Activation Checkpointing等高级技术。使用fuser -v /dev/nvidia*可以查看哪些进程打开了GPU设备文件辅助排查僵尸进程残留。5.3 场景三负载平均值Load Average很高但CPU使用率不高这是一个经典矛盾通常指向I/O或锁竞争瓶颈。检查I/O等待在top或vmstat 1中观察wa%wa值。如果持续很高例如20%说明磁盘或网络I/O是瓶颈。使用iostat -x 1查看具体磁盘的%util利用率、await平均等待时间、svctm服务时间。使用iotop命令查看是哪些进程在进行大量I/O操作。检查不可中断睡眠进程在top中查看Tasks行的b不可中断睡眠数量。或者直接用ps aux | grep D 查找处于D状态的进程。这类进程通常在等待磁盘I/O完成它们会贡献到负载平均值但不消耗CPU。检查锁竞争对于多线程程序如果线程间频繁竞争同一把锁会导致大量线程处于可运行状态R但实际在等待从而推高负载。这需要使用更专业的性能剖析工具如perf结合代码分析。5.4 一个综合排查案例Web服务响应变慢假设一个基于PythonDjango/Flask的Web服务突然变慢。整体观感htop发现系统负载从平时的0.5升到了8.04核CPU但CPU总使用率只有50%。细节分析vmstat 1显示wa在30%左右波动b有少量进程。iostat -x 1发现数据库所在磁盘的%util接近100%await高达几百毫秒。定位根源iotop发现是MySQL进程在大量写磁盘。登录MySQL执行SHOW PROCESSLIST;发现大量慢查询其中很多是未合理使用索引的全表扫描。解决方案优化SQL语句为相关字段添加索引。同时考虑升级磁盘为SSD或优化数据库配置。监控不是目的而是手段。通过这些工具和思路你将能构建起对Linux系统资源使用的清晰认知从而在问题出现时能够像侦探一样从纷繁的现象中迅速找到根源并实施有效的优化。记住熟练使用这些命令并结合实际业务逻辑思考是每个Linux从业者走向高阶的必经之路。
)
