Linux 服务器日常运维里最绕不开的就是查看“系统现在到底什么状态”CPU 够不够用、内存还剩多少、磁盘会不会满、负载是不是异常。很多刚接触 Linux 的同学习惯性地打开面板或者装一堆监控工具其实系统自带的lscpu、w、top、free、df这几个命令已经完全够用了关键是你会不会读它们的输出。这篇文章会把 5 个命令逐个拆开讲清楚每个字段的含义、常用参数、适合什么场景最后给出一套可以直接上手的组合巡检脚本。不需要装额外软件几乎所有 Linux 发行版都自带这些命令普通用户权限就能执行大部分查询。读完这篇文章你至少能快速回答这几个问题机器有几个核、负载高不高、内存是被谁吃掉的、磁盘还有多少空间、有没有进程在偷偷跑满 CPU。1. 核心能力速览命令功能定位输出核心内容常用参数适用场景lscpu查看 CPU 硬件架构信息CPU 型号、架构、核数、线程数、主频、虚拟化支持-e扩展可读列表首次登录服务器确认机器规格w查看系统负载与当前登录会话当前时间、开机时长、登录用户数、1/5/15 分钟负载每个用户执行的命令无特别常用参数登录后第一件事快速判断系统繁忙程度top动态查看进程级资源占用CPU 使用率、内存使用、每个进程的 CPU/内存占用-b、-n、-p、-o排查哪个进程占 CPU、内存过高观察僵尸进程free查看物理内存与 Swap 用量总内存、已用、空闲、缓存、可用内存-h、-m、-s、-g判断内存是否充足排查内存不足问题df查看磁盘空间与文件系统使用分区大小、已用、可用、挂载点、文件系统类型-h、-T、-i排查磁盘写满、inode 耗尽问题这 5 个命令共同覆盖了 CPU、内存、磁盘、负载四个维度是 Linux 系统体检的最小命令集。2. 适用场景与使用边界这套命令适合以下场景服务器首次上线巡检查看机器实际分配的 CPU 核数、内存大小、磁盘挂载情况确认和采购单是否一致。日常登机检查SSH 登录后先敲w看负载再free -h和df -h30 秒内完成一次健康检查。故障响应应用响应慢、接口超时、任务卡住时用top定位是 CPU 打满还是内存不足用df -h排除磁盘写满。容量规划定期采集free和df的输出观察内存和磁盘增长趋势提前扩容。边界也要说清楚。这些命令展示的是单机当前状态或短时统计值不涉及历史趋势和集群视角。跨多台机器巡检需要配合 Ansible、脚本批量执行或者接入 Prometheus、Node Exporter 这类监控系统。权限方面普通用户能执行大部分查询类命令。不过top内部发送信号杀进程、修改进程优先级等操作需要相应权限。所有命令都应在你有权管理的服务器上执行遵循企业安全规范不要在未授权的主机上做资源探测和故障处理。信息查询本身没有副作用但基于查询结果做出的运维动作需要谨慎复核。3. 环境准备与基础概念这套命令几乎没有环境门槛。主流发行版默认自带CentOS / Rocky / Alibaba Cloud Linuxlscpu来自util-linuxfree、top来自procps-ngdf来自coreutils。Ubuntu / Debian同样自带这些命令。最简环境只要有一个能 SSH 登录的 Linux 终端即可不需要图形界面不需要额外安装包。如果极少数精简镜像里确实缺少命令可用系统包管理器安装# CentOS / Rocky / Alibaba Cloud Linux yum install -y util-linux procps-ng coreutils # Ubuntu / Debian apt update apt install -y util-linux procps-ng coreutils开始之前先明确几个基础概念后面读输出字段会顺畅很多负载Load Average不是 CPU 使用率。它表示系统中处于可运行状态和不可中断睡眠状态的进程平均数量。单核 CPU 负载长期超过 1.0 说明 CPU 可能不够用但多核机器允许更高的负载值判断时要用核数做分母。逻辑 CPU 数物理核数 × 每核线程数。top里看到单进程 CPU 超过 100%就是因为程序在用多线程并行。available 内存在没有触发额外 swap 的前提下新进程实际可以申请到的内存量。它包含了可回收的缓存比 free 字段更有参考价值。inode文件系统存储文件元数据文件名、权限、大小、位置的索引节点。inode 用尽时即使磁盘还有空间也创建不了新文件所以df -i是常规磁盘检查之外必须补的一项。4. lscpu查看 CPU 架构与硬件规格lscpu是查看 CPU 信息最直观的命令它从/proc/cpuinfo、sysfs设备树等系统中汇总信息一次性输出人类可读的结果。执行lscpu输出核心字段的含义字段含义判断依据ArchitectureCPU 架构x86_64 是常见的 64 位 x86 架构aarch64 是 ARM 架构CPU(s)逻辑 CPU 总数等于 Socket × Core × ThreadModel nameCPU 型号名称判断服务器代际和生产商Thread(s) per core每核线程数2 表示开启了超线程Core(s) per socket每颗 CPU 的物理核数和 Socket 相乘得到物理核总数Socket(s)CPU 插槽数 / 物理颗数多路服务器会出现大于 1CPU max MHzCPU 最高运行频率注意实际频率受功耗和负载影响Virtualization虚拟化支持类型常见输出有 VT-x、AMD-VNUMA node(s)NUMA 节点数多路服务器性能调优时需要注意实际执行输出类似$ lscpu Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian Address sizes: 48 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: 142 Model name: Intel(R) Core(TM) i7-8565U CPU 1.80GHz Stepping: 10 CPU MHz: 1992.000 CPU max MHz: 4600.0000 CPU min MHz: 400.0000 Virtualization: VT-xCPU(s): 8表示逻辑 CPU 总数为 8也就是top中%Cpu(s)各状态百分比相加的基础。Thread(s) per core: 2表示开了超线程物理核实际上只有 4 个。如果只需要关键信息可以用grep过滤lscpu | grep -E ^(Architecture|CPU\(s\)|Model name|Socket|Core|Thread|Virtualization)需要强调一点lscpu显示的 CPU 主频是当前或额定状态的参考值CPU 实际频率会随负载和温度动态变化。判断 CPU 是否跑满要看top中的us和id指标而不是只看主频数字。有些场景下lscpu不展示型号输出里只有Architecture和CPU(s)等基础字段。这通常出现在云服务器或容器环境里宿主机屏蔽了部分 CPU 信息属于正常现象。此时可以尝试用cat /proc/cpuinfo | grep model name | head -1或者dmidecode -t processor需要 root 权限补充查看。5. w系统负载与当前登录会话w是一个经常被低估的命令。它一条命令同时给出了负载、登录用户、每个会话正在执行的命令信息量非常大。执行w输出分两部分。第一行是系统概要12:34:56 up 30 days, 4:12, 3 users, load average: 0.08, 0.03, 0.0112:34:56当前系统时间。up 30 days, 4:12系统已开机运行 30 天 4 小时 12 分。3 users当前登录会话数。load average: 0.08, 0.03, 0.011 分钟、5 分钟、15 分钟的平均负载。三个数都低说明系统很空闲如果 1 分钟明显高于 15 分钟说明负载正在上升。第二行是每个登录会话的明细USER TTY FROM LOGIN IDLE JCPU PCPU WHAT root pts/0 192.168.1.10 12:30 2.00s 0.05s 0.05s w root pts/1 192.168.1.20 11:20 1:04m 0.10s 0.02s topUSER登录用户。TTY终端类型pts/0表示远程 SSH 伪终端。FROM来源 IP本地登录显示-。LOGIN登录时间。IDLE会话空闲时间。JCPU该终端所有进程累计占用的 CPU 时间。PCPU当前前台进程占用的 CPU 时间。WHAT当前正在执行的命令。w的核心用法是快速判断负载到底是谁带来的。如果 load average 很高看WHAT列通常会直接看到top、python、java、nginx这类进程名。再用top进一步确认具体的进程 PID。w和uptime的区别在于uptime只输出第一行负载概要w额外输出所有用户会话。和who的区别是who只列出登录用户不显示负载和正在执行的命令。三选一的时候直接w信息量最大。6. top动态查看进程级资源占用top是排查 CPU 和内存问题的核心命令它实时刷新默认按 CPU 使用率排序。执行top前 5 行是系统概要top - 12:35:01 up 30 days, 4:13, 3 users, load average: 0.08, 0.03, 0.01 Tasks: 123 total, 1 running, 122 sleeping, 0 stopped, 0 zombie %Cpu(s): 2.0 us, 0.5 sy, 0.0 ni, 97.0 id, 0.5 wa, 0.0 hi, 0.0 si, 0.0 st MiB Mem : 7977.7 total, 1024.5 free, 2034.2 used, 4919.0 buff/cache MiB Swap: 2048.0 total, 2048.0 free, 0.0 used. 5473.2 avail Mem逐行解释行内容关键解读第 1 行当前时间、开机时长、用户数、负载与w第一行一致第 2 行进程汇总总数、运行中、睡眠、停止、僵尸zombie不为 0 时需要关注第 3 行CPU 状态百分比us用户态占用、sy内核态占用、id空闲、waIO 等待、st被虚拟机管理程序抢占第 4 行物理内存总量、空闲、已用、缓存重点看buff/cache是否占用过高第 5 行Swap 用量 实际可用内存avail Mem是真正能申请到的内存第 3 行里的 CPU 百分比最容易误读。正常情况下id应该很高比如 97% 说明 CPU 很空闲。如果us高说明用户态进程在密集运算sy高说明系统调用频繁可能是网络或磁盘 IO 引发wa高说明磁盘或网络 IO 成为瓶颈st高说明宿主机 CPU 超卖严重云服务器常见。进程列表部分默认关心的字段字段含义PID进程 IDUSER运行用户PR优先级NInice 值影响调度优先级VIRT虚拟内存总量RES常驻物理内存SHR共享内存S进程状态R 运行、S 睡眠、D 不可中断、Z 僵尸%CPUCPU 使用率多核下可以超过 100%%MEM物理内存占用百分比TIME累计 CPU 时间COMMAND命令名称top是交互式命令支持快捷键操作快捷键作用P按 CPU 使用率排序默认M按内存占用排序N按 PID 排序k发送信号给进程可输入 PID 后选择信号默认 SIGTERMq退出1展开或折叠每个 CPU 核心的独立使用率c显示完整命令行f进入字段管理界面勾选需要显示的列top默认是动态刷新不适合直接放进脚本采集。需要一次性输出时使用批处理模式top -b -n 1 | head -30-b表示批处理模式-n 1表示只输出一帧。结合grep和awk可以筛选关键进程top -b -n 1 | grep -E PID|java|python|nginx查看指定 PID 的资源占用top -b -n 1 -p 1234,5678使用top排查问题的基本思路是先看Tasks行有没有 zombie再看%Cpu(s)的us、sy、wa、st谁高最后按P或M排序定位到具体进程结合COMMAND列判断是什么业务。7. free查看内存与 Swap 使用情况free输出内存使用情况是排查内存问题最直接的命令。推荐直接带-h参数以人类可读的单位显示free -h新版输出示例total used free shared buff/cache available Mem: 7.8Gi 2.0Gi 1.0Gi 12Mi 4.8Gi 5.3Gi Swap: 2.0Gi 0B 2.0Gi各字段含义字段含义注意事项total物理内存总量与lscpu看到的机器规格直接对应used已使用的内存包含不可回收的系统内核占用free完全空闲的内存这个值不是判断内存不足的唯一依据sharedtmpfs 等共享内存占用量多进程共享的内存页buff/cache缓冲区 页缓存可被内核回收并不是“被占死”available新进程实际可用的内存最重要的参考值很多新手看到free很小、buff/cache很大就开始担心内存泄漏其实这是对 Linux 内存管理机制的误解。Linux 会把空闲内存用作页缓存加速文件读写当应用需要内存时内核会自动回收这些缓存。所以判断内存是否充足应该看available而不是free。如果available很低同时 Swap 一直在增长说明内存真的不够用了。可以用free -s 3每隔 3 秒刷新一次观察变化趋势free -h -s 3按不同单位输出free -m # 以 MiB 为单位 free -g # 以 GiB 为单位适合查看大内存机器查看内存占用最高的进程还是用toptop -b -n 1 | head -20内存不足典型表现应用进程被 OOM Killer 杀掉、系统开始大量使用 swap、dmesg里出现Out of memory日志。遇到这类问题先free -h确认现状再用top按M找到内存大户最后结合业务判断是扩容还是优化进程配置。这里不建议在业务服务器上随手执行echo 3 /proc/sys/vm/drop_caches来强制清理缓存。虽然能临时让free变大但会降低缓存命中率反而影响文件读写性能属于“拆东墙补西墙”的操作生产环境务必慎用。8. df查看磁盘空间与文件系统使用情况df用于查看文件系统磁盘空间占用。推荐组合参数-hT既显示文件系统类型又用人类可读单位df -hT输出示例Filesystem Type Size Used Avail Use% Mounted on /dev/vda1 ext4 40G 20G 18G 53% / tmpfs tmpfs 3.9G 0 3.9G 0% /dev/shm /dev/vdb1 xfs 100G 80G 20G 80% /data关键字段字段含义判断标准Filesystem设备或挂载来源/dev/vda1是云盘设备名tmpfs是内存文件系统Type文件系统类型ext4、xfs、tmpfs、overlay 等Size分区总容量Used已用容量Avail可用容量Use%使用率常规建议 80% 以下核心业务磁盘建议 70% 以下Mounted on挂载点判断磁盘对应哪个业务目录只查询某个目录所属的文件系统df -hT /datadf -h只显示空间信息不带文件系统类型需要确认文件系统格式时用-T。一般来说df -hT组合最省事。磁盘问题还有一个容易被忽略的维度inode 耗尽。inode 是文件系统索引节点每个文件或目录占用一个。文件很多但都很小比如邮件队列、日志碎片时可能出现磁盘空间还有余量、但 inode 已经耗尽的情况此时无法创建新文件。用df -i检查df -i输出示例Filesystem Inodes IUsed IFree IUse% Mounted on /dev/vda1 2560000 131278 2428722 6% /IUse%达到 100% 时即使df -h显示还有几十 GB 空闲应用依然会报No space left on device。处理方式通常是清理大量碎片小文件比如旧的日志、临时目录里残留的 session 文件。还有一种常见情况df -h显示磁盘满了但du -sh /逐目录排查后找不到特别大的文件。原因往往是某个文件被删除但进程还持有该文件句柄空间没有真正释放。排查方法# 查看被删除但仍在被进程占用的文件 lsof L1确认之后再决定是否重启对应进程或服务让内核完成空间回收。9. 组合实战一次完整的系统快速巡检单条命令各有用处但实际运维中更高效的是组合使用。下面是一套常用的巡检命令适合刚登录服务器时执行echo 系统时间与负载 uptime echo CPU 硬件与逻辑核数 lscpu | grep -E ^(Architecture|CPU\(s\)|Model name|Socket|Core|Thread|Virtualization) echo 内存使用情况 free -h echo 磁盘使用情况 df -hT echo inode 使用情况 df -i echo 当前登录用户与进程 w也可以写成更紧凑的单行uptime free -h df -hT w巡检后的判断逻辑可以按下面的规则快速过一遍负载是否异常load average三个值里1 分钟值明显高于 15 分钟值说明负载正在上升将 15 分钟负载值除以逻辑 CPU 数结果长期大于 1说明 CPU 可能不够用。CPU 是否打满top的%Cpu(s)里id长期小于 30%说明 CPU 繁忙wa高说明磁盘 IO 在拖后腿。内存是否足够看free -h的available字段而不是free字段。available 长期低于总内存的 20%需要关注。磁盘是否告急df -hT中Use%超过 80% 的分区要重点关注超过 90% 需要立即清理同时用df -i确认 inode 没有耗尽。有没有僵尸进程top的Tasks行里zombie数量不为 0 且持续增长说明有进程没有正确回收子进程需要定位父进程排查。这套流程不依赖任何监控平台SSH 登录后敲一遍几十秒内就能掌握服务器的基本健康状态。如果需要周期性采集可以把命令追加到crontab中输出重定向到日志文件*/5 * * * * /bin/bash /opt/scripts/sys_check.sh /var/log/sys_check.log 2110. 常见问题与排查方法问题现象可能原因排查方式解决方案load average 很高但 CPU 空闲率也很高大量 IO 等待进程阻塞在磁盘或网络 IOtop看wa指标vmstat 1看wa和si/so定位 IO 密集型进程考虑换 SSD、调整读写频率free显示可用内存很少业务运行正常buff/cache占用较高内核缓存被复用重点看available字段而非free字段无需处理内核会在需要时自动回收缓存磁盘空间满了但du找不到大文件文件被删除后进程仍持有句柄或日志被周期性截断写入使用lsof L1查看被删除但未释放的文件重启持有句柄的进程清理后重新检查df -h磁盘有空间但应用报No space left on deviceinode 已耗尽使用df -i查看 inode 使用率清理大量碎小文件或重建文件系统top中单个进程%CPU超过 100%多核并行百分比是按逻辑核数累加的使用lscpu查看逻辑 CPU 数正常现象结合nproc判断是否到瓶颈lscpu不显示 CPU 型号云服务器或容器环境屏蔽了部分信息使用cat /proc/cpuinfo或dmidecode -t processor补充确认环境是否允许获取完整硬件信息这 6 类问题是日常运维中出现频率最高的。掌握判断方法之后大部分资源类故障都能定位到一个相对具体的范围。11. 最佳实践与使用建议基于这几个命令的使用经验整理几条可直接落地的建议。先看整体再看细节。登录服务器之后先w看负载再free -h看内存最后df -hT看磁盘。负载高了再进top定位进程不要一上来就盯着具体 PID 看。给 top 加上批处理采集。top的交互模式适合人肉排查但如果要持续记录建议用top -b -n 1配合脚本定期落盘。也可以在top交互界面按W保存当前配置下次启动自动套用字段布局。记忆常用参数组合。这一组命令的常用参数非常固定建议直接记住lscpu w top -b -n 1 | head -30 free -h df -hT df -i建立基线数据。新机器上线第一天把lscpu、free -h、df -hT的输出保存到文档里。后续出问题时对比基线数据往往能快速发现是配置变化导致的资源变化还是业务增长导致的容量不足。定时巡检代替人工抽查。把第 9 节的巡检脚本放入 crontab每小时或每天执行一次。即使不接入告警系统日志文件也能在事后回溯故障现场。生产环境慎用“清理类型”的操作。比如强制清理 cache、手动杀进程确认清楚影响面再执行。查询命令无害但基于查询结果的处置动作一定要谨慎。涉及权限和合规的操作留痕。在多人共管的服务器上执行需要较高权限的操作时先沟通确认再操作、留日志。禁止在未授权的主机上执行资源探测和批量操作。12. 总结与下一步这 5 个命令是 Linux 系统管理的地基每一个都不复杂但组合起来覆盖了服务器日常巡检的大部分需求lscpu确认硬件规格w快速看负载top定位进程级别的 CPU 和内存占用free判断真实可用内存df排查磁盘空间和 inode。建议你先在任意一台 Linux 机器上逐条执行对照本文的字段解释读一遍输出然后把第 9 节的组合巡检脚本存下来改成自己的服务器巡检工具。第一次使用时就记住重点负载要和 CPU 核数对比内存要看 available磁盘空间要同时看容量和 inode。这几个命令掌握之后下一步可以继续学习vmstat和iostat看更细的 IO 指标用sar看历史趋势用pidstat跟踪具体进程。命令本身不难难的是熟练组合它们定位问题的思路。建议把这篇文章收藏备用下次登录服务器巡检时直接把命令拿出来用。如果遇到输出和本文示例不一致的情况大概率是发行版版本差异用man 命令名查看本机帮助文档即可。