1. 项目概述：为什么我们需要监控Ubuntu系统资源

在服务器运维、软件开发或者日常使用Ubuntu桌面系统时，我们经常会遇到一些“卡顿”或“异常”。比如，一个后台服务突然响应变慢，一个编译任务耗时远超预期，或者风扇狂转但不知道是哪个程序在作祟。这时候，光靠感觉是没用的，我们需要确凿的证据来定位问题根源。这就是系统资源监控的价值所在——它像给系统做了一次全面的“体检”，让你清晰地看到CPU、内存、网络等核心部件的实时工作状态。

对于Ubuntu用户，无论是新手还是老手，掌握一套高效、准确的资源查看命令，是一项必备的生存技能。这不仅能帮助你在问题发生时快速响应，更能让你在日常使用中优化系统性能，理解应用程序的行为模式。网络上虽然有很多零散的教程，但往往只介绍单个命令，缺乏从需求出发、由浅入深的系统性梳理。今天，我就结合自己多年的运维和开发经验，为你整理一份从基础到进阶的Ubuntu系统资源监控实战指南。我们将聚焦于最核心的CPU、内存和网络三大指标，使用系统自带的强大工具，不依赖任何第三方图形界面软件，让你在终端里就能掌控全局。

2. 核心监控工具全景与选型思路

在深入具体命令之前，我们先来了解一下Ubuntu系统为我们提供了哪些“听诊器”和“仪表盘”。这些工具大致可以分为几类：实时动态监控、历史数据统计、进程级细粒度分析以及网络专用工具。选择哪个工具，取决于你的具体场景：是想看实时滚动的全景（如top），还是想看某个时间点的快照（如ps），或是想分析过去一段时间的性能趋势（如sar）。

实时监控三剑客：top, htop, glancestop是元老，所有Linux发行版都预装，功能强大但界面古朴。htop是top的增强版，彩色界面，支持鼠标操作，直观性大幅提升，通常需要手动安装。glances则更现代化，用Python写成，能以Web服务方式提供监控面板。对于绝大多数场景，我推荐优先掌握top（因为肯定有），然后安装并使用htop以获得更好的体验。

快照与查询工具：ps, free, vmstat, netstat/ss当你不需要持续监控，只想看一眼当前状态时，这些命令是首选。ps查看进程列表，free看内存使用，vmstat看系统整体性能概览。网络方面，传统的netstat正在被更高效的ss命令取代，它们能告诉你哪些端口在监听，哪些连接已建立。

性能分析利器：sar, iostat, pidstat这些命令来自sysstat工具包，它们强大的地方在于能收集和报告历史性能数据。比如，你想知道昨天下午3点CPU为什么飙高，sar保存的历史日志就能派上用场。pidstat则可以针对特定进程，输出其CPU、内存、IO等详细统计信息，是深度排查的利器。

网络流量监控：iftop, nethogs, bmonifconfig或ip addr只能看到网卡收发数据包的总量，而iftop可以像top一样，实时显示每个网络连接的带宽占用。nethogs更进一步，能按进程来统计网络流量，直接揪出“流量小偷”。bmon提供了更丰富的图表化展示。

提示：对于新手，我建议的入门路径是：先用htop（或top）和free -h建立对系统资源的整体感知，然后用ps或pidstat定位具体进程，最后在需要分析网络问题时使用iftop或nethogs。sar等工具更适合搭建长期监控体系时使用。

3. CPU资源占用深度解析与实战

CPU是系统的大脑，其使用率是判断系统是否“繁忙”的首要指标。但CPU使用率本身也有多个维度，理解它们才能做出正确判断。

3.1 使用 top/htop 进行全局监控

打开终端，直接输入top，你会看到一个不断刷新的界面。最上面几行是系统概要信息：

• 第一行：系统当前时间、运行时间、登录用户数、系统平均负载（load average）。这里的平均负载（如0.05, 0.10, 0.15）需要特别注意，它代表过去1、5、15分钟内，系统处于可运行状态和不可中断状态的平均进程数。对于单核CPU，1.00表示刚好满负荷；对于4核CPU，4.00才表示满负荷。如果15分钟负载远高于CPU核心数，说明系统持续繁忙。
• 第二行：任务（Tasks）统计，包括总数、运行中的、休眠的、停止的、僵尸进程数。僵尸进程（zombie）过多可能意味着有程序没有正确回收子进程。
• 第三行：这是CPU使用率的精髓所在，以百分比显示：
  • us(user): 用户空间进程占用CPU时间百分比。你的应用程序（如Python脚本、Java服务）的计算就属于这里。
  • sy(system): 内核空间进程占用CPU时间百分比。系统调用、中断处理等开销在这里。
  • ni(nice): 被调整过优先级的用户进程占用时间。
  • id(idle): CPU空闲时间百分比。这是你最希望看到的数字，越高说明系统越“清闲”。
  • wa(iowait): CPU等待I/O（通常是磁盘I/O）完成的时间百分比。如果这个值持续很高（比如超过20%），说明磁盘可能是性能瓶颈，CPU在空等数据。
  • hi(hardware irq): 处理硬件中断的时间。
  • si(software irq): 处理软件中断的时间。
  • st(steal): 在虚拟化环境中，被宿主机“偷走”的时间。如果你的虚拟机感觉慢，可以看看这个值是否很高。

在top界面中，按下数字1，可以展开显示每个CPU核心的独立使用情况，对于多核CPU的负载均衡分析非常有用。

htop的界面更友好。安装命令：sudo apt update && sudo apt install htop。运行htop后，顶部用彩色条状图直观展示了CPU每个核心的使用情况，中间是进程列表，底部显示了功能键。你可以用F5键以树状图形式显示进程父子关系，用F6键选择按CPU%、内存%等排序，用鼠标直接点击选中进程并按F9发送信号（如终止进程）。

3.2 使用 mpstat 查看多核CPU细节

top和htop给出了整体视图，但如果你想看每个CPU核心的详细统计，或者需要更精确的采样数据，mpstat是更好的选择。它来自sysstat包，需要安装：sudo apt install sysstat。

查看所有CPU核心的实时统计（每2秒刷新一次）：

mpstat -P ALL 2

输出会显示每个核心的%usr,%nice,%sys,%iowait,%irq,%soft,%steal,%guest,%gnice,%idle，分类比top更细致。-P ALL表示所有处理器，2表示间隔2秒。

这个命令在诊断多核CPU负载不均问题时特别有用。你可能发现某个核心的%sys异常高，这或许意味着某个进程或中断被固定在了该核心上。

3.3 使用 pidstat 进行进程级CPU追踪

当top告诉你CPU使用率很高时，下一步就是找出是哪个或哪些进程导致的。pidstat可以完美胜任，它也来自sysstat包。

每2秒报告一次所有进程的CPU使用情况：

pidstat -u 2

输出列中，%usr和%system分别对应进程在用户态和内核态的CPU使用率。CPU列显示该进程在哪个核心上运行。

如果你想监控某个特定进程，比如PID为1234的进程，可以这样：

pidstat -u -p 1234 2

实操心得：排查CPU间歇性飙高的问题时，单纯靠top实时看可能抓不到瞬间峰值。一个更有效的方法是使用pidstat进行一段时间的高频率采样，并将结果重定向到文件，事后分析。例如：pidstat -u 1 60 > cpu_log.txt，这会对所有进程每秒采样一次，持续60秒。

4. 内存使用情况全面剖析

内存管理是Linux系统的强项，但也因此变得复杂。我们常说的“内存快满了”可能是一种误解，需要正确理解free命令的输出。

4.1 理解 free 命令的输出奥秘

直接运行free，输出单位是KB，可读性差。我们通常用free -h（人类可读格式）或free -m（以MB为单位）。

$ free -h total used free shared buff/cache available Mem: 7.7Gi 2.1Gi 1.5Gi 345Mi 4.1Gi 5.0Gi Swap: 2.0Gi 0.0Ki 2.0Gi

这里的关键是理解每一列的含义，尤其是used,free,buff/cache,available：

• total: 物理内存总量。
• used: 已使用的内存。注意：这个值包含了buffers和cached！所以它往往很大，不代表应用程序实际占用了这么多。
• free: 完全未被使用的内存。在Linux系统运行一段时间后，这个值通常会很小，这完全是正常且健康的，因为Linux会利用空闲内存来做磁盘缓存（cache）和缓冲区（buffer），以提升性能。
• shared: 主要是tmpfs（内存文件系统，如/dev/shm）使用的内存。
• buff/cache: 这是核心所在。buffers是内核缓冲区，用于存储磁盘块的元数据等；cache是页缓存，用于缓存从磁盘读取的文件内容。这部分内存在应用程序需要时，可以被立即回收。所以它算作“已用”，但实际上是“可用的”。
• available:这是你最应该关注的指标。它估算的是在不进行Swap交换的情况下，可以分配给新启动的应用程序的内存大小。它包含了free内存和大部分可回收的buff/cache内存。只要available内存还充足，系统就不会因为内存压力而变慢。

所以，判断内存是否紧张，不要看free是否接近0，而要看available是否充足。当available内存很低时，系统会开始频繁地使用Swap。

4.2 使用 top/htop 和 ps 查看进程内存

在top或htop的进程列表中，关于内存的列主要有：

• VIRT(Virtual Memory): 虚拟内存大小。进程申请的总地址空间，包括代码、数据、共享库、以及申请了但未使用的（如malloc未实际写入）内存。这个值可能很大，参考意义有限。
• RES(Resident Memory): 常驻内存大小。进程实际使用的物理内存（不含Swap）。这个值包含了该进程独占的内存和与其他进程共享的内存（如共享库）。这是判断一个进程消耗多少物理内存的主要指标。
• SHR(Shared Memory): 共享内存大小。RES中可以被其他进程共享的部分，主要是共享库。
• %MEM: 进程使用的物理内存（RES）占总物理内存的百分比。

一个更精确的查看进程内存的命令是ps：

ps aux --sort=-%mem | head -10

这条命令按内存使用率降序排列，显示前10个进程。aux选项列出了所有用户的进程详细信息。

4.3 深入排查：/proc/meminfo 与 slabtop

如果你对内存细节有极致追求，可以查看/proc/meminfo文件：

cat /proc/meminfo

这个文件提供了free命令数据的原始来源，并且信息量巨大，包括各种内存细项：活动/非活动匿名页缓存、脏页、写回页、Slab内存（内核对象缓存）等。当遇到特殊的内存泄漏问题（尤其是内核模块或驱动导致）时，这里的数据是重要的排查依据。

Slab是内核用于缓存常用数据结构（如inode, dentry）的机制。使用slabtop命令可以像top一样实时查看Slab缓存的使用情况：

sudo slabtop -o

-o表示按当前占用大小排序。如果发现某个对象（如dentry）数量异常庞大，可能意味着文件系统缓存了过多的目录项，在某些场景下需要关注。

5. 网络资源监控与连接分析

网络问题排查往往更复杂，因为它涉及本地状态、远程主机、协议和流量。我们从连接状态和流量监控两个层面来看。

5.1 使用 ss 命令替代 netstat 分析连接

netstat命令历史悠久，但在处理大量连接时效率较低。ss(socket statistics) 是它的现代替代品，速度更快，信息更直接。基本语法也类似。

查看所有已建立的TCP连接：

ss -t state established

查看所有监听中的端口：

ss -tuln

• -t: TCP协议
• -u: UDP协议
• -l: 仅显示监听中的套接字
• -n: 以数字形式显示地址和端口，不进行DNS解析和服务名查询（速度更快）
• -p: 显示使用该套接字的进程信息（需要sudo权限）

一个非常实用的组合是查看所有TCP连接及其对应的进程：

sudo ss -tunap

输出中，Local Address:Port和Peer Address:Port显示了本地和远端的地址端口对，users:后面则显示了进程ID和名称。这对于找出“谁在连接我的哪个端口”或者“我的程序在连接谁”至关重要。

5.2 实时网络流量监控：iftop 与 nethogs

ifconfig或ip -s link可以查看网卡收发数据包的总字节数，但无法知道流量具体流向。iftop可以实时显示网络带宽的使用情况，按主机对进行排序。

安装：sudo apt install iftop使用：sudo iftop -i eth0（将eth0替换为你的网卡名，可以用ip addr查看）

iftop界面分为三部分：顶部是刻度条，中间是当前流量最大的主机对列表（显示发送/接收速率和累计流量），底部是统计信息。你可以按h键查看帮助，按p切换显示端口号。

iftop告诉你流量在哪些IP之间流动，而nethogs则告诉你流量是由哪个进程产生的。这对于发现后台进程偷偷上传下载非常有效。

安装：sudo apt install nethogs使用：sudo nethogs eth0

nethogs界面类似top，按进程显示实时的下载和上传速率（KB/s）。你可以按m在KB/s、KB、B、MB等不同单位间切换。

5.3 网络性能基准测试：iperf3

当你怀疑网络带宽或质量有问题时，需要进行实测。iperf3是一个专业的网络性能测试工具。测试需要两台机器：一台作为服务器，一台作为客户端。

在服务器端（假设IP为192.168.1.100）运行：

sudo apt install iperf3 iperf3 -s

在客户端运行：

iperf3 -c 192.168.1.100

这会进行默认的TCP带宽测试。你可以添加参数进行更复杂的测试，例如测试UDP性能并指定带宽：iperf3 -c 192.168.1.100 -u -b 100M。测试结果会显示带宽、抖动、丢包率等关键指标。

6. 综合监控与自动化脚本实践

掌握了单个工具后，我们可以将它们组合起来，形成更强大的监控方案，或者制作成自动化脚本用于定期检查或故障排查。

6.1 使用 glances 进行一站式监控

glances是一个跨平台的、基于 curses 库或 Web 界面的综合监控工具。它在一个屏幕上集成了CPU、内存、交换分区、负载、网络、磁盘I/O、文件系统、传感器温度等几乎所有信息。

安装：sudo apt install glances运行：glances

在终端界面，你可以用c键按CPU排序，m键按内存排序，d键显示/隐藏磁盘I/O。更强大的是，它支持以Web服务器模式运行：

glances -w

然后你就可以在浏览器中访问http://<你的机器IP>:61208来查看监控面板了，这对于远程监控非常方便。

6.2 编写一个简单的资源监控脚本

我们可以写一个Bash脚本，定期收集关键指标并记录到日志文件，便于事后分析。

#!/bin/bash # 文件名：system_monitor.sh LOG_FILE="/var/log/system_monitor.log" INTERVAL=5 # 采集间隔，单位秒 while true; do TIMESTAMP=$(date '+%Y-%m-%d %H:%M:%S') # 1. 获取CPU负载（1分钟平均） LOAD1=$(uptime | awk -F'load average:' '{print $2}' | cut -d, -f1 | tr -d ' ') # 2. 获取内存可用量 (MB) AVAIL_MEM=$(free -m | awk '/^Mem:/ {print $7}') # 3. 获取根文件系统使用率 DISK_USAGE=$(df -h / | awk 'NR==2 {print $5}' | tr -d '%') # 4. 获取最耗CPU的进程（前1个） TOP_PROCESS=$(ps aux --sort=-%cpu | head -2 | tail -1 | awk '{print $11, $3"%"}') # 5. 获取总TCP连接数 TCP_CONN=$(ss -t state all | wc -l) # 连接数需要减去第一行标题行 TCP_CONN=$((TCP_CONN - 1)) echo "[$TIMESTAMP] Load1:$LOAD1, AvailableMem:${AVAIL_MEM}MB, DiskUsage:${DISK_USAGE}%, TopProcess:$TOP_PROCESS, TCPConn:$TCP_CONN" >> "$LOG_FILE" sleep $INTERVAL done

这个脚本每5秒采集一次系统负载、可用内存、磁盘使用率、最耗CPU的进程和TCP连接总数，并追加记录到日志文件中。你可以使用nohup ./system_monitor.sh &让它在后台运行。请注意，这个脚本比较简单，实际生产环境中可能需要更严谨的错误处理和更丰富的指标。

6.3 利用 watch 命令动态观察

如果你不想写脚本，只是想临时、动态地观察某个命令的输出变化，watch命令是你的好朋友。它定期执行指定的命令，并全屏刷新显示结果。

例如，每2秒刷新一次内存使用情况：

watch -n 2 free -h

动态观察网络连接数的变化：

watch -n 1 'ss -t state all | tail -n +2 | wc -l'

-n指定间隔秒数。按Ctrl+C退出。这是一个快速进行现场诊断的轻量级方法。

7. 常见问题排查与性能优化思路

掌握了监控工具，最终目的是解决问题。下面是一些典型场景的排查思路。

7.1 CPU使用率100%问题排查流程

1. 定位进程：使用top或htop，按P（按CPU%排序），找到占用最高的进程。记下其PID。
2. 分析进程类型：
   • 如果是java,python,node等应用进程，可能是业务逻辑陷入死循环、算法复杂度高、或频繁GC。
   • 如果是ksoftirqd,kworker等内核线程，可能硬件中断过多，或者有内核模块bug。
   • 如果是dd,gzip等工具，属于正常的高CPU占用。
3. 深入进程内部：
   • 对于Java应用，使用jstack <PID>打印线程栈，查看哪些线程在运行。通常CPU高的线程会在栈顶显示其正在执行的方法。
   • 对于C/C++等原生程序，可以使用perf工具进行性能剖析：sudo perf top -p <PID>。
   • 使用pidstat查看该进程的用户态和内核态CPU占比。如果%system异常高，说明系统调用频繁，可能涉及大量I/O或锁竞争。
4. 检查I/O等待：在top中观察%wa值。如果很高，说明CPU在等待磁盘，瓶颈在I/O。此时应使用iotop命令查看是哪个进程在进行大量磁盘读写。

7.2 内存不足与Swap频繁使用

当available内存很少，且si（swap in）和so（swap out）在vmstat或top中持续不为0时，说明系统正在频繁使用交换分区，这会严重拖慢性能。

1. 确认罪魁祸首：使用htop按M（按内存RES排序）或ps aux --sort=-%mem，找到消耗物理内存最多的进程。
2. 分析内存使用：对于可疑进程，可以查看其更详细的内存映射：sudo pmap -x <PID>。输出末尾的total kB大致对应RES。你也可以查看/proc/<PID>/smaps文件，了解其内存的具体分布（匿名页、文件映射页等）。
3. 检查内存泄漏：如果某个进程的RES或VIRT随时间持续增长，且没有合理的业务逻辑对应，可能存在内存泄漏。可以使用valgrind（针对开发测试）或持续监控/proc/<PID>/status文件中的VmRSS和VmSize字段来观察。
4. 调整Swappiness：内核参数vm.swappiness（0-100）控制系统使用Swap的倾向。值越高，越倾向于使用Swap。对于数据库服务器或追求性能的桌面，可以尝试调低（如设置为10）。临时修改：sudo sysctl vm.swappiness=10；永久修改：在/etc/sysctl.conf中添加vm.swappiness=10后执行sudo sysctl -p。

7.3 网络连接数过多或端口占用

遇到“Address already in use”错误或怀疑有服务异常占用端口时：

1. 查找端口占用者：sudo ss -tlnp | grep :<端口号>，例如sudo ss -tlnp | grep :80。-l表示监听，-n数字显示，-p显示进程。
2. 分析大量连接：如果连接数异常多（如ss -t state all | wc -l返回数万），使用sudo ss -t state established -p查看已建立连接的进程。可能是程序没有正确关闭连接（连接泄漏），或是正在遭受网络攻击（如CC攻击）。
3. 监控异常连接：使用iftop查看是否有异常的IP在产生大量流量。使用sudo netstat -natp | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n可以统计出每个远程IP建立了多少到本机的TCP连接，快速找出连接数最多的IP。

7.4 磁盘I/O成为瓶颈

系统响应慢，但CPU和内存都不高，很可能是磁盘I/O瓶颈。

1. 全局监控：使用iostat命令（来自sysstat包）：iostat -dx 2。关注%util列，它表示设备带宽利用率。如果持续接近100%，说明磁盘I/O饱和。同时观察await列，它表示I/O请求的平均等待时间（毫秒），如果很高（如超过20ms），说明磁盘响应慢。
2. 定位进程：使用iotop命令（需安装：sudo apt install iotop）来查看是哪些进程在进行磁盘读写，以及它们的读写速率。
3. 分析类型：是大量随机小IO（常见于数据库），还是顺序大IO（常见于日志写入、文件拷贝）？可以使用pidstat -d命令查看进程的IO统计数据。
4. 解决方案：优化程序逻辑减少IO、使用更快的存储（如SSD）、增加内存以提供更大的磁盘缓存、或者对磁盘进行RAID配置提升性能。

工具是死的，思路是活的。真正的排查过程往往是多个工具组合使用，根据初步线索层层深入。记住一个核心原则：先从全局（top,htop,glances）把握系统整体健康状况，再根据异常指标，使用专项工具（pidstat,iotop,iftop）进行下钻分析，最终定位到具体的进程、线程甚至代码行。这套方法论，远比死记硬背命令参数更重要。