Linux系统资源监控命令详解：lscpu、top、free、df与w实战

最近在排查线上服务器负载问题时，发现很多刚接触 Linux 的同学对系统资源查看命令的使用还停留在“会敲命令但不理解输出”的阶段。比如top里那一大屏指标分别代表什么？free显示的 buffer 和 cache 有什么区别？df出来磁盘明明还有空间，为什么应用还报“磁盘已满”？这些问题如果你也遇到过，那这篇文章正好适合你。

本文将围绕lscpu、w、top、free、df五个命令展开，逐个拆解它们的作用、常用参数、输出字段含义，并给出实际排查场景中的组合用法。无论你是刚入门 Linux 的新手，还是需要经常登录服务器排查问题的后端开发、运维同学，这篇文章都能帮你把系统资源监控这块知识补完整。

1. 背景与核心概念

1.1 为什么需要掌握这些命令

Linux 服务器运行过程中，CPU、内存、磁盘、负载是四类最核心的资源。当业务出现卡顿、接口超时、服务宕机时，第一步往往不是看日志，而是先登录服务器确认资源状态。这一套命令就是最常见的“第一视角”。

• lscpu：查看 CPU 架构、核心数、型号等静态信息。
• w：查看当前系统负载、登录用户、每个终端正在执行的命令。
• top：实时查看进程级 CPU、内存占用，是定位资源消耗大户的利器。
• free：查看物理内存和交换分区的使用情况。
• df：查看文件系统磁盘空间占用。

把这五个命令组合起来，基本可以回答以下问题：

• 服务器是不是负载过高？
• CPU 是计算密集还是等待 IO？
• 内存是否不足？有没有用到 swap？
• 磁盘空间还剩多少？哪个目录占得最多？
• 哪个进程在消耗资源？

1.2 负载、CPU、内存、磁盘之间的关系

在进入命令细节之前，有必要理清几个容易混淆的概念。

系统负载（Load Average）是 Linux 中非常经典的指标，它表示一段时间内处于可运行状态和不可中断睡眠状态的进程平均数。简单理解，就是“有多少任务在等待 CPU 处理”。top和w第一行都会显示三个数字，分别对应 1 分钟、5 分钟、15 分钟的平均负载。

这里有一个常见误区：负载高不等于 CPU 使用率高。如果进程大量阻塞在磁盘 IO 上，也会表现为负载高，但 CPU 可能很空闲。所以排查时不能只看负载数值，还要结合 CPU 的 us、sy、wa 等指标一起判断。

内存（Memory）分为物理内存和交换分区（swap）。Linux 的内存管理机制比较特殊，它会尽量利用空闲内存做文件缓存（cache），提升 IO 性能。所以看到free中 used 很高时，不一定代表内存真的不够用，需要结合 buffer/cache 和 available 来判断。

磁盘（Disk）的占用和文件系统挂载密不可分。df查看的是文件系统级别的使用率，而具体哪个目录占用大，需要配合du来定位。

把这几个概念放在一起，你就有了一个基本认知模型：CPU 负责计算，内存负责临时数据，磁盘负责持久化，负载反映整体压力。接下来要学习的命令，都是围绕这个模型展开的。

2. 环境准备与命令概览

2.1 运行环境说明

本文命令在以下环境中验证通过，绝大多数 Linux 发行版都通用：

如果你使用的是精简版容器镜像，可能默认没有安装这些命令。以 Ubuntu 为例，安装命令如下：

# Ubuntu / Debian apt update && apt install -y procps util-linux coreutils # CentOS / Rocky / RHEL yum install -y procps-ng util-linux coreutils

其中procps-ng提供top、free、w等命令，util-linux提供lscpu，coreutils提供df。不同发行版包的名称可能略有差异，按实际环境调整即可。

2.2 查看命令帮助

每个命令都有--help和man文档，学习时建议先扫一眼帮助，了解有哪些参数，不必全部背下来。

lscpu --help w --help top --help free --help df --help

需要注意的是，不同发行版对命令参数的支持可能略有不同，比如free的--total参数在 CentOS 6 上就不存在。如果你在生产环境发现某个参数不可用，优先执行man 命令名查看当前版本支持的参数列表。

3. lscpu 命令详解：查看 CPU 架构与核心信息

3.1 lscpu 能告诉我们什么

lscpu用于显示 CPU 架构信息，它从/proc/cpuinfo和sysfs中收集数据，并以更易读的格式输出。执行后你会看到类似下面的内容：

$ lscpu Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 8 On-line CPU(s) list: 0-7 Thread(s) per core: 2 Core(s) per socket: 4 Socket(s): 1 NUMA node(s): 1 Vendor ID: GenuineIntel CPU family: 6 Model: 158 Model name: Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz Stepping: 9 CPU MHz: 2800.000 CPU max MHz: 3800.0000 CPU min MHz: 800.0000 BogoMIPS: 5616.00 Virtualization: VT-x L1d cache: 32K L1i cache: 32K L2 cache: 256K L3 cache: 6144K NUMA node0 CPU(s): 0-7

3.2 核心字段解读

理解这几个字段后，你可以快速得出一个关系式：

逻辑 CPU 总数 = Socket 数 × 每个 Socket 核心数 × 每个核心线程数

例如上面的输出：1 * 4 * 2 = 8，和CPU(s): 8完全吻合。

3.3 常用参数与场景

lscpu的常用参数不多，重点记住以下几个：

# 查看 CPU 核心与 NUMA 映射 lscpu -e # JSON 输出，方便脚本解析 lscpu -J

在实际项目中，lscpu最常用于两个场景：

1. 判断服务器 CPU 规格：新接手一台服务器时，先用lscpu确认核心数和架构，避免装错软件版本。比如在 ARM 服务器上安装 x86 的软件包，会直接报错。
2. 配合容器和 JVM 调优：确认 CPU 核心数后，可以合理设置 JVM 线程池大小、Nginx worker_processes 数量等参数。

这里补充一个常见坑点：很多云服务器买的是 4 核，但在系统内看到CPU(s): 8，这是因为开启了超线程。如果做性能测试，物理核数往往比逻辑核数更能反映真实算力。

4. w 命令详解：查看系统负载与登录用户

4.1 w 命令输出解读

w命令同时展示系统负载、当前时间、开机时长、登录用户数，以及每个终端用户正在执行的命令。执行如下：

$ w 10:36:18 up 3 days, 2:15, 2 users, load average: 0.18, 0.21, 0.19 USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT root pts/0 192.168.1.102 Wed09 1.00s 0.02s 0.02s -bash ubuntu pts/1 192.168.1.101 Wed10 2:30 0.05s 0.05s top

4.2 第一行信息解读

第一行和uptime命令输出一致：

• 10:36:18：当前系统时间。
• up 3 days, 2:15：系统已运行 3 天 2 小时 15 分钟。
• 2 users：当前登录用户数。
• load average: 0.18, 0.21, 0.19：1 分钟、5 分钟、15 分钟的平均负载。

关于负载值的判断，有一个经验参考：如果负载长期大于逻辑 CPU 数量，说明系统可能已经过载。比如 8 核机器负载长期 15+，那大概率有进程在争抢 CPU。

4.3 列表字段解读

4.4 常用参数

# 不显示标题行，适合脚本使用 w -h # 以短格式显示，不显示登录来源和登录时间 w -s # 指定查看某个用户 w root

w命令在运维中比较实用的是快速确认“谁在服务器上”“在跑什么命令”。如果发现陌生 IP 登录且正在执行危险命令，需要立即引起警惕。比如看到某个用户正在运行rm -rf /或下载可疑脚本，就要及时处理。

5. top 命令详解：实时监控进程资源占用

5.1 top 基础视图

top是 Linux 系统监控中使用频率最高的命令之一。它每隔一段时间刷新一次，默认显示进程并按照 CPU 使用率排序。执行top后，界面分为上下两部分：头部是系统整体信息，下面是进程列表。

top - 10:40:01 up 3 days, 2:18, 2 users, load average: 0.10, 0.15, 0.18 Tasks: 212 total, 1 running, 211 sleeping, 0 stopped, 0 zombie %Cpu(s): 2.3 us, 1.0 sy, 0.0 ni, 96.3 id, 0.3 wa, 0.0 hi, 0.0 si, 0.0 st MiB Mem : 15884.3 total, 2048.5 free, 10234.2 used, 3601.6 buff/cache MiB Swap: 2048.0 total, 2048.0 free, 0.0 used. 3840.5 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1234 root 20 0 1624.4m 1.2g 2.2m S 12.5 7.7 5:23.45 java 5678 www 20 0 812.4m 89.0m 1.1m S 2.0 0.6 1:05.20 nginx

5.2 头部信息逐行拆解

第二行 Tasks 行：

• 212 total：进程总数。
• 1 running：正在运行的进程数。
• 211 sleeping：睡眠中的进程数。
• 0 zombie：僵尸进程数，如果长期不为 0，需要关注父进程是否正常回收子进程。

第三行 CPU 状态行：

• us（user）：用户态 CPU 占比。
• sy（system）：内核态 CPU 占比。
• ni（nice）：调整过优先级的进程占用 CPU 占比。
• id（idle）：空闲 CPU 占比。
• wa（iowait）：等待 IO 完成的 CPU 占比。这个值偏高，说明磁盘或网络 IO 可能存在瓶颈。
• hi（hardware irq）：硬件中断占用。
• si（software irq）：软件中断占用。
• st（steal）：被虚拟机管理程序偷走的 CPU 时间。云服务器上这个值偏高，说明宿主机资源争抢严重。

第四行内存行（Mem）：

• total：物理内存总量。
• free：完全空闲的内存。
• used：已使用的内存。
• buff/cache：用于缓冲和缓存的内存。

第五行交换分区行（Swap）：

• total：swap 总量。
• free：swap 空闲量。
• used：swap 已用量。如果 swap used 持续增长，通常说明物理内存不足，需要警惕。

5.3 进程列表字段解读

5.4 常用交互快捷键

进入top界面后，可以按键交互操作：

一个很有用的组合是：进入top后先按M按内存排序，再按c显示完整命令行，可以快速定位是哪个 Java 应用或者哪个 Python 脚本占用内存最多。

5.5 top 常用启动参数

很多老师在排障时习惯一条命令直接拿到关键信息：

# 非交互模式，刷新 1 次后退出，适合脚本采集 top -b -n 1 # 只显示指定 PID 的进程 top -p 1234 # 设置刷新间隔为 2 秒 top -d 2 # 按内存排序输出 top -b -n 1 -o %MEM

在实际脚本监控中，top -b -n 1是最常用的模式，因为它不会进入交互界面，可以直接把结果重定向到文件或交给其他命令处理：

# 把 top 快照保存到文件 top -b -n 1 > /tmp/top_snapshot.txt

6. free 命令详解：查看内存使用情况

6.1 free 基础用法

free用于查看系统内存使用情况。最简单的执行方式：

$ free total used free shared buff/cache available Mem: 15884 4136 5968 116 5780 9940 Swap: 2047 0 2047

不过现在主流 Linux 发行版更推荐使用free -h，以人类可读的格式显示：

$ free -h total used free shared buff/cache available Mem: 15Gi 4.0Gi 5.8Gi 116Mi 5.6Gi 9.7Gi Swap: 2.0Gi 0B 2.0Gi

6.2 字段解读与重要概念

这里最需要理解的是free和available的区别。很多新手看到used很高就以为内存不足，实际上 Linux 会主动把空闲内存用作文件缓存（cache），以便加速读写。这部分内存在应用需要时会被内核自动释放，所以available才是“真正还能用多少”的参考值。

判断内存是否吃紧，更可靠的指标是：

• available是否长期偏低。
• swap used是否持续增长。

如果swap开始频繁使用，说明物理内存已经不够了，大量内存页在内存和磁盘之间换入换出，性能会明显下降。

6.3 常用参数

# 人类可读格式 free -h # 以 MB 为单位显示 free -m # 以 GB 为单位显示 free -g # 每秒刷新一次，类似 top 的实时模式 free -s 1 # 显示总计行（多节点内存时有用） free -t

free -s 1可以连续刷新，适合观察内存变化趋势。比如执行一个压力测试脚本时，另开一个终端用free -s 2监控内存变化，能直观看到内存增长曲线。

6.4 内存排查实战示例

假设你收到告警说服务器可用内存不足，可以通过以下步骤快速定位：

# 第一步：确认整体内存状态 free -h # 第二步：按内存占用排序查看进程 top -b -n 1 -o %MEM | head -20 # 第三步：查看具体进程的详细内存信息（以 PID 为例） cat /proc/1234/status | grep -E "VmRSS|VmSize|VmSwap"

VmRSS表示进程实际占用的物理内存，VmSwap表示进程占用的交换分区大小。如果某个进程的VmSwap很大，说明它已经被换出到磁盘，性能会明显下降。

7. df 命令详解：查看磁盘空间使用情况

7.1 df 基础用法

df（disk free）用于查看文件系统的磁盘空间使用情况。常规用法：

$ df -h Filesystem Size Used Avail Use% Mounted on /dev/vda1 50G 23G 25G 49% / devtmpfs 7.8G 0 7.8G 0% /dev tmpfs 7.8G 0 7.8G 0% /dev/shm tmpfs 7.8G 12M 7.8G 1% /run tmpfs 7.8G 0 7.8G 0% /sys/fs/cgroup

-h参数把容量转换为人类可读格式，是最常用的展示方式。

7.2 字段解读

7.3 常用参数

# 显示 inode 使用情况 df -i # 只显示本地文件系统，不显示 tmpfs 等虚拟文件系统 df -h -x tmpfs -x devtmpfs # 查看指定目录所在文件系统 df -h /var/log # 以 MB 为单位输出 df -m

df -i是一个容易被忽略但非常重要的参数。它显示的是 inode 的使用情况。有时候df -h显示磁盘还有空间，但应用却报错“No space left on device”，就是因为 inode 用满了。这种情况下，需要找到小文件过多的目录进行清理。

7.4 磁盘空间排查流程

当你发现磁盘使用率超过 80% 时，可以按以下流程定位：

# 第一步：查看整体磁盘使用情况 df -h # 第二步：找到占用大的目录（从根目录开始逐层深入） du -sh /* 2>/dev/null | sort -hr | head # 第三步：精确定位到具体目录 du -sh /var/* 2>/dev/null | sort -hr | head # 第四步：查看是否有已删除但仍被占用的文件 lsof | grep deleted

第四步是一个很经典的坑：运维同学删除了大文件，但df -h显示空间没有释放。原因是有进程仍然持有该文件的句柄，文件虽然从目录中删除了，但磁盘空间要等进程关闭文件后才会释放。此时用lsof | grep deleted找到对应进程，重启进程即可释放空间。

8. 组合实战：一次完整的系统资源排查

掌握了单个命令之后，更重要的是学会如何组合使用。下面模拟一个真实场景。

8.1 场景描述

业务反馈“系统访问变慢”，登录服务器进行排查。

8.2 排查步骤与命令

第一步：查看负载和登录情况。

w

输出负载值为3.20, 2.85, 2.10，登录了 3 个用户。如果是 4 核机器，这个负载已经偏高了。

第二步：确认 CPU 核心数。

lscpu | grep -E "^CPU\(s\)|^Model name"

确认是 4 核 8 线程的机器。负载 3.2 虽然还没超过 8，但已经明显在上升。

第三步：查看 CPU 和负载细节。

top -b -n 1 | head -15

发现%Cpu(s)中wa高达 30%，说明 CPU 大量时间在等待 IO。同时看到一个 Java 进程 CPU 占用 45%。

第四步：查看内存状态。

free -h

available只剩 1.2G，swap used接近 1G，说明物理内存比较紧张。

第五步：查看磁盘状态。

df -h

根分区使用率 92%，同时在dmesg中看到大量 IO 错误。

8.3 结论

综合以上信息，可以初步判断：

• 根分区磁盘空间不足，可能影响日志写入。
• IO 等待高，磁盘读写性能成为瓶颈。
• 内存紧张导致部分内存换入换出到 swap，进一步加剧磁盘 IO 压力。
• Java 应用占用资源较多，需要进一步排查其 GC 或线程池配置。

这个排查过程并不复杂，但每一步都依赖对单个命令输出字段的准确理解。这也是本文把这些命令放在一起讲的原因：它们是同一套排查体系的不同零件。

9. 常见问题与排查思路

在实际使用中，经常有人因为输出理解偏差而误判。下面整理几个高频问题。

这里特别提醒一点：top中的%CPU默认是单个 CPU 核心的百分比，如果进程是多线程的，实际占用需要乘以核心数。比如一个 8 线程进程在 8 核机器上显示 100%，实际上占满了所有核心。不过现代版本top已经会将多线程 CPU 时间汇总，具体表现因版本而异。

10. 最佳实践与工程建议

10.1 养成先整体后局部的排查习惯

遇到系统问题，严格按照“负载 → CPU → 内存 → 磁盘 → 进程”的顺序排查，不要上来就kill进程。整体指标能帮你说清问题范围，局部定位才能找到根因。

推荐顺序：

# 1. 负载 uptime # 2. CPU 核心数 lscpu | grep "^CPU(s)" # 3. CPU 占用和负载 top -b -n 1 | head -15 # 4. 内存 free -h # 5. 磁盘 df -h

10.2 采集中使用非交互模式

如果要把监控数据写入日志或告警脚本，务必使用非交互模式，避免命令卡住或输出控制字符。

# 正确的采集方式 top -b -n 1 | head -20 > /tmp/top_$(date +%F).log free -h >> /tmp/mem_$(date +%F).log df -h >> /tmp/disk_$(date +%F).log

10.3 关注趋势而非瞬时值

单次执行top或free只能看到瞬间的状态，容易误判。比如某个瞬时 CPU 100% 可能只是启动时的初始化行为。建议：

• 使用top -d 2 -n 5观察一段时间内的变化。
• 使用free -s 5 -c 12观察 1 分钟内存变化。
• 结合监控系统（如 Prometheus + node_exporter）保留历史数据。

10.4 注意生产环境的权限和安全

执行top的k命令、free的系统调用等操作时，要确认当前用户具有合法授权。生产环境禁止随意 kill 进程，尤其是数据库、注册中心等核心服务。如果确实需要结束进程，先确认进程 PID 和父进程关系：

# 查看进程父子关系 ps -ef | grep PID

10.5 推荐组合工具

这五个命令是基础，但在大型项目排查中，还可以搭配以下工具：

10.6 日志和知识沉淀

每次排查完问题，建议把当时的命令、输出和结论记录到团队知识库。很多看起来复杂的故障，其实只是几个命令组合使用的问题。沉淀成文档后，下次遇到类似问题，按图索骥就能快速解决。

11. 总结

这篇文章详细拆解了lscpu、w、top、free、df五个命令的核心输出和实战用法。我们从概念上理清了负载、CPU、内存、磁盘之间的关系，又通过一个完整的排查场景把这些命令串联起来。学完之后，你应该能独立完成一次基本的系统资源体检，能够判断“系统到底是不是负载过高”“内存是否真的不够”“磁盘空间为什么没释放”等问题。

这五个命令只是 Linux 系统监控的起点。下一步可以继续学习iostat、pidstat、sar等性能分析工具，也可以结合node_exporter把监控指标接入 Prometheus，实现历史趋势分析和告警。但在那之前，把基础命令的每个字段都看懂，排查问题时不慌不乱，是更重要的一步。

如果你在阅读过程中发现命令行输出和你的系统有差异，建议先执行man 命令名查看当前版本的文档。不同发行版、不同版本之间的输出格式确实会有细微差别，理解原理远比背诵输出格式更有价值。