如果你经常登录服务器排查问题肯定被这几个问题折腾过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 nameCPU 型号性能判断的第一依据。Virtualization是否支持虚拟化搭建虚拟机时看这个。计算逻辑核数的方法是Thread(s) per core × Core(s) per socket × Socket(s)。如果结果是 8而CPU(s)也是 8说明没有逻辑核浪费。如果想只看部分字段可以用-e输出可扩展视图一列一列对应lscpu -e在脚本中想拿到稳定的机器可读输出建议用-J输出 JSONlscpu -J很多人会碰到一种情况执行lscpu后找不到Model name输出里只有Model和Stepping没有具体型号。这通常发生在某些虚拟化环境或云主机上宿主机没有把物理 CPU 型号暴露给虚拟机。解决办法是看/proc/cpuinfocat /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显示用户当前正在执行的命令用来判断是否有测试脚本或慢任务挂在终端上。只看负载可以用uptimeuptime但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或-Thdf -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高则先去查磁盘 IOst高则考虑云主机资源争抢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 核数、负载、内存、磁盘信息输出为 keyvalue 格式 LOG_TIME$(date %Y-%m-%d %H:%M:%S) CPU_CORES$(nproc) LOAD_1$(uptime | awk -Fload 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 NR2{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 21这类脚本适合放在小型服务器或临时排查场景不能替代专业监控。生产环境建议优先使用 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 阻塞进程在等待 IOiostat -x 1、iotop确认是哪个磁盘评估是否扩容或优化读写逻辑free -h显示 used 很高free 很小Linux 缓存策略buff/cache 占了内存看 available不要只看 free正常现象只要 available 充足就不必回收缓存df -h有空间但写入报 No space leftinode 耗尽或已删除文件被进程占用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 输出或直接读/procw没有显示用户任务用户可能登录很久或 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 / --outputsource,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 做长期趋势监控。基础命令用熟了后面接触更深入的工具会轻松很多。