如果你经常登录服务器排查问题，肯定被这几个问题折腾过：CPU 到底几核？负载算不算高？内存是不是不够用了？磁盘怎么又满了？这次把 Linux 上最常用的五个命令lscpu、w、top、free、df一次性讲透。它们都是系统自带工具，不需要额外安装，不占监控 Agent 资源，单个命令看一个维度，组合起来正好覆盖日常性能排查的第一轮判断。
文章会做四件事：先给一张核心能力速览表，再逐个拆解命令的关键字段和常用参数，接着给一套从负载到进程到内存再到磁盘的排查顺序，最后补充自动化采集脚本和常见坑。适合刚接触服务器维护的运维新手，也适合需要写排查脚本的开发同学。
1. 核心能力速览
| 命令 | 作用 | 主要输出 | 最常用场景 |
|---|---|---|---|
lscpu | 查看 CPU 架构、核数、频率、缓存、虚拟化支持 | CPU 数量、型号、架构、NUMA 节点 | 确认服务器规格，判断逻辑核和物理核 |
w | 查看系统负载、在线用户、每个用户占用的终端和任务 | load average、用户终端、JCPU、PCPU | 快速判断系统是否高负载，谁在干活 |
top | 动态查看进程级 CPU、内存占用 | 系统总览、CPU 统计、内存统计、进程列表 | 定位占用最高的进程，观察 CPU 和内存分配 |
free | 查看物理内存和 Swap 使用情况 | total、used、free、shared、buff/cache、available | 判断内存是否充足，排查 OOM 风险 |
df | 查看文件系统磁盘空间和 inode 使用情况 | 文件系统、容量、已用、挂载点 | 检查磁盘是否满，定位 "No space left" 问题 |
这五个命令的共同点是：全部来自系统基础工具包，读取的是/proc等内核接口，执行成本低，普通用户即可运行。组合使用的时候，先看w确认负载，再用top找进程，用free看内存压力，用df排除磁盘空间问题，最后用lscpu确认 CPU 规格作为判断阈值的基础。
2. 适用场景与使用边界
这套命令最适合做第一轮性能排查。比如线上告警说接口变慢、服务器负载高、某个进程被杀，你登录机器后必须在几分钟内给出初步判断。这时候打开终端依次执行w、top、free、df，基本能把问题范围缩到 CPU、内存、磁盘这几个大类里。
它也适合做硬件信息核对。采购的机器到了，或者云主机配置有疑问，用lscpu看核数和架构，用free -h看内存总量，用df -h确认数据盘是否挂载，比登录云控制台还要快。
但也有明显边界：这几个命令都是瞬时快照，不能替代专业监控系统。要看趋势曲线，得配合探针采集；要看历史负载，得依靠 Prometheus 或 Zabbix 这类平台。另外top虽然可以动态刷新，但它本身是一个交互程序，在自动化脚本里需要用批处理模式，否则会卡住。free显示的内存使用量也不能直接当“内存告急”的标志，必须先理解available和buff/cache的含义。
操作边界也要注意：top里的k可以直接杀进程，free的缓存回收操作会影响性能，df显示某个挂载点满了时不要盲目删文件，尤其是生产环境。所有会改变系统状态的命令，都要先确认业务影响。
3. 环境准备与前置条件
这几个命令在绝大多数 Linux 发行版中都预装了，不需要复杂环境。你只需要：
- 一台 Linux 服务器或本地虚拟机，主流的 CentOS 7/8、Ubuntu 20.04/22.04、Debian 均适用。
- SSH 登录权限，普通用户即可查看大部分信息；如果要用
top调整进程优先级或 kill 进程，需要 root 或对应权限。 - 如果是最小化安装的系统，某些命令可能缺失，需要安装
procps或util-linux工具包。
检查命令是否存在：
command -v lscpu command -v top command -v free command -v df command -v w如果某个命令提示 not found，按发行版安装。CentOS/RHEL 系列：
sudo yum install -y procps-ng util-linuxUbuntu/Debian 系列：
sudo apt update sudo apt install -y procps util-linux这些工具本身依赖很少，安装后即可使用。接下来逐个看命令的详细输出和参数。
4. 命令使用详解
4.1lscpu查看 CPU 架构与核心信息
lscpu会汇总/proc/cpuinfo和 sysfs 中的 CPU 信息，输出格式对终端阅读有优化。执行后典型的输出如下：
Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian Address sizes: 46 bits physical, 48 bits virtual 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-7700 CPU @ 3.60GHz Stepping: 9 CPU MHz: 3600.000 CPU max MHz: 4200.000 CPU min MHz: 800.000 BogoMIPS: 7200.00 Virtualization: VT-x L1d cache: 128 KiB L1i cache: 128 KiB L2 cache: 1 MiB L3 cache: 8 MiB NUMA node0 CPU(s): 0-7在实际排查中，你需要关注这几个字段：
CPU(s)：逻辑 CPU 总数。上面例子是 8，物理机是超线程后的总数。Thread(s) per core：每核线程数，2 表示开启了超线程。Core(s) per socket：每个物理 CPU 的物理核数。Socket(s)：CPU 卡槽数量。Model name：CPU 型号，性能判断的第一依据。Virtualization：是否支持虚拟化，搭建虚拟机时看这个。
计算逻辑核数的方法是Thread(s) per core × Core(s) per socket × Socket(s)。如果结果是 8，而CPU(s)也是 8，说明没有逻辑核浪费。如果想只看部分字段，可以用-e输出可扩展视图，一列一列对应：
lscpu -e在脚本中想拿到稳定的机器可读输出，建议用-J输出 JSON：
lscpu -J很多人会碰到一种情况：执行lscpu后找不到Model name，输出里只有Model和Stepping，没有具体型号。这通常发生在某些虚拟化环境或云主机上，宿主机没有把物理 CPU 型号暴露给虚拟机。解决办法是看/proc/cpuinfo：
cat /proc/cpuinfo | grep -m 1 "model name"如果/proc/cpuinfo也没有，就是虚拟化层故意屏蔽了，不必纠结，用CPU(s)和缓存大小也能判断规格。
4.2w查看系统负载与用户活动
w的功能比uptime更多，第一行会显示当前时间、系统运行时长、在线用户数，以及最重要的load average三项值：
10:22:31 up 18 days, 3:11, 2 users, load average: 0.08, 0.03, 0.01 USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT root pts/0 192.168.1.10 10:20 1.00s 0.04s 0.02s w deploy pts/1 192.168.1.11 09:30 52:00 0.11s 0.05s tail -f app.logload average后面的三个数字分别代表过去 1 分钟、5 分钟、15 分钟的系统负载平均值。这个值不是 CPU 使用率，而是处于可运行状态和不可中断状态（通常是等待磁盘/网络 IO）的平均进程数。判断负载是否异常，要结合lscpu看到的逻辑核数：
- 负载长期低于核数：系统整体比较空闲。
- 负载接近或等于核数：CPU 资源已被充分使用。
- 负载远高于核数（比如 16 核主机负载到 30）：说明排队严重，需要进一步定位。
用户行里的PCPU表示进程累计消耗的 CPU 时间，JCPU表示终端相关所有进程消耗的时间。WHAT显示用户当前正在执行的命令，用来判断是否有测试脚本或慢任务挂在终端上。
只看负载可以用uptime：
uptime但w的优势在于同时输出用户和任务，排查现场时更省事。脚本采集时通常只需要第一行，可以提取：
w | head -14.3top动态查看进程负载
top是排查 CPU 和内存问题最常用的工具。启动后是一个实时刷新页面，默认按 CPU 使用率从高到低排序。最上面 5 行是系统总览，下面是进程列表。
第一行和w类似，包含负载均值。第二行是任务统计：
Tasks: 203 total, 1 running, 202 sleeping, 0 stopped, 0 zombie第三行是 CPU 统计：
%Cpu(s): 5.2 us, 2.1 sy, 0.0 ni, 91.7 id, 0.5 wa, 0.3 hi, 0.2 si, 0.0 st各列含义：
us：用户态 CPU 占用。sy：内核态 CPU 占用。id：空闲率。wa：等待 IO 完成的比例，这个值高说明磁盘或网络 IO 可能是瓶颈。st：被虚拟化层偷走的时间，云主机常见，太高说明宿主机资源争抢严重。
第四行和第五行是内存和 Swap 信息，基本对应free命令的输出。
进程列表里默认展示 PID、USER、PR、NI、VIRT、RES、SHR、S、%CPU、%MEM、TIME+、COMMAND。排查时重点看：
%CPU：单核占用比例，超过 100% 说明使用了多核。%MEM：物理内存占用比例。RES：常驻物理内存，进程真实占用的内存。TIME+：累计 CPU 时间，可以判断进程是否长时间吃 CPU。
交互键非常有用。按1可以显示每个逻辑核的使用率；按大写P按 CPU 排序；按大写M按内存排序；按c显示进程完整命令行；按k输入 PID 可以杀进程；按r可以调整优先级。这些都是排查现场的高频操作：
# 启动 top top # 按数字键 1：查看每个 CPU 核心 # 按大写 P：按 CPU 使用率排序 # 按大写 M：按内存使用率排序 # 按 c：显示完整命令行 # 按 q：退出在自动化脚本里不能进入交互界面，要用批处理模式：
# 只采集一次快照 top -b -n 1 # 只看指定进程 top -b -n 1 -p 12345 # 按内存占用排序输出 top -b -n 1 -o %MEM-b表示批处理，-n 1表示只输出一次，避免脚本一直刷新。-o指定排序列，支持%CPU和%MEM等。这些参数比在交互界面里慢慢按要适合采集场景。
4.4free查看内存使用
内存问题用free看，最常用的参数是-h，以人类可读的单位显示：
total used free shared buff/cache available Mem: 31Gi 9.8Gi 1.1Gi 150Mi 20Gi 20Gi Swap: 8.0Gi 0B 8.0Gi很多人第一次看到会误判：used 很大，free 很小，是不是内存紧张？其实不是。Linux 会尽量把内存用作缓存（buff/cache），空闲时用于缓存文件数据，当应用需要时再让出来。所以最该看的是available，它表示不需要交换就能分配给新进程的内存估算值。
字段说明：
total：物理内存总量。used：已使用的物理内存，包含页缓存和内核数据结构的一部分。free：完全空闲的内存，很小不表示内存不足。shared：多个进程共享的内存。buff/cache：用作块设备缓存和文件缓存的内存，业务压力大时可以被回收。available：当前真正可用的内存，是评估内存压力的关键指标。
常用参数：
# 人类可读输出 free -h # 以 MB 为单位 free -m # 每 3 秒刷新一次，观察内存变化 free -s 3 # 同时显示总览行 free -t如果available长期偏低，或者 Swap 的used快速增长，就说明内存可能吃紧。进一步定位是哪个进程占用的，用：
top -b -n 1 -o %MEM | head -20用head截断输出，只保留内存占用最高的前 15 行左右。注意观察 Swap 前几行里的进程，这些进程也值得关注。生产环境不要轻易执行echo 3 > /proc/sys/vm/drop_caches去手动释放缓存，通常没必要，而且可能引起性能抖动。
4.5df查看磁盘空间
磁盘空间问题用df，日常用法是加-h或-Th：
df -hFilesystem Size Used Avail Use% Mounted on /dev/vda1 40G 22G 17G 58% / tmpfs 3.9G 0 3.9G 0% /dev/shm /dev/vdb1 200G 190G 1.5G 100% /data-T会显示文件系统类型：
df -Th排查“磁盘满”时，只确认空间够不够还不行，还要看 inode。文件很多时空间没用完，但 inode 会先满了：
df -iFilesystem Inodes IUsed IFree IUse% Mounted on /dev/vda1 2621440 2600000 21440 100% /如果df -i显示 100%，但df -h还有剩余空间，说明是“小文件过多”导致 inode 耗尽。这时候继续用df -h判断空间没有意义，要去找哪个目录堆积了大量小文件，然后清理。
还有一种常见情况：df -h显示还有空间，但写入文件时报No space left on device。可能是 inode 满了，也可能是某个被删除的文件还被进程占用。后者用下面命令查：
lsof | grep deleted判断哪些文件被删但进程仍然持有句柄，确认后重启对应进程或 kill 进程才能释放空间。
df也支持按指定路径查看：
df -h /data这条命令只看某个目录所在的文件系统，适合挂在云盘、数据盘较多的服务器。
5. 组合使用与性能排查示例
单个命令信息有限，组合起来才是完整排查链路。下面以“用户反馈服务变慢”为例，给出一套适合现场执行的排查流程。
第一步，看系统负载和在线用户：
w如果load average的 1 分钟值明显高于 15 分钟值，说明负载是最近才涨起来的，多半是突发的进程或请求。然后看用户列表里有没有人正在跑压测或 tail 日志。
第二步，看 CPU 使用率和进程排名：
top -b -n 1 | head -20重点关注%Cpu(s)里的us、sy、wa、st。wa高则先去查磁盘 IO，st高则考虑云主机资源争抢，us高则继续往下看进程列表，定位%CPU最高的进程。
第三步，看内存是否吃紧：
free -h如果available已经很低，Swap也在持续增长，说明内存不足。再回到top按内存排序：
top -b -n 1 -o %MEM | head -20第四步，看磁盘是否满：
df -h df -i这两条命令一起执行，先排除空间耗尽，再排除 inode 耗尽。
最后汇总判断：
- 如果
load average高、%CPU高、某个业务进程%CPU也很高，说明 CPU 型负载。 - 如果
load average高、%CPU不高、wa很高，说明 IO 型负载，需要进一步看磁盘iostat或网络。 - 如果
available内存很低，同时有进程%MEM很高，优先考虑内存型问题。 - 如果
df显示 100%，则清理磁盘或扩容是最直接的动作。
这套流程不用安装额外工具，能覆盖大多数性能问题的第一轮判断。后续如需深挖，再上pidstat、iostat、strace或监控平台。
6. 自动化采集与批量监控
这五个命令本身不提供业务 API，但完全可以用 Shell 脚本做定时采集，把结果输出成可供监控系统或 Log 平台读取的格式。下面是一个简单的采集脚本，按固定分隔符输出：
#!/bin/bash # 采集 CPU 核数、负载、内存、磁盘信息，输出为 key=value 格式 LOG_TIME=$(date '+%Y-%m-%d %H:%M:%S') CPU_CORES=$(nproc) LOAD_1=$(uptime | awk -F'load average:' '{print $2}' | awk -F',' '{print $1}') MEM_TOTAL=$(free -m | awk '/^Mem:/{print $2}') MEM_AVAIL=$(free -m | awk '/^Mem:/{print $7}') DISK_USED=$(df -h / | awk 'NR==2{print $5}') echo "time=$LOG_TIME" echo "cpu_cores=$CPU_CORES" echo "load_1min=$LOAD_1" echo "mem_total_mb=$MEM_TOTAL" echo "mem_avail_mb=$MEM_AVAIL" echo "disk_used_percent=$DISK_USED"如果你需要进程层数据，可以用top批处理模式：
top -b -n 1 | sed -n '1,6p'再把结果追加到采集日志：
top -b -n 1 >> /var/log/top_snapshot.log要注意的是，top -b -n 1输出内容较多，如果定时任务很频繁，日志会增长很快。建议只保留必要行，或者先用head截取。Cron 定时执行示例：
*/1 * * * * /opt/scripts/collect_perf.sh >> /var/log/perf_collect.log 2>&1这类脚本适合放在小型服务器或临时排查场景，不能替代专业监控。生产环境建议优先使用 Node Exporter、Telegraf 等采集器，它们对/proc的读取更规范，也自带指标存储和告警。
7. 资源占用与性能观察
这几个命令自身非常轻量，对系统性能影响可以忽略。但要注意几个细节：
top交互模式是动态刷新，默认每 3 秒刷新一次，常驻交互界面会占用一定 CPU，不过很低。批量模式top -b -n 1只执行一次，适合脚本。lscpu会读取 sysfs 和/proc/cpuinfo，在核数很多的服务器上输出多行，但执行时间通常在毫秒级。free和df也是直接读系统接口，成本很低。
排查性能时，我们更关心的是命令输出反映出来的资源变化。可以利用watch自动刷新，比如每 2 秒看一次内存：
watch -n 2 free -h看负载变化：
watch -n 2 uptime在压力测试场景下，建议同时开两个终端，一个跑top，一个依次执行free -s 5和df -i。观察维度的变化趋势比看单次值更有价值。比如available从 10G 掉到 500M，但buff/cache在同步增长，说明文件缓存被大量使用；如果Swap used也在涨，就有内存压力。
另外要注意：命令输出的值永远是瞬时快照。top第一行是自启动到当前的聚合数据，不是实时值，所以长时间观察时要记录多个采样点，判断趋势。不要在 CPU 占用率刚升高 2 秒后就下结论，多采几次再定位。
8. 常见问题与排查方法
| 问题现象 | 可能原因 | 排查方式 | 解决方案 |
|---|---|---|---|
lscpu不显示 CPU 型号 | 虚拟化层未透传型号，或内核参数隐藏 | cat /proc/cpuinfo | grep model name | 型号信息确实拿不到时，以核数和主频为准 |
top里wa很高，但进程%CPU不高 | 磁盘 IO 或网络 IO 阻塞，进程在等待 IO | iostat -x 1、iotop | 确认是哪个磁盘，评估是否扩容或优化读写逻辑 |
free -h显示 used 很高，free 很小 | Linux 缓存策略，buff/cache 占了内存 | 看 available，不要只看 free | 正常现象，只要 available 充足就不必回收缓存 |
df -h有空间，但写入报 No space left | inode 耗尽，或已删除文件被进程占用 | df -i、lsof | grep deleted | 清理小文件，或重启占用删除文件句柄的进程 |
| 负载很高，但 CPU 使用率很低 | 大量 D 状态进程，通常是内核 IO 等待 | top看wa，或抓取 D 状态进程 | 定位具体 IO 路径，检查磁盘健康或网络存储 |
top命令找不到 | 最小化安装缺少 procps 包 | command -v top、yum provides top | 安装 procps-ng 或 procps 包 |
free输出单位看不懂 | 默认以字节显示 | 使用free -h | 用人类可读单位查看 |
lscpu在脚本中解析费力 | 人类可读输出不适合程序处理 | lscpu -J或解析/proc/cpuinfo | 脚本里使用 JSON 输出或直接读/proc |
w没有显示用户任务 | 用户可能登录很久，或 WHAT 被截断 | 检查w输出宽度 | 扩大终端宽度，或用w -u过滤用户 |
9. 最佳实践与使用建议
先花十分钟把正常状态下的基线记录保存下来。比如新机器刚上线时，把lscpu的核数、free -h的总内存、df -h的磁盘使用率都记录下来，后面出现告警时可以直接对比，判断是业务增长还是异常故障。
日常操作建议按“先整体后局部”的顺序执行。先用w看负载，再用top看进程，用free看内存，用df和df -i看磁盘。每一步都只关注关键字段，不要把输出从头到尾背下来。判断内存一定要看available，而不是free。判断磁盘一定要df -h和df -i一起看，两者缺一不可。
脚本里解析命令输出时，优先使用稳定的命令参数。比如free -m可以按 MB 输出，df -h适合人看但不适合程序切割，可以考虑df / --output=source,size,used,avail,pcent -B G这类可预测输出格式。不同发行版对参数支持有差异，建议先在本机man df确认。
批量管理服务器时，把这五个命令封装成一个小脚本，通过 SSH 批量分发执行，可以快速摸清一批机器的资源情况。但要注意：不要通过定时任务高频执行top交互模式，也不要删除系统自带工具。排查完成后，保持系统环境干净，能降低后续出问题的概率。
另外，使用top时要养成先看进程归属和完整命令行的习惯，再决定是否 kill。某些进程名看起来可疑，但可能是宿主机的内核线程或系统组件，贸然操作会造成服务中断。生产环境所有动手类操作都要有确认环节，最好先记录现场快照，再执行变更。
10. 总结与下一步
lscpu、w、top、free、df这五个命令覆盖了 CPU 规格、系统负载、进程资源、内存和磁盘空间五个核心维度。对运维和开发来说，它们是服务器排查的第一梯队工具，学起来成本低，使用频率高，组合起来能解决日常大部分初步定位问题。
建议先在自己机器上跑一遍，不要求记住所有参数，但要记住排查顺序：负载异常看w，进程定位用top，内存压力看free -h，磁盘报错查df -h和df -i。遇到不认识的字段，第一时间用man查手册，比网上零散搜索更可靠。
下一阶段可以继续学习iostat看磁盘 IO、pidstat看单进程上下文切换、vmstat看系统整体统计，再配合 Prometheus 做长期趋势监控。基础命令用熟了，后面接触更深入的工具会轻松很多。
