系统变慢了第一反应是什么上服务器敲free看内存还有多少跑top看哪个进程在吃 CPU再执行df -h确认磁盘有没有写满。这是很多后端开发同学和运维同学的真实肌肉记忆。问题在于这几个命令每个人都会敲但真正能通过输出内容快速定位问题的却不一定是多数。有些场景下load average已经飙到三位数CPU 占用却很低有些场景下free显示内存几乎耗尽系统却依然流畅还有些场景下df -h显示磁盘还有几十 G但创建文件就是失败。如果只看命令表面很容易被这些现象带偏。这一篇把 Linux 运维排查中最常用的五个命令一次性讲透lscpu、w、top、free、df。它们分别对应 CPU 信息、系统负载、进程资源、内存使用和磁盘容量。弄清楚这些命令的关键字段、常见误区和组合用法你在排查“系统变慢”这个问题时就不需要再靠猜了。1. 这篇文章真正要解决的问题很多人用top看一眼 CPU 占用率再用free看一眼内存觉得“数值没满就是没问题”。但真实的生产环境远比这个复杂。举个例子一台 8 核 16 线程的服务器top里显示的是 16 个逻辑 CPU而不是 8 个物理核。如果你不知道这 16 个数字是怎么来的就很难理解为什么load average到达 16 还不算严重而到达 32 才意味着性能明显恶化。lscpu解决的就是这个认知前提。再举一个例子free里有一项buff/cache在 Linux 的经典内存管理机制下可能会看到几 GB 甚至几十 GB 都被 cache 占用了。很多新手第一反应是“内存不够了”但其实这部分内存是当文件读写缓存用的系统内存吃紧时会被自动回收。如果误判这一点你可能会为了“释放内存”去重启服务反而白白增加一次故障。这篇文章会从概念对比开始把五个命令的主要输出字段、典型应用场景和组合排查思路逐一拆开。读完之后你应该能达到一个状态拿到一台 Linux 服务器能用一条lscpu确认硬件底座用w快速看负载用top定位进程用free分析内存用df检查磁盘空间。如果做到这五步80% 的“服务器响应慢”类问题你都能在第一轮排查中确定方向。2. 负载、CPU、内存、磁盘先分清四个概念在看命令之前必须先用一点点篇幅把四个核心概念厘清。命令输出只是结果概念才是判断依据。2.1 系统负载Load Average与 CPU 占用率load average是 Linux 系统非常关键的指标它表示一段时间内处于可运行状态正在使用 CPU、等待 CPU以及不可中断睡眠状态通常是等待磁盘 I/O、等待网络 I/O的进程平均数量。简单理解就是“平均有多少进程在排队等 CPU 或等 I/O”。CPU 占用率是某一时刻 CPU 忙的时间比例而负载是“队列长度”的度量。两者有关系但不等价如果一个进程在等待磁盘数据CPU 占用率可能不高但负载会持续升高。判断负载是否异常不能只看绝对值要看逻辑 CPU 数量。8 核机器负载 8 意味着刚好满载16 核机器负载 8 说明还有余量。这也是为什么下一节要先讲lscpu。2.2 物理内存、Swap 与 Cache物理内存是真正的 RAMfree命令中总量、已用、可用等字段都来自内核的meminfo。Swap 是把磁盘空间当内存用的一种扩展机制当物理内存不足时不常用的内存页会被交换到磁盘上。buff/cache是缓冲区和高页缓存Linux 会把读写过的磁盘数据放在内存里加速下一次读写。这部分内存看似“用了”但实际上在应用程序需要时可以被回收。所以判断内存到底够不够要用available字段而不是用free字段。2.3 磁盘容量与 inode磁盘容量指的是数据块的总量df -h看的通常是容量。inode 是文件系统管理文件元数据的索引节点每个文件或目录都要消耗一个 inode。容量有剩余但 inode 耗尽同样会提示“No space left on device”这是排查磁盘问题时需要特别注意的坑。2.4 四者关系概念关心的问题对应命令系统负载平均有多少进程在排队w、top、uptimeCPU核数、架构、使用率lscpu、top内存物理内存、Swap、Cachefree磁盘容量、inode、读写等待df、du、iostat这一组概念是后文所有命令的基础。不要跳过直接看命令否则遇到实际情况容易“读得懂数值定不了故障”。3. 环境准备与命令帮助信息的获取这五个命令不需要额外安装属于 Linux 基础工具集。lscpu来自util-linux包。w来自procps-ng或sysvinit-tools包。top来自procps-ng包。free来自procps-ng包。df来自coreutils包。绝大多数的 CentOS、Ubuntu、Debian、openEuler 等发行版都自带了这些命令。如果你使用的精简 Docker 镜像里缺失了某个命令可以用包管理器安装。# CentOS / RHEL / openEuler yum install -y procps-ng util-linux coreutils # Ubuntu / Debian apt update apt install -y procps util-linux coreutils注意free在不同发行版中包装名不完全一致Debian/Ubuntu 中它位于procps包内CentOS/RHEL 中位于procps-ng包内。如果你对某个命令的字段不确定最常用的两个帮助入口是man free free --helpman页面内容完整适合精读--help输出精简适合速查。本文后面提到的所有字段也建议大家在真实服务器上对照执行一遍输出可能因为发行版版本不同而略有差异但核心字段含义是稳定的。本文示例基于主流 Linux 发行版的默认输出格式不针对特定版本展开。命令的核心逻辑是通用思路。4. lscpu先看清机器到底有几颗 CPU、几个核很多人在排查负载时犯的第一个错误是不知道这台服务器到底有多少逻辑 CPU。4.1 基本用法与输出解读直接执行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关键字段按重要性排序如下字段含义排查中的用途CPU(s)逻辑 CPU 数量判断 load average 是否过高的基准值Thread(s) per core每个物理核的线程数判断是否开启超线程Core(s) per socket每个 CPU 插槽的物理核数判断业务可以占用多少独立执行单元Socket(s)CPU 插槽数量判断是不是多路主板Model nameCPU 型号判断处理器代际和主频范围ArchitectureCPU 架构判断是否 x86_64 / aarch64CPU max MHz最高主频判断是否有睿频空间逻辑 CPU 数量的计算公式是逻辑 CPU 数 Socket(s) × Core(s) per socket × Thread(s) per core比如上面这台机器1 × 4 × 2 8所以这台服务器的load average如果需要压满在纯计算场景下至少要跑到 8 以上才算“满载”。如果是 8 逻辑核的机器load 常年处于 16那就说明排队翻倍了需要进一步看top定位是哪些进程在抢资源。4.2 快速获取逻辑 CPU 数量的三种方式如果不想看完整lscpu输出可以直接用命令行提取# 方式一直接从 lscpu 提取 lscpu | grep -E ^CPU\(s\): | awk {print $2} # 方式二查看 /proc/cpuinfo 中 processor 个数 grep -c ^processor /proc/cpuinfo # 方式三使用 nproc nprocnproc会输出当前进程可用的 CPU 数量在容器环境下尤其有用。因为容器的 CPU 配额可能会被限制lscpu看到的可能是宿主机的总体规格而nproc看到的可能是容器内实际可用的配额。这个区别对排查线上容器负载很有意义。4.3 常见误区lscpu 不显示型号有些云服务器或精简版系统上执行lscpu输出里没有Model name字段或者显示为Model name: N/A。这是因为某些虚拟化环境或内核启动参数没有完整透传 CPU 型号信息。遇到这种情况可以尝试cat /proc/cpuinfo | grep -m 1 model name如果/proc/cpuinfo也没有说明宿主机把 CPU 信息隐藏了这不会影响功能但会影响你对主频和代际的判断。遇到这类现象不必惊慌不代表机器有问题只需要换用cat /proc/cpuinfo核对即可。4.4 lscpu 在排查中的实际价值判断负载是否异常的“基数”是多少。判断是否需要多路应用进程数量按 CPU 核数设置。确认是物理机还是虚拟机架构。排查编程语言运行时或数据库线程池配置时作为核心参数依据。5. w系统负载和当前登录状态的第一眼信息w命令适合在登录服务器后第一时间执行。它会在一条命令内同时展示当前时间、开机时长、登录用户数量、系统负载、每个登录用户的活动情况和终端占用。5.1 基本用法w第一次执行时输出大概长这样14:22:30 up 3 days, 2:18, 2 users, load average: 0.08, 0.12, 0.15 USER TTY FROM LOGIN IDLE JCPU PCPU WHAT root pts/0 192.168.1.10 13:50 0.00s 0.05s 0.05s -bash ubuntu pts/1 192.168.1.23 12:10 5:30 0.10s 0.02s vim nginx.conf5.2 第一行信息解析第一行的load average: 0.08, 0.12, 0.15是整条命令的重点。三个数字分别代表过去 1 分钟、5 分钟、15 分钟的平均负载。数字越高说明系统在过去这段时间内排队执行的进程越多。up 3 days, 2:18表示系统已连续运行 3 天 2 小时 18 分钟。这个信息对排查“是不是有人重启过服务器”或“服务器是否因负载过高自动重启过”很有帮助。2 users表示当前有 2 个登录会话。这个信息对排查多人操作同一台服务器的场景非常实用。5.3 load average 应该怎么判断判断负载是否异常的常用参考标准如下逻辑 CPU 数负载参考值判断80~8正常可继续观察88~16偏高需要定位进程816严重可能已经影响业务这里的逻辑是负载值等于逻辑 CPU 数时系统刚好能把所有 CPU 队列排满超过这个值就意味着多出来的进程在等待。但需要注意负载高不一定代表 CPU 忙也可能是因为大量进程在等待磁盘 I/O。所以只看w不能下结论下一步必须用top辅助确认。uptime命令的输出比w更精简只包含第一行uptime14:22:30 up 3 days, 2:18, 2 users, load average: 0.08, 0.12, 0.15如果想在脚本里快速获取负载可以读/proc/loadavgcat /proc/loadavg输出0.08 0.12 0.15 1/345 12345其中前三位是 1、5、15 分钟负载第四个字段表示“当前可运行进程数/总进程数”最后一个字段是最近创建的进程 PID。脚本监控时可以直接解析这个文件不需要反复调用w。5.4 w 适合什么时候用登录服务器后想快速了解当前系统整体状态。接受告警时先看一眼负载和在线用户判断是正常流量还是异常有人登录执行了任务。写脚本时用/proc/loadavg做轻量级采集。真正要定位哪个进程消耗了资源w不够必须进入top。6. top实时查看系统负载、CPU、内存和进程状态top是 Linux 排查问题时使用频率最高的命令之一。它每隔几秒刷新一次把系统整体资源和所有进程的资源占用动态展示在终端上是快速定位“谁在偷吃 CPU/内存”的核心工具。6.1 基本执行top进入交互界面后默认按 CPU 使用率从高到低排序。上方是系统概要信息下方是进程列表。top - 14:30:02 up 3:15, 2 users, load average: 1.05, 0.80, 0.60 Tasks: 220 total, 2 running, 218 sleeping, 0 stopped, 0 zombie %Cpu(s): 12.5 us, 6.2 sy, 0.0 ni, 81.2 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st MiB Mem : 7976.0 total, 2500.0 free, 3200.0 used, 2276.0 buff/cache MiB Swap: 2048.0 total, 2048.0 free, 0.0 used. 3700.0 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME COMMAND 1234 root 20 0 600000 45000 8000 S 30.0 0.6 1:23.45 java 2345 root 20 0 300000 20000 6000 S 10.0 0.3 0:34.56 python36.2 前五行概要信息逐一解释第一行和w的第一行完全一样。top - 14:30:02表示当前时间up 3:15表示开机时长load average三个值含义前文已讲过。这个位置的价值在于和进程列表放在同一屏不用来回切换命令。第二行进程状态汇总。total进程总数注意这里统计的是线程数Linux 中线程也以任务为单位。running正在运行状态包括等待 CPU 调度的进程。sleeping休眠状态大多数正常服务都在睡眠中等待事件。stopped被SIGSTOP暂停的进程。zombie僵尸进程子进程已退出但父进程没有调用wait()回收资源。如果zombie数字持续大于 0需要注意父进程是否有 bug但少量僵尸进程一般不直接导致系统不可用。第三行CPU 使用率。%Cpu(s): 12.5 us, 6.2 sy, 0.0 ni, 81.2 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st缩写全称含义ususer用户态 CPU 时间占比sysystem内核态 CPU 时间占比ninice低优先级nice 值调整过进程占用的 CPUididle空闲 CPU 比例waiowait等待 I/O 完成的时间占比hihardware interrupt硬件中断占比sisoftware interrupt软件中断占比ststeal time被虚拟化环境偷走的时间云服务器上常见wa高意味着有进程在等磁盘或网络 I/OCPU 可能只是“被迫空闲”。此时 CPU 不高但系统慢重点应该查磁盘 I/O而top本身只能发现问题进一步定位要借助iostat或iotop。st高则说明宿主机的资源竞争影响了当前虚拟机。第四、五行内存信息。其中total、free、used、buff/cache、avail Mem等含义与free命令一致后文会详细说明。6.3 常用交互命令进入top后按下面这些键可以快速切换视图P 按 CPU 使用率排序默认 M 按内存使用率排序 T 按累计 CPU 时间排序 N 按 PID 排序 k 杀掉指定 PID 的进程会提示输入 PID 和信号 r 重新设置进程 nice 值 d 修改刷新间隔单位秒 q 退出 top如果只想看某个用户启动了哪些进程按u再输入用户名u输入root后进程列表就只显示 root 用户的进程。这个功能在多人共用的服务器上非常有用。6.4 进程列表关键列列名含义PID进程 IDUSER启动进程的用户PR内核调度优先级NInice 值影响优先级高低VIRT虚拟内存大小RES实际驻留物理内存大小SHR共享内存大小S进程状态常见的是 S睡眠、R运行、Z僵尸%CPUCPU 使用率%MEM物理内存占比TIME累计 CPU 时间COMMAND命令名称RES常驻内存比 VIRT虚拟内存更值得关注。一个 Java 进程 VIRT 可能到十几个 G但真正占用物理内存的是 RES。6.5 查看指定进程的线程如果一个进程整体 CPU 不高但它内部某个线程出了问题就需要按线程视角查看top -H -p 12341234替换为实际进程 PID。此模式下进程的每个线程都会显示为一行可以定位是哪一个线程在疯狂占用 CPU。拿到线程号后再结合jstack或其他语言对应的线程转储工具可以进一步分析业务代码。6.6 批量输出到文件top交互模式适合人看不适合脚本采集。如果想抓取一次快照可以这样top -b -n 1-b表示非交互模式-n 1表示只输出一次。输出后可以配合head、grep提取想要的内容也可以直接追加到日志文件top -b -n 1 /var/log/top_$(date %F_%H%M).log在生产环境中这种快照采集适合作为短时间内的现场记录但不建议长期高频运行避免额外增加系统开销。6.7 top 在排查中的典型路径执行w确认负载偏高。执行top进入动态界面按P确认 CPU 排在最前的是哪些进程。如果%CPU很高的是业务进程再按M看内存占用。如果某个进程占满 CPU用top -H -p PID看具体线程。按q退出结合日志和代码继续定位。7. free真正看懂内存使用不要被“占用高”吓到free是查看内存使用情况的核心命令。但很多人在看到free很小、used很大的时候就直接判断“内存不足”这个结论往往是错的。7.1 基本用法free -h-h会以人类友好的单位显示比如GiB、MiB。如果脚本需要按统一单位解析可以用-m强制以 MB 输出free -m实际输出示例total used free shared buff/cache available Mem: 7976 3200 2500 20 2276 3700 Swap: 2048 0 20487.2 字段含义字段含义total物理内存总量used已被使用的内存free完全没有被使用的内存shared各进程共享的内存buff/cache内核缓冲区与页面缓存available可用于启动新应用的内存估算值available是判断内存是否够用的首选字段。它的含义是在不触发明显 swap 的前提下还能分配给新进程的内存大小。buff/cache大并不等于内存不够。Linux 会自动利用空闲内存做文件缓存当应用需要内存时这一部分会被回收。所以used高、free小但available足够大说明系统运行非常健康。7.3 常见误区内存被 cache 占满是不是问题很多初次接触 Linux 内存机制的人会问“为什么我刚启动一个 Java 进程free 就没多少了buff/cache 占了两个 G是不是要手动释放”不需要。buff/cache是内核缓存是用来加速文件读写的不会长期霸占物理内存。当系统内存出现压力时内核内核会优先回收这部分页面而不是立刻触发 OOM。如果你想验证这一点在内存使用看起来“很高”时运行一个大应用观察available的变化即可。不要在生产环境执行echo 3 /proc/sys/vm/drop_caches之类的操作来手动释放 cache这不会提升性能反而会丢掉大量缓存导致后续读盘变慢并加大磁盘 I/O 压力。7.4 Swap 的意义Swap 行显示交换分区的使用情况。理想的运维状态是 Swap 基本为 0。如果 Swap 持续增长说明物理内存已经吃紧系统开始把内存页换到磁盘。磁盘的速度远低于内存所以一旦 Swap 开始增长服务响应时间会明显上升。排查 Swap 升高的路径是free -h top -o %MEMtop -o %MEM会直接按内存占用率排序。找到内存占用最高的进程后再结合业务的堆内存配置、连接数配置检查是否超出预期。7.5 获取更细粒度内存信息如果free的汇总级别不够可以读取cat /proc/meminfo这个文件会列出MemTotal、MemFree、MemAvailable、Buffers、Cached、SwapTotal、SwapFree等更加细节的字段。性能排查脚本如果要采集内存数据从/proc/meminfo解析是更常用的方式。7.6 内存排查建议第一优先看available不是free。buff/cache高通常不是问题反而是 Linux 磁盘性能优化的体现。Swap 升高需要警惕。如果OOM日志在/var/log/messages或dmesg中出现说明当时确实发生了物理内存耗尽需要结合业务进程内存配置来调整。8. df磁盘空间与 inode两个“满了”不等价磁盘排查有两个维度容量和 inode。df命令可以同时覆盖这两个维度。8.1 基础用法df -h输出示例Filesystem Size Used Avail Use% Mounted on /dev/vda1 40G 20G 18G 53% / tmpfs 3.9G 0 3.9G 0% /dev/shm /dev/vdb1 100G 80G 15G 85% /data每一列含义Filesystem文件系统设备或挂载源。Size总容量。Used已使用容量。Avail当前用户可用的容量。Use%使用率。Mounted on挂载点。排查时最重要的字段是Avail和Use%。如果某个挂载点Use%已经超过 85%建议提前规划磁盘扩容或者清理日志和过期备份。8.2 查看 inode 使用情况如果磁盘打不开文件或者应用报错No space left on device但df -h显示容量还够第一反应应该是检查 inodedf -i输出示例Filesystem Inodes IUsed IFree IUse% Mounted on /dev/vda1 2621440 243000 2378440 10% /IUse%达到 100% 时即使容量没满也无法再创建新文件。生产环境常见的 inode 耗尽场景包括邮件服务器产生了大量小邮件文件。日志文件切分过于频繁产生海量小日志文件。临时目录/tmp下有大量遗留小文件。Docker 容器频繁重建残留了大量的 overlay 文件系统层或临时文件。出现 inode 耗尽时先用df -i确认哪个挂载点满了然后在对应目录下用find找出小文件数量最多的目录。find /data -xdev -type f | wc -l要找到占用文件数量最多的前几个目录可以这样排查for dir in $(find /data -maxdepth 2 -type d 2/dev/null); do echo $(find $dir -xdev -type f | wc -l) $dir; done | sort -rn | head -20找到集中目录后删除过期小文件inode 会立刻恢复。这个操作同样需要先确认目录是业务数据还是垃圾文件不要盲目删除。8.3 df 和 du 显示不一致日常排查中还会遇到df -h显示磁盘满了但用du -sh *加起来却远小于总容量的情况。可能原因主要有三类可能原因说明删除过的文件仍被进程占用文件被删除但句柄未释放空间不会立刻回收隐藏文件或大目录漏统计需要确认是否用了du -sh *或漏掉了.开头的目录文件系统元数据/预留空间某些文件系统会预留部分块给 rootdf统计口径与du不同最常见的是第一种日志文件被rm删除但是写日志的进程没有重启文件句柄依然打开着磁盘空间不会释放。定位方法是找出打开但已删除的文件lsof L1lsof L1会列出所有link count 1的文件也就是已经被删除却仍被进程打开的文件。找到对应文件的 PID 后可以重启进程或者确认内容后通过/proc/PID/fd/目录下的句柄进一步处理。8.4 查找占用空间的大文件容量维度排查最常用的组合是# 查看当前目录一级子目录占用 du -h --max-depth1 /data | sort -hr | head -20 # 找出指定目录下大于 500M 的文件 find /data -type f -size 500M -exec ls -lh {} \; | sort -k5 -hr这两个命令组合基本可以在 1 到 2 分钟内定位一块磁盘上的大目录和超大文件。9. 常见问题与排查思路下面列出几组在真实环境中反复出现的现象、原因、排查方法和解决方案。这些 Case 已经按“现象到结论”的价值排序。问题现象可能原因排查方式解决方案系统很卡但 top 中 %CPU 总和不高大量进程在等待磁盘 I/Owa高执行top观察第三行wa是否很高再用iostat -x 1看磁盘%util优化 SQL 或接口考虑把磁盘换成 SSD限制日志写入频率load average 很高top 里没有高 CPU 进程进程进入不可中断睡眠等待 I/O执行top按D状态观察进程用iostat观察磁盘压力确认是否有 I/O 密集任务检查磁盘健康度必要时增加内存减少 swapfree 显示 used 高、free 小业务进程确实占用了大量内存或 cache 较高执行free -h重点看available执行top -o %MEM定位高内存进程如果available充足则不必处理如果不足考虑优化进程内存或扩容磁盘还有空间但创建文件报 No space left on deviceinode 耗尽执行df -i查看 IUse%清理小文件调整文件系统重建前先备份df -h 显示磁盘满du 加起来没满删除过的文件仍被进程占用执行lsof L1确认后重启占用进程或清理由/proc/PID/fd指向的句柄lscpu 不显示 Model name虚拟化环境未透传 CPU 型号执行 cat /proc/cpuinfogrep -m 1 model name云服务器 CPU 显示不高业务却慢st被宿主机抢占CPU 被偷走执行top观察第三行st是否过高调整实例规格或迁移到负载更低的宿主机这些问题的共同点是单看一个命令的“数字”不够必须结合多个命令一起判断。比如负载高不代表 CPU 不够内存占用高不代表内存不够磁盘有空间不代表可以写文件。多命令交叉验证才是稳定可靠的排查方式。10. 最佳实践与工程建议10.1 养成“登录先看”的习惯建议每次登录 Linux 服务器后按固定顺序执行一次lscpu | grep -E ^(CPU\(s\)|Thread|Core|Socket|Model name) free -h df -h w这四条命令无论谁登录都能在十秒内看到机器的基本盘。不要等到业务报障才想起来看。10.2 用组合命令代替单一命令负载高低要靠lscpu的逻辑 CPU 数来判断。系统负载高时要靠top定位进程。内存够不够要靠free的available字段判断。磁盘异常要同时执行df -h和df -i。10.3 把现场数据留存给排障用如果遇到反复出现的故障在故障发生时不要只拍照可以低成本采集现场date /tmp/sys_issue_$(date %s).log w /tmp/sys_issue_$(date %s).log top -b -n 1 /tmp/sys_issue_$(date %s).log free -h /tmp/sys_issue_$(date %s).log df -h /tmp/sys_issue_$(date %s).log df -i /tmp/sys_issue_$(date %s).log这组命令把问题和现场固定到文件里后续分析、复盘、对比都能用。10.4 设置别名加快日常操作可以在~/.bashrc中加几个简化命令alias cllscpu | grep -E ^(CPU\(s\)|Thread|Core|Socket|Model name) alias mffree -h df -h df -i alias cpuloadtop -b -n 1 | head -5配置后执行source ~/.bashrc立即生效。注意不要在生产环境的全局/etc/profile里放太多自定义别名避免影响其他人。10.5 尊重权限与安全边界top里按k杀进程、用rm清理文件、调整磁盘分区这些操作都会影响生产环境。动手前一定要确认三件事当前会话是否具备权限避免用 root 执行不需要 root 的查询命令。是否已经对业务影响做过评估清理文件前先确认是不是业务当前正在使用的数据。是否有备份或回滚方案删除、格式化、修改分区属于高危操作必须先备份并确认回滚路径。安全实践应该遵循最小权限原则能只读查询就不写能单独进程处理就不全局操作能先在测试环境验证就不直接在生产环境试。10.6 结合历史数据与监控系统top、free、df这些命令看到的是瞬时快照适合现场排查。如果想判断趋势建议接入监控系统。node_exporter、Prometheus、Grafana 这类开源组件可以从同一组内核数据中采集指标按时间维度展示负载、CPU、内存、磁盘的变化曲线。这样在故障发生前往往就能从曲线中提前发现风险而不是等load average爆表了再手动执行命令。10.7 深入学习建议理解/proc文件系统/proc/loadavg、/proc/meminfo、/proc/cpuinfo是这些命令的数据来源。掌握iostat和iotop当top里wa偏高时用它们定位磁盘 I/O 瓶颈。掌握vmstat它能把 CPU、内存、I/O 的多个关键指标合并成一个动态视图。学会使用pidstat按进程维度输出 CPU、内存、I/O 数据比top更适合批量数据采集。继续熟悉du、lsof、find的组合用法磁盘空间问题真正动手处理时它们的配合程度决定了效率。11. 总结与后续学习方向这一篇从“服务器变慢了怎么办”这个具体问题出发依次拆解了lscpu、w、top、free、df五个命令。你需要记住的核心结论有五个lscpu负责让你知道系统有多少逻辑 CPU这是判断负载是否过高的基数w负责在登录后第一时间展示负载和在线用户信息top负责实时定位进程级别的 CPU、内存占用和线程状态free负责判断内存使用是否健康重点看available而不是被buff/cache吓到df负责检查磁盘容量和 inode两个维度都不能漏掉。把这五个命令串起来就是一套完整的“发现问题 → 确认方向 → 定位进程 → 判断资源”的排查路径。建议你找一台测试服务器把每个命令都执行一遍对照本文的字段说明做一次输出分析。下次再遇到线上系统变慢你至少能直接说出“是 CPU 不够、内存吃紧、磁盘 I/O 等待过高还是磁盘空间不足”而不是只丢出一句“感觉服务器很卡”。 Linux系统变慢？lscpu、w、top、free、df命令帮你快速定位
系统变慢了第一反应是什么上服务器敲free看内存还有多少跑top看哪个进程在吃 CPU再执行df -h确认磁盘有没有写满。这是很多后端开发同学和运维同学的真实肌肉记忆。问题在于这几个命令每个人都会敲但真正能通过输出内容快速定位问题的却不一定是多数。有些场景下load average已经飙到三位数CPU 占用却很低有些场景下free显示内存几乎耗尽系统却依然流畅还有些场景下df -h显示磁盘还有几十 G但创建文件就是失败。如果只看命令表面很容易被这些现象带偏。这一篇把 Linux 运维排查中最常用的五个命令一次性讲透lscpu、w、top、free、df。它们分别对应 CPU 信息、系统负载、进程资源、内存使用和磁盘容量。弄清楚这些命令的关键字段、常见误区和组合用法你在排查“系统变慢”这个问题时就不需要再靠猜了。1. 这篇文章真正要解决的问题很多人用top看一眼 CPU 占用率再用free看一眼内存觉得“数值没满就是没问题”。但真实的生产环境远比这个复杂。举个例子一台 8 核 16 线程的服务器top里显示的是 16 个逻辑 CPU而不是 8 个物理核。如果你不知道这 16 个数字是怎么来的就很难理解为什么load average到达 16 还不算严重而到达 32 才意味着性能明显恶化。lscpu解决的就是这个认知前提。再举一个例子free里有一项buff/cache在 Linux 的经典内存管理机制下可能会看到几 GB 甚至几十 GB 都被 cache 占用了。很多新手第一反应是“内存不够了”但其实这部分内存是当文件读写缓存用的系统内存吃紧时会被自动回收。如果误判这一点你可能会为了“释放内存”去重启服务反而白白增加一次故障。这篇文章会从概念对比开始把五个命令的主要输出字段、典型应用场景和组合排查思路逐一拆开。读完之后你应该能达到一个状态拿到一台 Linux 服务器能用一条lscpu确认硬件底座用w快速看负载用top定位进程用free分析内存用df检查磁盘空间。如果做到这五步80% 的“服务器响应慢”类问题你都能在第一轮排查中确定方向。2. 负载、CPU、内存、磁盘先分清四个概念在看命令之前必须先用一点点篇幅把四个核心概念厘清。命令输出只是结果概念才是判断依据。2.1 系统负载Load Average与 CPU 占用率load average是 Linux 系统非常关键的指标它表示一段时间内处于可运行状态正在使用 CPU、等待 CPU以及不可中断睡眠状态通常是等待磁盘 I/O、等待网络 I/O的进程平均数量。简单理解就是“平均有多少进程在排队等 CPU 或等 I/O”。CPU 占用率是某一时刻 CPU 忙的时间比例而负载是“队列长度”的度量。两者有关系但不等价如果一个进程在等待磁盘数据CPU 占用率可能不高但负载会持续升高。判断负载是否异常不能只看绝对值要看逻辑 CPU 数量。8 核机器负载 8 意味着刚好满载16 核机器负载 8 说明还有余量。这也是为什么下一节要先讲lscpu。2.2 物理内存、Swap 与 Cache物理内存是真正的 RAMfree命令中总量、已用、可用等字段都来自内核的meminfo。Swap 是把磁盘空间当内存用的一种扩展机制当物理内存不足时不常用的内存页会被交换到磁盘上。buff/cache是缓冲区和高页缓存Linux 会把读写过的磁盘数据放在内存里加速下一次读写。这部分内存看似“用了”但实际上在应用程序需要时可以被回收。所以判断内存到底够不够要用available字段而不是用free字段。2.3 磁盘容量与 inode磁盘容量指的是数据块的总量df -h看的通常是容量。inode 是文件系统管理文件元数据的索引节点每个文件或目录都要消耗一个 inode。容量有剩余但 inode 耗尽同样会提示“No space left on device”这是排查磁盘问题时需要特别注意的坑。2.4 四者关系概念关心的问题对应命令系统负载平均有多少进程在排队w、top、uptimeCPU核数、架构、使用率lscpu、top内存物理内存、Swap、Cachefree磁盘容量、inode、读写等待df、du、iostat这一组概念是后文所有命令的基础。不要跳过直接看命令否则遇到实际情况容易“读得懂数值定不了故障”。3. 环境准备与命令帮助信息的获取这五个命令不需要额外安装属于 Linux 基础工具集。lscpu来自util-linux包。w来自procps-ng或sysvinit-tools包。top来自procps-ng包。free来自procps-ng包。df来自coreutils包。绝大多数的 CentOS、Ubuntu、Debian、openEuler 等发行版都自带了这些命令。如果你使用的精简 Docker 镜像里缺失了某个命令可以用包管理器安装。# CentOS / RHEL / openEuler yum install -y procps-ng util-linux coreutils # Ubuntu / Debian apt update apt install -y procps util-linux coreutils注意free在不同发行版中包装名不完全一致Debian/Ubuntu 中它位于procps包内CentOS/RHEL 中位于procps-ng包内。如果你对某个命令的字段不确定最常用的两个帮助入口是man free free --helpman页面内容完整适合精读--help输出精简适合速查。本文后面提到的所有字段也建议大家在真实服务器上对照执行一遍输出可能因为发行版版本不同而略有差异但核心字段含义是稳定的。本文示例基于主流 Linux 发行版的默认输出格式不针对特定版本展开。命令的核心逻辑是通用思路。4. lscpu先看清机器到底有几颗 CPU、几个核很多人在排查负载时犯的第一个错误是不知道这台服务器到底有多少逻辑 CPU。4.1 基本用法与输出解读直接执行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关键字段按重要性排序如下字段含义排查中的用途CPU(s)逻辑 CPU 数量判断 load average 是否过高的基准值Thread(s) per core每个物理核的线程数判断是否开启超线程Core(s) per socket每个 CPU 插槽的物理核数判断业务可以占用多少独立执行单元Socket(s)CPU 插槽数量判断是不是多路主板Model nameCPU 型号判断处理器代际和主频范围ArchitectureCPU 架构判断是否 x86_64 / aarch64CPU max MHz最高主频判断是否有睿频空间逻辑 CPU 数量的计算公式是逻辑 CPU 数 Socket(s) × Core(s) per socket × Thread(s) per core比如上面这台机器1 × 4 × 2 8所以这台服务器的load average如果需要压满在纯计算场景下至少要跑到 8 以上才算“满载”。如果是 8 逻辑核的机器load 常年处于 16那就说明排队翻倍了需要进一步看top定位是哪些进程在抢资源。4.2 快速获取逻辑 CPU 数量的三种方式如果不想看完整lscpu输出可以直接用命令行提取# 方式一直接从 lscpu 提取 lscpu | grep -E ^CPU\(s\): | awk {print $2} # 方式二查看 /proc/cpuinfo 中 processor 个数 grep -c ^processor /proc/cpuinfo # 方式三使用 nproc nprocnproc会输出当前进程可用的 CPU 数量在容器环境下尤其有用。因为容器的 CPU 配额可能会被限制lscpu看到的可能是宿主机的总体规格而nproc看到的可能是容器内实际可用的配额。这个区别对排查线上容器负载很有意义。4.3 常见误区lscpu 不显示型号有些云服务器或精简版系统上执行lscpu输出里没有Model name字段或者显示为Model name: N/A。这是因为某些虚拟化环境或内核启动参数没有完整透传 CPU 型号信息。遇到这种情况可以尝试cat /proc/cpuinfo | grep -m 1 model name如果/proc/cpuinfo也没有说明宿主机把 CPU 信息隐藏了这不会影响功能但会影响你对主频和代际的判断。遇到这类现象不必惊慌不代表机器有问题只需要换用cat /proc/cpuinfo核对即可。4.4 lscpu 在排查中的实际价值判断负载是否异常的“基数”是多少。判断是否需要多路应用进程数量按 CPU 核数设置。确认是物理机还是虚拟机架构。排查编程语言运行时或数据库线程池配置时作为核心参数依据。5. w系统负载和当前登录状态的第一眼信息w命令适合在登录服务器后第一时间执行。它会在一条命令内同时展示当前时间、开机时长、登录用户数量、系统负载、每个登录用户的活动情况和终端占用。5.1 基本用法w第一次执行时输出大概长这样14:22:30 up 3 days, 2:18, 2 users, load average: 0.08, 0.12, 0.15 USER TTY FROM LOGIN IDLE JCPU PCPU WHAT root pts/0 192.168.1.10 13:50 0.00s 0.05s 0.05s -bash ubuntu pts/1 192.168.1.23 12:10 5:30 0.10s 0.02s vim nginx.conf5.2 第一行信息解析第一行的load average: 0.08, 0.12, 0.15是整条命令的重点。三个数字分别代表过去 1 分钟、5 分钟、15 分钟的平均负载。数字越高说明系统在过去这段时间内排队执行的进程越多。up 3 days, 2:18表示系统已连续运行 3 天 2 小时 18 分钟。这个信息对排查“是不是有人重启过服务器”或“服务器是否因负载过高自动重启过”很有帮助。2 users表示当前有 2 个登录会话。这个信息对排查多人操作同一台服务器的场景非常实用。5.3 load average 应该怎么判断判断负载是否异常的常用参考标准如下逻辑 CPU 数负载参考值判断80~8正常可继续观察88~16偏高需要定位进程816严重可能已经影响业务这里的逻辑是负载值等于逻辑 CPU 数时系统刚好能把所有 CPU 队列排满超过这个值就意味着多出来的进程在等待。但需要注意负载高不一定代表 CPU 忙也可能是因为大量进程在等待磁盘 I/O。所以只看w不能下结论下一步必须用top辅助确认。uptime命令的输出比w更精简只包含第一行uptime14:22:30 up 3 days, 2:18, 2 users, load average: 0.08, 0.12, 0.15如果想在脚本里快速获取负载可以读/proc/loadavgcat /proc/loadavg输出0.08 0.12 0.15 1/345 12345其中前三位是 1、5、15 分钟负载第四个字段表示“当前可运行进程数/总进程数”最后一个字段是最近创建的进程 PID。脚本监控时可以直接解析这个文件不需要反复调用w。5.4 w 适合什么时候用登录服务器后想快速了解当前系统整体状态。接受告警时先看一眼负载和在线用户判断是正常流量还是异常有人登录执行了任务。写脚本时用/proc/loadavg做轻量级采集。真正要定位哪个进程消耗了资源w不够必须进入top。6. top实时查看系统负载、CPU、内存和进程状态top是 Linux 排查问题时使用频率最高的命令之一。它每隔几秒刷新一次把系统整体资源和所有进程的资源占用动态展示在终端上是快速定位“谁在偷吃 CPU/内存”的核心工具。6.1 基本执行top进入交互界面后默认按 CPU 使用率从高到低排序。上方是系统概要信息下方是进程列表。top - 14:30:02 up 3:15, 2 users, load average: 1.05, 0.80, 0.60 Tasks: 220 total, 2 running, 218 sleeping, 0 stopped, 0 zombie %Cpu(s): 12.5 us, 6.2 sy, 0.0 ni, 81.2 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st MiB Mem : 7976.0 total, 2500.0 free, 3200.0 used, 2276.0 buff/cache MiB Swap: 2048.0 total, 2048.0 free, 0.0 used. 3700.0 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME COMMAND 1234 root 20 0 600000 45000 8000 S 30.0 0.6 1:23.45 java 2345 root 20 0 300000 20000 6000 S 10.0 0.3 0:34.56 python36.2 前五行概要信息逐一解释第一行和w的第一行完全一样。top - 14:30:02表示当前时间up 3:15表示开机时长load average三个值含义前文已讲过。这个位置的价值在于和进程列表放在同一屏不用来回切换命令。第二行进程状态汇总。total进程总数注意这里统计的是线程数Linux 中线程也以任务为单位。running正在运行状态包括等待 CPU 调度的进程。sleeping休眠状态大多数正常服务都在睡眠中等待事件。stopped被SIGSTOP暂停的进程。zombie僵尸进程子进程已退出但父进程没有调用wait()回收资源。如果zombie数字持续大于 0需要注意父进程是否有 bug但少量僵尸进程一般不直接导致系统不可用。第三行CPU 使用率。%Cpu(s): 12.5 us, 6.2 sy, 0.0 ni, 81.2 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st缩写全称含义ususer用户态 CPU 时间占比sysystem内核态 CPU 时间占比ninice低优先级nice 值调整过进程占用的 CPUididle空闲 CPU 比例waiowait等待 I/O 完成的时间占比hihardware interrupt硬件中断占比sisoftware interrupt软件中断占比ststeal time被虚拟化环境偷走的时间云服务器上常见wa高意味着有进程在等磁盘或网络 I/OCPU 可能只是“被迫空闲”。此时 CPU 不高但系统慢重点应该查磁盘 I/O而top本身只能发现问题进一步定位要借助iostat或iotop。st高则说明宿主机的资源竞争影响了当前虚拟机。第四、五行内存信息。其中total、free、used、buff/cache、avail Mem等含义与free命令一致后文会详细说明。6.3 常用交互命令进入top后按下面这些键可以快速切换视图P 按 CPU 使用率排序默认 M 按内存使用率排序 T 按累计 CPU 时间排序 N 按 PID 排序 k 杀掉指定 PID 的进程会提示输入 PID 和信号 r 重新设置进程 nice 值 d 修改刷新间隔单位秒 q 退出 top如果只想看某个用户启动了哪些进程按u再输入用户名u输入root后进程列表就只显示 root 用户的进程。这个功能在多人共用的服务器上非常有用。6.4 进程列表关键列列名含义PID进程 IDUSER启动进程的用户PR内核调度优先级NInice 值影响优先级高低VIRT虚拟内存大小RES实际驻留物理内存大小SHR共享内存大小S进程状态常见的是 S睡眠、R运行、Z僵尸%CPUCPU 使用率%MEM物理内存占比TIME累计 CPU 时间COMMAND命令名称RES常驻内存比 VIRT虚拟内存更值得关注。一个 Java 进程 VIRT 可能到十几个 G但真正占用物理内存的是 RES。6.5 查看指定进程的线程如果一个进程整体 CPU 不高但它内部某个线程出了问题就需要按线程视角查看top -H -p 12341234替换为实际进程 PID。此模式下进程的每个线程都会显示为一行可以定位是哪一个线程在疯狂占用 CPU。拿到线程号后再结合jstack或其他语言对应的线程转储工具可以进一步分析业务代码。6.6 批量输出到文件top交互模式适合人看不适合脚本采集。如果想抓取一次快照可以这样top -b -n 1-b表示非交互模式-n 1表示只输出一次。输出后可以配合head、grep提取想要的内容也可以直接追加到日志文件top -b -n 1 /var/log/top_$(date %F_%H%M).log在生产环境中这种快照采集适合作为短时间内的现场记录但不建议长期高频运行避免额外增加系统开销。6.7 top 在排查中的典型路径执行w确认负载偏高。执行top进入动态界面按P确认 CPU 排在最前的是哪些进程。如果%CPU很高的是业务进程再按M看内存占用。如果某个进程占满 CPU用top -H -p PID看具体线程。按q退出结合日志和代码继续定位。7. free真正看懂内存使用不要被“占用高”吓到free是查看内存使用情况的核心命令。但很多人在看到free很小、used很大的时候就直接判断“内存不足”这个结论往往是错的。7.1 基本用法free -h-h会以人类友好的单位显示比如GiB、MiB。如果脚本需要按统一单位解析可以用-m强制以 MB 输出free -m实际输出示例total used free shared buff/cache available Mem: 7976 3200 2500 20 2276 3700 Swap: 2048 0 20487.2 字段含义字段含义total物理内存总量used已被使用的内存free完全没有被使用的内存shared各进程共享的内存buff/cache内核缓冲区与页面缓存available可用于启动新应用的内存估算值available是判断内存是否够用的首选字段。它的含义是在不触发明显 swap 的前提下还能分配给新进程的内存大小。buff/cache大并不等于内存不够。Linux 会自动利用空闲内存做文件缓存当应用需要内存时这一部分会被回收。所以used高、free小但available足够大说明系统运行非常健康。7.3 常见误区内存被 cache 占满是不是问题很多初次接触 Linux 内存机制的人会问“为什么我刚启动一个 Java 进程free 就没多少了buff/cache 占了两个 G是不是要手动释放”不需要。buff/cache是内核缓存是用来加速文件读写的不会长期霸占物理内存。当系统内存出现压力时内核内核会优先回收这部分页面而不是立刻触发 OOM。如果你想验证这一点在内存使用看起来“很高”时运行一个大应用观察available的变化即可。不要在生产环境执行echo 3 /proc/sys/vm/drop_caches之类的操作来手动释放 cache这不会提升性能反而会丢掉大量缓存导致后续读盘变慢并加大磁盘 I/O 压力。7.4 Swap 的意义Swap 行显示交换分区的使用情况。理想的运维状态是 Swap 基本为 0。如果 Swap 持续增长说明物理内存已经吃紧系统开始把内存页换到磁盘。磁盘的速度远低于内存所以一旦 Swap 开始增长服务响应时间会明显上升。排查 Swap 升高的路径是free -h top -o %MEMtop -o %MEM会直接按内存占用率排序。找到内存占用最高的进程后再结合业务的堆内存配置、连接数配置检查是否超出预期。7.5 获取更细粒度内存信息如果free的汇总级别不够可以读取cat /proc/meminfo这个文件会列出MemTotal、MemFree、MemAvailable、Buffers、Cached、SwapTotal、SwapFree等更加细节的字段。性能排查脚本如果要采集内存数据从/proc/meminfo解析是更常用的方式。7.6 内存排查建议第一优先看available不是free。buff/cache高通常不是问题反而是 Linux 磁盘性能优化的体现。Swap 升高需要警惕。如果OOM日志在/var/log/messages或dmesg中出现说明当时确实发生了物理内存耗尽需要结合业务进程内存配置来调整。8. df磁盘空间与 inode两个“满了”不等价磁盘排查有两个维度容量和 inode。df命令可以同时覆盖这两个维度。8.1 基础用法df -h输出示例Filesystem Size Used Avail Use% Mounted on /dev/vda1 40G 20G 18G 53% / tmpfs 3.9G 0 3.9G 0% /dev/shm /dev/vdb1 100G 80G 15G 85% /data每一列含义Filesystem文件系统设备或挂载源。Size总容量。Used已使用容量。Avail当前用户可用的容量。Use%使用率。Mounted on挂载点。排查时最重要的字段是Avail和Use%。如果某个挂载点Use%已经超过 85%建议提前规划磁盘扩容或者清理日志和过期备份。8.2 查看 inode 使用情况如果磁盘打不开文件或者应用报错No space left on device但df -h显示容量还够第一反应应该是检查 inodedf -i输出示例Filesystem Inodes IUsed IFree IUse% Mounted on /dev/vda1 2621440 243000 2378440 10% /IUse%达到 100% 时即使容量没满也无法再创建新文件。生产环境常见的 inode 耗尽场景包括邮件服务器产生了大量小邮件文件。日志文件切分过于频繁产生海量小日志文件。临时目录/tmp下有大量遗留小文件。Docker 容器频繁重建残留了大量的 overlay 文件系统层或临时文件。出现 inode 耗尽时先用df -i确认哪个挂载点满了然后在对应目录下用find找出小文件数量最多的目录。find /data -xdev -type f | wc -l要找到占用文件数量最多的前几个目录可以这样排查for dir in $(find /data -maxdepth 2 -type d 2/dev/null); do echo $(find $dir -xdev -type f | wc -l) $dir; done | sort -rn | head -20找到集中目录后删除过期小文件inode 会立刻恢复。这个操作同样需要先确认目录是业务数据还是垃圾文件不要盲目删除。8.3 df 和 du 显示不一致日常排查中还会遇到df -h显示磁盘满了但用du -sh *加起来却远小于总容量的情况。可能原因主要有三类可能原因说明删除过的文件仍被进程占用文件被删除但句柄未释放空间不会立刻回收隐藏文件或大目录漏统计需要确认是否用了du -sh *或漏掉了.开头的目录文件系统元数据/预留空间某些文件系统会预留部分块给 rootdf统计口径与du不同最常见的是第一种日志文件被rm删除但是写日志的进程没有重启文件句柄依然打开着磁盘空间不会释放。定位方法是找出打开但已删除的文件lsof L1lsof L1会列出所有link count 1的文件也就是已经被删除却仍被进程打开的文件。找到对应文件的 PID 后可以重启进程或者确认内容后通过/proc/PID/fd/目录下的句柄进一步处理。8.4 查找占用空间的大文件容量维度排查最常用的组合是# 查看当前目录一级子目录占用 du -h --max-depth1 /data | sort -hr | head -20 # 找出指定目录下大于 500M 的文件 find /data -type f -size 500M -exec ls -lh {} \; | sort -k5 -hr这两个命令组合基本可以在 1 到 2 分钟内定位一块磁盘上的大目录和超大文件。9. 常见问题与排查思路下面列出几组在真实环境中反复出现的现象、原因、排查方法和解决方案。这些 Case 已经按“现象到结论”的价值排序。问题现象可能原因排查方式解决方案系统很卡但 top 中 %CPU 总和不高大量进程在等待磁盘 I/Owa高执行top观察第三行wa是否很高再用iostat -x 1看磁盘%util优化 SQL 或接口考虑把磁盘换成 SSD限制日志写入频率load average 很高top 里没有高 CPU 进程进程进入不可中断睡眠等待 I/O执行top按D状态观察进程用iostat观察磁盘压力确认是否有 I/O 密集任务检查磁盘健康度必要时增加内存减少 swapfree 显示 used 高、free 小业务进程确实占用了大量内存或 cache 较高执行free -h重点看available执行top -o %MEM定位高内存进程如果available充足则不必处理如果不足考虑优化进程内存或扩容磁盘还有空间但创建文件报 No space left on deviceinode 耗尽执行df -i查看 IUse%清理小文件调整文件系统重建前先备份df -h 显示磁盘满du 加起来没满删除过的文件仍被进程占用执行lsof L1确认后重启占用进程或清理由/proc/PID/fd指向的句柄lscpu 不显示 Model name虚拟化环境未透传 CPU 型号执行 cat /proc/cpuinfogrep -m 1 model name云服务器 CPU 显示不高业务却慢st被宿主机抢占CPU 被偷走执行top观察第三行st是否过高调整实例规格或迁移到负载更低的宿主机这些问题的共同点是单看一个命令的“数字”不够必须结合多个命令一起判断。比如负载高不代表 CPU 不够内存占用高不代表内存不够磁盘有空间不代表可以写文件。多命令交叉验证才是稳定可靠的排查方式。10. 最佳实践与工程建议10.1 养成“登录先看”的习惯建议每次登录 Linux 服务器后按固定顺序执行一次lscpu | grep -E ^(CPU\(s\)|Thread|Core|Socket|Model name) free -h df -h w这四条命令无论谁登录都能在十秒内看到机器的基本盘。不要等到业务报障才想起来看。10.2 用组合命令代替单一命令负载高低要靠lscpu的逻辑 CPU 数来判断。系统负载高时要靠top定位进程。内存够不够要靠free的available字段判断。磁盘异常要同时执行df -h和df -i。10.3 把现场数据留存给排障用如果遇到反复出现的故障在故障发生时不要只拍照可以低成本采集现场date /tmp/sys_issue_$(date %s).log w /tmp/sys_issue_$(date %s).log top -b -n 1 /tmp/sys_issue_$(date %s).log free -h /tmp/sys_issue_$(date %s).log df -h /tmp/sys_issue_$(date %s).log df -i /tmp/sys_issue_$(date %s).log这组命令把问题和现场固定到文件里后续分析、复盘、对比都能用。10.4 设置别名加快日常操作可以在~/.bashrc中加几个简化命令alias cllscpu | grep -E ^(CPU\(s\)|Thread|Core|Socket|Model name) alias mffree -h df -h df -i alias cpuloadtop -b -n 1 | head -5配置后执行source ~/.bashrc立即生效。注意不要在生产环境的全局/etc/profile里放太多自定义别名避免影响其他人。10.5 尊重权限与安全边界top里按k杀进程、用rm清理文件、调整磁盘分区这些操作都会影响生产环境。动手前一定要确认三件事当前会话是否具备权限避免用 root 执行不需要 root 的查询命令。是否已经对业务影响做过评估清理文件前先确认是不是业务当前正在使用的数据。是否有备份或回滚方案删除、格式化、修改分区属于高危操作必须先备份并确认回滚路径。安全实践应该遵循最小权限原则能只读查询就不写能单独进程处理就不全局操作能先在测试环境验证就不直接在生产环境试。10.6 结合历史数据与监控系统top、free、df这些命令看到的是瞬时快照适合现场排查。如果想判断趋势建议接入监控系统。node_exporter、Prometheus、Grafana 这类开源组件可以从同一组内核数据中采集指标按时间维度展示负载、CPU、内存、磁盘的变化曲线。这样在故障发生前往往就能从曲线中提前发现风险而不是等load average爆表了再手动执行命令。10.7 深入学习建议理解/proc文件系统/proc/loadavg、/proc/meminfo、/proc/cpuinfo是这些命令的数据来源。掌握iostat和iotop当top里wa偏高时用它们定位磁盘 I/O 瓶颈。掌握vmstat它能把 CPU、内存、I/O 的多个关键指标合并成一个动态视图。学会使用pidstat按进程维度输出 CPU、内存、I/O 数据比top更适合批量数据采集。继续熟悉du、lsof、find的组合用法磁盘空间问题真正动手处理时它们的配合程度决定了效率。11. 总结与后续学习方向这一篇从“服务器变慢了怎么办”这个具体问题出发依次拆解了lscpu、w、top、free、df五个命令。你需要记住的核心结论有五个lscpu负责让你知道系统有多少逻辑 CPU这是判断负载是否过高的基数w负责在登录后第一时间展示负载和在线用户信息top负责实时定位进程级别的 CPU、内存占用和线程状态free负责判断内存使用是否健康重点看available而不是被buff/cache吓到df负责检查磁盘容量和 inode两个维度都不能漏掉。把这五个命令串起来就是一套完整的“发现问题 → 确认方向 → 定位进程 → 判断资源”的排查路径。建议你找一台测试服务器把每个命令都执行一遍对照本文的字段说明做一次输出分析。下次再遇到线上系统变慢你至少能直接说出“是 CPU 不够、内存吃紧、磁盘 I/O 等待过高还是磁盘空间不足”而不是只丢出一句“感觉服务器很卡”。