Ubuntu系统资源监控实战：从CPU、内存到网络的全面排查指南

1. 引言：为什么你需要掌握系统资源监控

如果你在Ubuntu上跑过服务、部署过应用，或者仅仅是觉得电脑突然变慢了，那你大概率遇到过这样的场景：终端里敲命令，响应慢得像在爬；浏览器开几个标签页，风扇就开始狂转；后台跑个脚本，不知道它到底吃了多少内存。这时候，你需要的不是重启大法，而是一双能看清系统内部状况的“眼睛”。掌握查看系统资源占用的技能，就是给你自己装上这双眼睛。

这不仅仅是运维工程师的专利。对于开发者来说，它是定位性能瓶颈、优化代码的第一手资料；对于普通用户，它是判断“电脑是不是该升级了”或者“哪个软件是拖慢系统的元凶”的直接依据。CPU、内存、网络，这三者是现代计算系统的核心资源三角，任何一个出现瓶颈，都会直接影响你的使用体验和工作效率。

网上教程很多，但往往只告诉你一两个命令，比如top或htop，然后罗列一堆参数就结束了。这就像只给了你一把螺丝刀，却没告诉你哪颗螺丝该拧。实际工作中，你需要的是一个工具箱，以及知道在什么情况下该用哪件工具。今天，我们就来彻底搞懂在Ubuntu上监控系统资源的那些事，从最基础的命令到进阶的组合拳，让你不仅能“看到”，更能“看懂”和“解决”。

2. 核心监控工具全景图：从命令行到图形界面

在深入每个资源之前，我们有必要先建立一个全局视角。Ubuntu下的资源监控工具大致可以分为三类：经典的命令行工具、增强型交互工具以及图形化工具。每类工具都有其最佳使用场景。

2.1 经典命令行“三剑客”：top, vmstat, netstat

这三个命令历史悠久，几乎存在于所有Linux发行版中，是排查问题的基本功。

top命令是你打开终端后第一个应该想到的工具。它提供了一个动态、实时更新的系统进程和资源使用情况视图。运行top后，你会看到几块关键信息：

• 系统概要区：最上面几行显示了系统运行时间、登录用户数、系统平均负载（load average），以及CPU和内存的使用情况汇总。平均负载的三个数字（如 0.05, 0.10, 0.15）分别代表过去1分钟、5分钟、15分钟的平均负载，对于多核CPU，这个数值需要除以核心数来理解其繁忙程度。
• 进程列表区：下面则是各个进程的详细信息，默认按CPU使用率降序排列。关键列包括：
  • PID: 进程ID。
  • %CPU: 进程占用的CPU时间百分比。
  • %MEM: 进程使用的物理内存百分比。
  • COMMAND: 启动此进程的命令行。

vmstat（virtual memory statistics）则侧重于内存、进程、CPU活动等系统整体指标。它的优势在于可以以固定间隔采样，适合观察一段时间内的趋势。例如，vmstat 2 5表示每隔2秒采样一次，共采样5次。输出中的si（swap in）和so（swap out）如果持续大于0，就是内存不足、开始使用交换空间的明确信号，这是系统变慢的一个重要原因。

netstat曾经是查看网络连接、路由表、接口统计信息的瑞士军刀。虽然在新系统中逐渐被功能更强大的ss命令取代，但它依然广泛使用。netstat -tunlp可以列出所有TCP/UDP监听端口以及对应的进程，是排查“端口被谁占了”问题的利器。

2.2 增强型交互工具：htop, glances, nmon

如果你觉得top的界面不够友好，那么htop绝对是你的菜。它可以说是top的现代化增强版，具有彩色输出、鼠标支持、垂直和水平滚动、树状视图显示进程关系等特性。你可以直接用方向键选择进程，按F9发送信号（如终止进程），按F2进入设置界面，用户体验提升巨大。安装也简单：sudo apt install htop。

glances是一个跨平台的、基于curses库的系统监控工具，它在一个屏幕上用不同的颜色高亮显示了几乎所有的关键信息：CPU、内存、负载、网络I/O、磁盘I/O、以及最消耗资源的进程列表。它还能以客户端/服务器模式运行，方便远程监控。安装命令：sudo apt install glances。

nmon则是性能分析人士的最爱，尤其擅长将性能数据记录到文件，供事后分析。它同样提供实时视图，可以非常直观地查看CPU、内存、网络、磁盘等数十种指标。你可以通过sudo apt install nmon安装，然后运行nmon，通过按单键（如cfor CPU,mfor Memory,nfor Network）来切换不同资源的视图。

2.3 图形化工具：系统监视器与GNOME System Monitor

对于桌面用户，Ubuntu自带的“系统监视器”（GNOME System Monitor）是一个零学习成本的完美选择。你可以在应用菜单中直接搜索打开。它提供了三个标签页：

• 进程：类似htop的图形化列表，可以排序、搜索、结束进程。
• 资源：以历史图表的形式展示CPU、内存和网络的历史使用情况，非常直观。
• 文件系统：显示磁盘空间的使用情况。

它的优势在于可视化，能让你一眼就看到历史趋势，比如内存使用量是否在缓慢增长（可能存在内存泄漏），或者网络活动是否在某个时间点出现峰值。

提示：在服务器环境或无图形界面的系统中，命令行工具是你的唯一选择。而在日常桌面使用中，结合图形化工具快速概览和命令行工具深度排查，效率最高。

3. 深度剖析CPU使用情况

CPU是系统的大脑，其使用率是衡量系统繁忙程度的核心指标。但看CPU使用率，不能只看一个总的百分比。

3.1 理解CPU使用率的构成

在top或htop中，CPU一行通常会显示如下的信息：%Cpu(s): 12.5 us, 6.2 sy, 0.0 ni, 81.0 id, 0.2 wa, 0.0 hi, 0.0 si, 0.0 st。这些缩写代表：

• us(user): 运行用户空间进程（也就是你的应用程序）所花费的时间百分比。
• sy(system): 运行内核空间进程（系统调用）所花费的时间百分比。如果这个值持续很高，可能意味着内核在处理大量I/O或进程调度。
• id(idle): CPU空闲时间百分比。这是你最希望看到的数字，越高说明系统越“轻松”。
• wa(iowait): CPU等待I/O（通常是磁盘I/O）完成的时间百分比。这是一个非常关键的指标。如果wa持续很高（比如超过20%），而id很低，即使总的CPU使用率不高，系统也会感觉非常卡顿，因为CPU都在“空转”等待慢速的磁盘。这时候瓶颈在磁盘，而不是CPU。
• st(steal): 在虚拟化环境中（如云服务器），被宿主机“偷走”的时间百分比。如果你的虚拟机性能不稳定，可以关注这个值是否过高。

所以，当你发现系统卡顿时，首先看wa和id。高wa指向磁盘问题，低id且高us/sy才是真正的CPU算力不足。

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

top和htop能告诉你哪个进程现在最耗CPU，但如果你想知道一个进程在一段时间内的平均CPU消耗，或者想监控某个特定进程，pidstat是更好的工具。它是sysstat软件包的一部分，需要安装：sudo apt install sysstat。

例如，你想每2秒采样一次，共采样10次，并查看所有进程的CPU使用情况：pidstat -u 2 10。如果你想监控特定进程（如PID为1234），可以：pidstat -u -p 1234 2 10。它的输出包含了用户态和内核态的CPU时间，能更精细地分析进程行为。

3.3 实战：定位CPU占用飙升的“元凶”

假设你的服务器在凌晨突然收到告警，CPU使用率持续超过90%。你通过SSH登录后，应该如何排查？

1. 快速概览：首先运行top，按1键（数字1）展开所有CPU核心的单独显示，看是单个核心打满还是所有核心都高。同时观察wa值，排除磁盘I/O瓶颈。
2. 定位进程：在top视图中，进程默认按%CPU排序，排在第一位的很可能就是“元凶”。记下它的PID和COMMAND。
3. 深入分析进程：如果进程是Java/Python等解释型语言，高CPU可能意味着陷入死循环或复杂计算。你可以用pidstat对该PID进行细粒度采样，或者使用更专业的工具：
   • 对于Java进程：使用jstack <pid>获取线程堆栈，结合top -H -p <pid>查看哪个线程CPU高，然后将线程ID（十进制）转换为十六进制，在jstack的输出中搜索，就能定位到问题代码行。
   • 对于其他进程：可以使用strace -cp <pid>来统计系统调用，看是否在频繁执行某些调用。
4. 历史回溯：如果问题已经发生，你可以查看/var/log/syslog或系统的监控历史数据（如果部署了Prometheus、Zabbix等），看问题发生时间点附近有哪些日志或事件。

一个我踩过的坑：有一次一个后台数据处理服务CPU持续100%，top显示是一个Python进程。用strace发现它在疯狂进行stat系统调用。最后发现是代码中一个目录遍历的逻辑错误，在循环里反复检查一个不存在的目录，导致无意义的系统调用风暴。修复循环判断条件后，CPU使用率立刻降到1%以下。

4. 全面掌握内存使用分析

内存管理是Linux系统中最精妙也最容易让人困惑的部分。free -m命令显示的内存信息，就经常引发误解。

4.1 解读free命令：你的内存真的被用光了吗？

运行free -h（-h表示人类可读格式），你会看到类似下面的输出：

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

关键是要理解每一列的含义：

• total: 物理内存总量。
• used: 已使用的内存。注意：这个值包含了buffers和cached！所以它往往很大。
• free: 完全未被使用的内存。这个值小不一定代表内存紧张。
• buff/cache: 这是核心所在。buffers是内核缓冲区用的内存，cache是页缓存和slab。简单理解，这部分内存被用来缓存磁盘数据和内核对象，目的是加速系统性能。当应用程序需要更多内存时，这部分缓存可以被立刻回收。所以它不算“被占用”。
• available:这才是判断内存是否充足的关键指标。它估算的是在不使用交换空间的情况下，可以分配给新应用程序的内存大小。它等于free+ 可回收的buff/cache。上例中，虽然used显示2.1G，free只有1.5G，但available高达5.0G，说明内存非常充裕。
• Swap: 交换分区使用情况。如果used持续增长，说明物理内存确实不足，系统开始把不常用的内存页换出到磁盘，这会导致性能严重下降。

所以，看内存压力，首要关注available和Swap used，而不是free。

4.2 深入/proc文件系统：smem与/proc/meminfo

/proc是一个虚拟文件系统，提供了内核内部数据的接口。/proc/meminfo文件包含了最详细的内存统计信息。free和top等命令的数据都来源于此。直接cat /proc/meminfo可以看到MemTotal,MemFree,Buffers,Cached,SwapCached等数十个指标，适合深度分析。

smem是一个更直观的工具，它能显示进程的内存使用情况，并且按照不同的计算方式（如PSS、USS）呈现。PSS（Proportional Set Size）对于共享内存的计算更合理，是衡量进程实际占用物理内存的更好指标。安装：sudo apt install smem。使用smem -t -p可以以百分比和表格形式查看，一目了然。

4.3 实战：诊断内存泄漏与OOM Killer

内存泄漏是后台服务常遇到的问题。症状通常是available内存随时间缓慢但持续地减少，即使服务负载没有增加。重启服务后，内存恢复正常，但几天后又慢慢涨上去。

排查步骤：

1. 确认泄漏：使用watch -n 5 ‘free -h‘命令，每5秒刷新一次内存情况，观察available和buff/cache的变化趋势。如果available持续下降，而buff/cache变化不大，基本可以断定是应用程序内存泄漏，而非系统缓存增长。
2. 定位泄漏进程：使用smem或htop，按内存使用排序，观察哪个进程的RES（常驻内存）或PSS在持续增长。对于容器环境，可以使用docker stats。
3. 分析进程内部：如果是Java进程，可以使用jmap -histo:live <pid>查看堆内存中的对象分布，或者使用jcmd <pid> GC.heap_info。结合监控工具（如VisualVM, JMC）进行实时堆转储分析是更有效的方法。
4. 应对OOM Killer：当系统内存严重不足时，Linux内核的“Out-Of-Memory Killer”会被触发，它会选择一个“最不重要”的进程杀死以释放内存。被杀的进程会在/var/log/kern.log或dmesg输出中留下记录（搜索"Out of memory"或"Killed process"）。优化方向一是增加内存或优化应用，二是通过调整/proc/<pid>/oom_score_adj来影响进程被选中的优先级（值越低越不容易被杀）。

我曾经管理过一个Go语言写的API服务，每隔一周左右就会因为内存泄漏被OOM Killer干掉。用smem观察到其PSS每天增长约200MB。最终使用pprof进行堆分析，发现是一个全局的缓存map只增不减，没有设计淘汰策略。增加了LRU淘汰机制后，问题解决。

5. 网络流量与连接监控

网络问题往往更复杂，因为它涉及本地连接、远程主机、协议和端口。监控网络主要关注两点：流量（带宽）和连接状态。

5.1 实时流量监控：iftop, nload, vnstat

iftop类似于top，但是用于网络接口。它可以实时显示当前主机上各个网络连接的带宽使用情况，按流量排序。安装：sudo apt install iftop。运行sudo iftop -i eth0（将eth0替换为你的网卡名）即可。它能非常直观地告诉你“到底是哪个IP在疯狂上传/下载”。

nload则更简洁，它专注于显示每个网络接口的实时流量图表，包括流入（Incoming）和流出（Outgoing）的实时速率、平均速率、最大速率以及数据总量。安装：sudo apt install nload。运行nload eth0即可。

vnstat是一个基于控制台的网络流量统计工具，它的特点是轻量级、后台运行、统计历史数据。它不实时显示流量，而是定期（如每5分钟）将网卡流量记录到数据库，然后你可以查询每天、每周、每月的流量总计。安装后需要先为指定网卡初始化数据库：sudo vnstat -i eth0 --create，然后可以通过vnstat -d（日）、vnstat -m（月）等命令查看。这对于监控服务器月度流量消耗非常有用。

5.2 连接状态分析：ss命令的完全指南

如前所述，netstat已老，ss（socket statistics）是它的现代替代品，速度更快，信息更详细。掌握ss的常用组合至关重要：

• ss -tlnp: 查看所有监听（LISTEN）的TCP端口，并显示对应的进程名和PID。这是查看本机开放了哪些服务端口的首选命令。
• ss -tunp: 查看所有TCP和UDP连接（包括监听和非监听），并显示进程信息。-u表示UDP。
• ss -s: 查看套接字统计摘要，显示各种类型的连接总数，快速了解系统连接概况。
• ss -o state established ‘( dport = :443 or sport = :443 )‘: 这是一个更高级的用法，查看所有与443端口相关的已建立连接，并显示定时器信息（如keepalive时间）。这对于排查连接不释放的问题很有帮助。

5.3 实战：排查服务器网络异常（高连接数、端口占用）

场景：服务器响应变慢，怀疑是网络连接数过多或某个端口被异常占用。

1. 查看连接数概况：运行ss -s。关注Total连接数是否异常高。如果TIME-WAIT状态连接特别多，可能是短连接服务没有正确设置TCP参数（如tcp_tw_reuse）。
2. 定位异常连接：运行ss -tunp | head -20，查看当前活跃的连接。关注那些你不认识的远程IP或非常用端口。可以使用grep过滤，例如ss -tunp | grep :8080查看所有涉及8080端口的连接。
3. 排查端口占用：如果你想启动一个服务，发现端口（比如3000）被占用，运行sudo ss -tlnp | grep :3000。它会告诉你哪个进程的PID占用了这个端口。然后你可以用ps aux | grep <PID>找到具体的进程，决定是否要终止它。
4. 监控实时流量：如果怀疑有异常流量（如被攻击或爬虫），运行sudo iftop -i eth0。观察是否有单个IP在短时间内产生了巨大的流量。结合ss命令，你可以找到该IP对应的连接和进程。

一个常见的坑是“TIME-WAIT”堆积。我们的一个Web服务器在承受高并发压力测试后，ss -s显示有上万个TIME-WAIT连接。这是因为HTTP短连接在关闭后，会进入TIME-WAIT状态，等待2MSL（最大报文段生存时间，通常2分钟）以确保网络中旧的重复报文消散。对于高并发短连接服务，这会导致端口资源快速耗尽。解决方案是调整内核参数，如启用net.ipv4.tcp_tw_reuse和net.ipv4.tcp_timestamps，让内核更积极地复用处于TIME-WAIT状态的套接字。但修改内核参数需要谨慎，并充分测试。