1. 项目概述为什么我们需要系统监控指令在Ubuntu服务器或者日常开发机上你有没有遇到过系统突然变慢、程序卡死或者风扇狂转但不知道是谁在“搞鬼”的情况我遇到过太多次了。尤其是在跑深度学习训练、编译大型项目或者仅仅是开了几十个浏览器标签页的时候系统资源就像被黑洞吸走了一样。这时候光靠感觉是没用的你需要的是像“听诊器”和“X光机”一样的工具精准地看到CPU、内存、GPU、硬盘这些核心部件到底在忙什么。“Ubuntu下系统CPU/内存/GPU/硬盘监控查看指令”这个标题听起来像是一份命令清单但它的内核远不止于此。它是一套系统诊断的方法论。对于运维工程师这是保障服务稳定的基本功对于开发者这是定位性能瓶颈、优化代码的必备技能即便是普通用户学会几招也能在电脑卡顿时自救而不是只会重启。网上的热词也印证了这种需求的普遍性从“wechatappex.exe占用cpu高”、“内存泄漏”到“pytorch安装教程gpu”背后都是大家对资源使用情况的困惑和焦虑。很多人知道top或htop但可能不知道如何持续监控硬盘I/O或者如何判断是CPU瓶颈还是内存不足导致的卡顿。更别提GPU了在AI应用普及的今天监控GPU的显存、算力利用率对于模型训练和推理调优至关重要。所以这篇文章的目的不是简单地罗列命令而是带你建立一套从全局到局部、从瞬时到持续的监控思维。我会分享我用了十多年的“组合拳”告诉你每个命令在什么场景下最有用如何解读那些看似复杂的输出数字以及当出现问题时我的第一反应是查哪里。这些经验很多是手册里不会写的“肌肉记忆”。2. 核心监控思路与工具选型解析面对系统监控新手最容易犯的错误就是拿起一个工具就用看到一堆数字就懵。我的思路是分层、分场景并且理解每个工具的设计哲学。2.1 监控的四个层次与对应策略系统监控可以粗略分为四个层次由宏观到微观全局概览层快速回答“系统整体健康吗”的问题。工具需要提供CPU、内存、交换分区Swap、负载Load Average的即时快照。代表工具top,htop,glances。进程详情层回答“是谁在消耗资源”的问题。需要能排序、筛选、查看单个进程的详细资源占用。代表工具top/htop交互模式pspidstat。硬件专项层针对特定硬件如GPU、磁盘、网络进行深度剖析。回答“GPU显存满了吗”、“磁盘读写有多忙”的问题。代表工具nvidia-smi(GPU)iostat,iotop(磁盘)iftop,nethogs(网络)。历史与趋势层回答“这个问题是突然出现的还是长期趋势”的问题。需要记录和可视化历史数据。代表工具sar(System Activity Reporter) 配合gnuplot或更现代的PrometheusGrafana。对于日常命令行操作前三个层次是重点。我的习惯是先用htop看全局发现异常进程号PID后用ps或pidstat深挖该进程如果怀疑磁盘或GPU则用专项工具验证。2.2 为什么选择这些命令行工具图形化工具如系统监视器很直观但在服务器环境、SSH远程连接、或者需要自动化脚本时命令行工具是不可替代的。它们轻量、高效、可脚本化并且通常提供更丰富、更原始的数据。topvshtoptop是元老几乎所有Unix-like系统都有功能强大但交互和界面相对古老。htop是它的现代化增强版支持颜色、鼠标操作、垂直/水平滚动、树状视图查看进程关系用户体验好太多。我强烈建议将htop作为你的默认全局监控工具。安装也简单sudo apt install htop。ps的灵活性ps命令的参数体系庞大BSD和GNU风格并存乍看复杂但正是这种复杂性赋予了它无与伦比的灵活性。你可以用它组合出几乎任何你想要的进程信息视图并传递给其他命令如grep、awk进行处理这是图形工具难以做到的。nvidia-smi的权威性对于NVIDIA GPU这是官方提供的唯一权威监控工具。它不仅显示状态还能设置GPU运行模式、重置ECC错误等。注意工具的选择也取决于你的Ubuntu版本和安装的软件包。有些工具如iotop,nethogs可能需要额外安装。本文会基于Ubuntu 22.04 LTS或更新版本进行说明大部分工具可通过apt直接安装。3. CPU监控看懂负载、利用率与进程调度CPU是系统的大脑它的状态最直接地反映了系统的繁忙程度。但看CPU不能只看一个“使用率”数字。3.1 核心指标解读top/htop第一行运行htop顶部信息栏是关键1 [||||||||||||||||||| 50.0%] Tasks: 156, 317 thr; 2 running 2 [|||||||||||| 25.0%] Load average: 1.25 0.80 0.60 3 [ 0.0%] Uptime: 10 days, 15:30:20 4 [|||||||||||||||||||||||||||||| 100.0%] Mem[||||||||||||||||||||| 2.45G/7.64G] Swp[ 0K/2.00G]CPU使用率条形图这里通常有多个条形代表不同的CPU核心或线程。图例中1-4行可能对应CPU1-CPU4或者更常见的表示行1总体用户空间进程使用率行2系统内核空间使用率行3低优先级进程nice使用率行4空闲率。在htop设置F2中可以选择显示方式。重点是用户态us高通常表示应用繁忙内核态sy高可能涉及大量系统调用或中断需要警惕。负载平均值Load Average1.25 0.80 0.60这三个数字分别代表过去1分钟、5分钟、15分钟系统的平均负载。这个负载不是百分比其含义是“平均有多少个进程在等待或正在使用CPU或等待I/O”。对于单核CPU1.0表示刚好满负荷对于4核CPU4.0表示满负荷。如果1分钟值远高于5分钟、15分钟值说明有突发负载如果持续高于CPU核心数说明系统过载进程需要排队。任务Tasks总进程数、线程数、正在运行的进程数。线程数远大于进程数是现代多线程应用的常态。3.2 进程级CPU监控ps与pidstat在htop里按F6可以选择排序依据比如按%CPU排序立刻能找到最耗CPU的进程。但如果你想在脚本中捕获或者查看某个特定进程的详细CPU使用ps和pidstat更强大。ps常用组合拳# 查看所有进程的PID、用户、CPU和内存占用并持续刷新类似top ps aux --sort-%cpu | head -20 # 查看特定进程如nginx的详细信息包括其所有线程 ps -eLf | grep nginx # 查看某个PID如1234的进程及其父进程、子进程树 ps -ef --forest | grep -A 5 -B 5 1234ps aux的输出中%CPU列是进程自启动以来占用CPU时间的平均百分比但在top/htop中则是瞬时或近期的百分比。对于短时爆发的进程ps的%CPU可能看起来不高。pidstat更专业的进程资源统计pidstat来自sysstat工具包能提供间隔性的采样数据更适合观察趋势。# 安装sysstat sudo apt install sysstat # 每2秒采样一次统计所有进程的CPU使用情况共采样5次 pidstat -u 2 5 # 针对特定PID如1234进行详细的CPU统计包括用户态、内核态、等待等 pidstat -u -p 1234 1 10它的输出包含%usr用户态、%system内核态、%guest虚拟机CPU、%wait等待CPU比ps更细致。3.3 实操心得CPU监控的常见陷阱高负载但低CPU使用率如果Load Average很高但top里CPU的id空闲也很高这通常是I/O等待wa过高导致的。进程都在等磁盘或网络CPU没事干。此时应该去查磁盘监控见第5节。%CPU超过100%在top/htop中%CPU是单个CPU核心的100%为基准。如果一个多线程进程使用了2个核心的全部算力它的%CPU会显示200%。这是正常的。瞬间尖刺如何抓top或htop的默认刷新间隔通常3秒可能错过瞬间的CPU峰值。可以用pidstat设置更短的采样间隔如pidstat -u 1 60或者使用**perf** 这样的性能剖析工具来抓取热点函数。4. 内存监控理解已用、缓存、交换与泄漏内存管理是Linux内核的强项但也因此让内存监控变得有点“反直觉”。你不能简单地认为“Used”内存高就是有问题。4.1 解读free -h与top中的内存信息最常用的命令是free -h-h表示人类可读格式total used free shared buff/cache available Mem: 7.6Gi 2.4Gi 1.1Gi 300Mi 4.1Gi 4.5Gi Swap: 2.0Gi 0.0Ki 2.0Gi这里的关键是理解每一列total物理内存总量。used已使用的内存。注意这个“已使用”包含了应用程序使用的内存Mem和内核缓冲区/缓存buff/cache。所以这个数字大不一定代表应用吃紧。free完全空闲、未被使用的内存。在健康的Linux系统上这个值通常很小因为内核会用空闲内存做磁盘缓存cache和缓冲区buffer来提升性能。buff/cache这是可以随时被回收的内存。当应用程序需要更多内存时内核会迅速释放这部分内存。所以buff/cache高通常是好事说明系统在有效利用内存做缓存。available这是最重要的指标它估算的是在不进行交换Swap的情况下可供新应用程序使用的内存量。它包含了free内存和大部分可回收的buff/cache。只要available内存还充足比如大于总内存的20%系统内存压力就不大。Swap交换分区使用情况。如果used持续增长说明物理内存不足内核开始把不常用的内存页换出到磁盘这会严重降低性能。在top或htop中内存信息通常以进度条形式显示其原理与free一致。4.2 进程内存分析ps、htop与/proc每个进程的内存占用也有多个维度VIRT (Virtual Memory)虚拟内存大小。进程申请的总地址空间包括实际使用的内存、映射的文件、共享库等。这个数字可能很大不代表实际物理内存消耗。RES (Resident Memory)常驻内存。进程实际使用的、未被换出的物理内存大小。这是衡量进程内存占用的核心指标。在htop里对应RES列。SHR (Shared Memory)共享内存。可能被其他进程共享的内存部分如共享库。%MEM进程RES占物理内存总量的百分比。查找内存消耗最大的进程ps aux --sort-%mem | head -10或者直接在htop里按F6选择MEM%排序。对于更深入的分析可以查看进程的/proc/[PID]/smaps文件需要sudo权限它会详细列出进程内存的每个映射区域对于诊断内存泄漏非常有帮助。4.3 诊断内存泄漏与OOM内存泄漏的典型表现是某个进程的RES或%MEM随时间持续、稳定地增长即使在其业务低峰期也不释放。你可以用简单的脚本来记录# 每10秒记录一次进程1234的内存占用 while true; do ps -o pid,rss,cmd -p 1234 | grep -v PID sleep 10 done当系统内存严重不足时Linux内核的“Out-Of-Memory Killer”OOM Killer会被触发它会选择一个“坏”进程杀死以释放内存。查看系统日志可以找到线索sudo dmesg -T | grep -i kill 或 sudo journalctl --since 1 hour ago | grep -i oom实操心得不要恐慌于高used和低free重点看available。Swap使用是最后的警报。如果发现Swap的used在持续增加必须立即着手排查要么给系统加物理内存要么优化应用内存使用。缓存cache的积极影响特别是对于频繁读写的数据库或文件服务大量的cache能极大提升性能。用sudo sync echo 3 | sudo tee /proc/sys/vm/drop_caches可以手动清理缓存仅用于测试生产环境慎用观察清理前后性能对比就能体会到缓存的作用。5. GPU监控NVIDIA显卡的专属工具箱对于从事机器学习、科学计算或图形渲染的用户GPU监控和CPU/内存监控同等重要。这里主要针对主流的NVIDIA GPU。5.1nvidia-smi一站式信息面板nvidia-smiSystem Management Interface是你的瑞士军刀。直接运行它会显示一个概要信息表----------------------------------------------------------------------------- | 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 P0 50W / 200W | 1024MiB / 12288MiB | 15% Default | | | | N/A | ---------------------------------------------------------------------------你需要关注这几列Fan, Temp风扇转速和GPU温度。温度是GPU健康的关键指标长期高负荷下最好保持在80-85°C以下。Perf性能状态。从P0最高性能到P12最低功耗。如果GPU不忙但处于P0可能驱动或应用有问题导致无法降频。Pwr:Usage/Cap当前功耗/最大设计功耗。Memory-Usage这是最关键的指标1024MiB / 12288MiB表示已用显存/总显存。深度学习模型训练时这个值会接近满载。如果还没开始计算任务显存就占了很多可能是之前进程未释放需要排查。GPU-UtilGPU计算单元利用率百分比。跑CUDA核心计算时这个值会很高。注意一些内存传输密集型或非核心计算的任务可能GPU-Util不高但Memory-Usage满同样会卡顿。Compute M.计算模式。Default表示多个进程可以共享GPU。5.2 实时监控与进程关联nvidia-smi也可以像top一样实时刷新并显示占用GPU的进程# 每1秒刷新一次显示进程信息 nvidia-smi -l 1 # 或者使用更易读的循环命令 watch -n 1 nvidia-smi要查看是哪个进程占用了显存可以使用nvidia-smi --query-compute-appspid,process_name,used_memory --formatcsv这个命令会列出所有使用GPU的进程及其显存占用结合ps命令就能定位到具体的程序。5.3 常见GPU问题排查显存已满但GPU-Util为0%这通常是显存泄漏或进程崩溃后未释放显存。解决方法是找到残留进程并杀死。如果找不到可以尝试重启图形界面sudo systemctl restart display-manager或最彻底地重启系统。对于服务器可以使用sudo nvidia-smi --gpu-reset如果支持来重置GPU。GPU-Util波动很大在深度学习训练中这可能是由于数据加载CPU/磁盘瓶颈导致GPU等数据计算不连续。需要优化数据管道如使用更快的存储、更多数据加载worker、预取。nvidia-smi命令找不到说明没有安装NVIDIA驱动或驱动安装不正确。需要安装合适的驱动可通过ubuntu-drivers devices查看推荐驱动然后用sudo apt install nvidia-driver-xxx安装。实操心得对于长期运行的训练任务我习惯将nvidia-smi的输出定期重定向到日志文件以便后续分析显存和利用率趋势# 每30秒记录一次持续到训练结束 while true; do nvidia-smi --query-gputimestamp,name,utilization.gpu,utilization.memory,memory.used,memory.total,temperature.gpu --formatcsv gpu_log.csv sleep 30 done6. 硬盘监控I/O才是真正的性能隐形杀手很多时候系统卡顿CPU和内存看起来都正常罪魁祸首往往是磁盘I/O。磁盘监控主要看两个维度使用率空间和活动率I/O性能。6.1 磁盘空间监控df与du这是最基本也是最常用的。df查看文件系统磁盘空间使用情况df -h-h代表人类可读GB/MB。重点关注Use%列通常告警阈值设置在80%或90%。/根分区和/home、/var日志常在这里等是重点监控对象。du估算文件和目录的磁盘使用空间# 查看当前目录下各子目录的大小 du -sh * # 找出当前目录下最大的10个文件或目录 du -ah . | sort -rh | head -n 20 # 经典用法快速定位哪个目录占用了大量空间 sudo du -h --max-depth1 / | sort -h当df显示某个分区快满了就用du层层深入找到是哪个“大家伙”在占用空间。对于/var/log经常是日志文件膨胀可以用logrotate服务管理。6.2 磁盘I/O性能监控iostat与iotop空间够不代表磁盘不忙。高I/O等待wa是系统响应慢的常见原因。iostat查看CPU统计信息和设备I/O统计信息# 安装sysstat sudo apt install sysstat # 每2秒刷新一次显示所有设备的扩展统计信息 iostat -dx 2关键列解读%util设备利用率。这是最重要的指标表示设备有I/O请求的时间百分比。如果持续接近100%说明磁盘I/O饱和成为瓶颈。r/s,w/s每秒读/写请求数。rkB/s,wkB/s每秒读/写的数据量KB。await平均每次I/O请求的等待时间毫秒。这个值高说明磁盘响应慢可能队列太长或磁盘本身性能差。avgqu-sz平均请求队列长度。队列越长等待时间自然越长。iotop类似top的I/O监控工具按进程排序sudo apt install iotop sudo iotop这个工具直观地显示了是哪个进程在进行大量的磁盘读写。你可以看到每个进程的读/写速率DISK READ/DISK WRITE以及它们贡献的I/O百分比。当iostat显示%util很高时立刻打开iotop就能找到“元凶”。6.3 实操心得磁盘监控的深层技巧区分“慢”的原因高%util不一定代表磁盘吞吐量rkB/s/wkB/s大。如果是大量的小文件随机读写如数据库、邮件服务器即使吞吐量不大也会因为寻道时间导致%util和await很高。此时需要优化应用减少随机I/O或考虑使用SSD。waI/O等待与%util的关系在top里看到高wa基本对应iostat里的高%util。它意味着CPU在空转等待磁盘I/O完成。监控磁盘健康度对于机械硬盘HDD可以使用smartctl工具sudo apt install smartmontools检查S.M.A.R.T.状态预测潜在故障。sudo smartctl -a /dev/sdaSSD的特殊性SSD的%util通常意义不大因为其并行性高。更应关注延迟await和读写量避免过度写入影响寿命。使用nvme命令针对NVMe SSD或iostat看avgqu-sz如果队列深度始终很低但性能差可能是其他瓶颈。7. 综合监控与高级工具链前面介绍的都是点对点的瞬时监控工具。对于需要长期跟踪、分析趋势的场景我们需要更强大的工具。7.1sar系统活动历史报告器sysstat包里的sar命令是宝藏。它默认会每10分钟收集一次系统数据CPU、内存、磁盘、网络等并保存到/var/log/sysstat/目录下。你可以回顾过去任意时间段的数据。# 查看当天CPU使用率的历史记录 sar -u # 查看指定日期如26号的内存使用历史 sar -r -f /var/log/sysstat/sa26 # 查看当天磁盘I/O历史 sar -d # 以更易读的格式查看过去一段时间的网络接口统计 sar -n DEV 1 5sar的数据对于排查“昨天下午系统为什么慢”这类历史问题无比珍贵。你需要先确保sysstat服务已启用sudo systemctl enable sysstat sudo systemctl start sysstat。7.2glances跨平台的现代化仪表盘如果你想要一个集大成的、更美观的终端仪表盘glances是个不错的选择。sudo apt install glances glances它在一个界面里集中显示了CPU、内存、交换分区、负载、磁盘I/O、网络I/O、最耗资源的进程列表等信息密度高且支持客户端-服务器模式远程监控。7.3 建立监控脚本与告警对于生产环境手动敲命令是不够的。我们需要自动化。一个简单的思路是编写Shell脚本定期收集关键指标并与阈值比较触发告警如发送邮件、钉钉消息。#!/bin/bash # 示例监控内存可用性并告警 THRESHOLD500 # MB AVAILABLE_MEM$(free -m | awk /^Mem:/{print $7}) if [ $AVAILABLE_MEM -lt $THRESHOLD ]; then echo 警告可用内存不足 ${AVAILABLE_MEM}MB低于阈值 ${THRESHOLD}MB | \ mail -s 内存告警 $(hostname) your-emailexample.com # 或者调用其他告警接口 fi # 监控根分区使用率 USAGE$(df -h / | awk NR2 {print $5} | sed s/%//) if [ $USAGE -gt 90 ]; then echo 警告根分区使用率 ${USAGE}% | \ mail -s 磁盘空间告警 $(hostname) your-emailexample.com fi将这个脚本加入crontab即可实现定时监控。当然对于更复杂的系统建议使用专业的监控方案如Zabbix,Prometheus Grafana它们能提供强大的数据采集、存储、可视化、告警能力。8. 常见问题排查流程实录当系统出现性能问题时一个清晰的排查思路比记住所有命令更重要。以下是我常用的“四步诊断法”第一步快速全局定位 (htopdmesg -T | tail)打开htop看整体负载Load Avg、CPU各状态us, sy, wa, id、内存可用内存、Swap使用。快速按F6分别按%CPU和%MEM排序找出头部的“嫌疑进程”。同时在另一个终端运行dmesg -T | tail -20查看内核是否有最新的错误或OOM日志。第二步根据线索深入分析如果wa高立即运行iostat -dx 2和sudo iotop定位磁盘瓶颈和肇事进程。如果CPUus或sy高在htop里已找到高CPU进程。用strace -p [PID]或perf top可以进一步分析该进程在做什么系统调用或哪些函数耗时。如果内存available低且Swap使用增长用ps aux --sort-%mem找内存大户。用sudo tail -f /var/log/syslog或journalctl -f观察是否有应用错误或OOM Killer日志。如果怀疑GPU问题运行nvidia-smi -l 1观察显存、利用率和温度。用nvidia-smi --query-compute-appspid,process_name,used_memory --formatcsv关联进程。第三步专项工具验证网络问题用iftop或nethogs看流量和进程。进程内部细节用pmap -x [PID]看内存映射用lsof -p [PID]看打开的文件。系统调用跟踪strace -p [PID]。第四步历史数据回溯如果问题是间歇性的使用sar命令查询问题时间段的历史数据CPU、内存、磁盘、网络看是否能找到规律。我踩过的一个坑有一次线上服务响应变慢htop显示CPUid很高wa不高负载也不高。但用户就是感觉慢。最后用sar -n DEV回顾历史发现问题时间段内网络接收错误包rxerr/s激增原来是底层网络链路出了问题。所以当CPU、内存、磁盘看起来都正常时别忘了检查网络。这套指令和思路是我多年在Ubuntu环境下进行系统调试和性能优化的核心工具箱。记住监控的目的不是为了看一堆数字而是为了建立对系统行为的直觉在问题出现时能快速定位根因。刚开始可能觉得命令多多用几次形成自己的检查清单你就会发现系统在你眼里变得越来越透明。