2026/8/30 3:59:04
FEATURED · 精选文章 
Linux 排查 CPU、内存、磁盘和负载最常用的一组命令就是lscpu、w、top、free、df。很多新手习惯只看top和df -h结果遇到内存明明还有空间却 swap 一直在涨、磁盘df正常却写不进文件这类问题就很难定位。这篇文章按真实运维排查顺序把这 5 个命令拆开讲清楚每个命令的输出字段、常用参数、判断标准以及几个容易误判的坑。适合刚接触 Linux 的开发者也适合准备面试、做系统巡检的运维人员。1. 先搞清楚这些命令各自解决什么问题1.1 五个命令并不是同一类工具lscpu是一台机器的 CPU 架构信息汇总属于静态信息。它告诉你这台机器有几个逻辑 CPU、什么架构、什么型号但不会持续刷新也不会告诉你当前 CPU 忙不忙。w是一个综合状态命令。它能显示当前时间、系统已经运行多久、登录了几个用户以及系统平均负载。重点在“当前”这个时间点而不是历史趋势。top是动态监控工具。它会每隔一段时间刷新进程列表让你看到哪些进程占用 CPU 和内存高也可以看到整个系统有多少任务在运行、多少任务在排队。free是瞬时内存快照。它看的是物理内存和 swap 的使用量不包含进程细节也不显示谁占了内存。df是文件系统磁盘占用查看命令。它显示的是分区、挂载点、容量、剩余空间以及 inode 使用情况。这五个命令各管一段CPU 信息、整体负载、进程资源、内存容量、磁盘容量。把它们组合起来基本能覆盖一台 Linux 机器最常见的基础问题。1.2 不同场景应该先看哪个命令遇到“系统变卡”这种模糊问题我建议不要直接开top而是先按下面这个顺序判断系统响应慢先看w或uptime确认负载高不高。负载高再用lscpu看逻辑 CPU 数量只有拿到核数才能判断负载是否真的过高。负载正常但交互卡顿用top看进程和 CPU 状态确认有没有进程异常占用。怀疑内存不足用free -h看 available 和 swap。怀疑磁盘空间不足用df -h和df -i看容量和 inode。命令选择不是看你会哪些而是看你现在想回答什么问题。2. lscpu确认 CPU 数量、核数、型号和虚拟化情况2.1 lscpu 输出字段怎么读在终端输入lscpu输出是一段 key-value 格式的信息。重点关注这些字段字段含义判断价值ArchitectureCPU 架构常见 x86_64、aarch64决定软件包能否直接安装CPU(s)逻辑 CPU 总数判断负载是否过高的关键参数Thread(s) per core每颗物理核支持的线程数超线程信息Core(s) per socket每颗物理 CPU 的物理核数物理核数量Socket(s)物理 CPU 插槽数整机有几颗 CPUModel nameCPU 型号确认性能水平Hypervisor vendor虚拟化厂商说明是否在虚拟机中这里最容易踩的坑是CPU(s)不是物理核数而是逻辑 CPU 数量。比如一台机器实际有 2 个 Socket每个 Socket 8 核每核 2 线程那逻辑 CPU 就是2 * 8 * 2 32CPU(s)显示 32。这个数字要记下来因为它直接关系到后面的负载判断。如果只想快速提取型号和核数可以加grep筛选lscpu | grep -E Model name|^CPU\(s\)|Core\(s\) per socket|Socket\(s\)|Thread\(s\) per core2.2 lscpu 常用参数和常见异常lscpu默认输出足够日常使用但有几个参数偶尔很有用lscpu -e以列表格式显示每个逻辑 CPU 对应的核、socket、NUMA 节点。做 CPU 绑核或排查 NUMA 不均衡时这个输出更直观。lscpu -J输出 JSON 格式适合脚本处理。lscpu -p输出可解析格式每行一个逻辑 CPU适合写自动化采集。实际使用中还有个常见现象是“lscpu不展示型号”。我遇到比较多的情况是云服务器或虚拟机环境Model name一栏可能是空或者只显示CPU而不是具体型号。这不一定是命令出错很多时候是宿主机没有把 CPU 型号透传给虚拟机。这时候可以补看cat /proc/cpuinfo | grep -i model name | head -n 1如果/proc/cpuinfo里也没有那就要么是被虚拟化屏蔽要么是/proc信息特殊处理。遇到这种情况不用慌CPU(s)、Core(s) per socket这些核数信息通常还是准确的不影响判断负载。3. w一条命令同时摸清负载和登录情况3.1 w 的第一行和表头信息输入w输出分两部分。第一行类似16:30:05 up 10 days, 2:34, 3 users, load average: 0.82, 0.64, 0.55这一行里16:30:05是当前系统时间。up 10 days, 2:34表示系统已经运行 10 天 2 小时 34 分。3 users表示当前有 3 个登录会话。load average: 0.82, 0.64, 0.55是系统平均负载分别表示过去 1 分钟、5 分钟、15 分钟的平均值。第二行是各登录用户的详情USER TTY FROM LOGIN IDLE JCPU PCPU WHAT root pts/0 192.168.1.10 16:20 0.00s 0.05s 0.05s w zhangsan pts/1 192.168.1.20 10:10 40:20 1.20s 0.10s top字段含义USER登录用户名。TTY登录终端。FROM从哪里登录可能是 IP 或主机名。LOGIN登录时间。IDLE用户空闲时间。JCPU占用的累计 CPU 时间。PCPU当前进程占用的 CPU 时间。WHAT用户当前正在执行的命令。w最适合干的事情是快速判断当前系统到底有没有异常登录、谁在跑长时间任务。如果某台机器负载很高先用w看到某个用户正在跑top或make基本可以顺着用户定位到进程。3.2 用 w 判断当前负载是否异常很多人看到load average就紧张但单独看数字没有意义必须结合逻辑 CPU 数量。判断标准可以这样定负载小于CPU(s)说明系统还有余量。负载等于CPU(s)说明 CPU 基本跑满。负载持续大于CPU(s)说明有任务在排队系统已经过载。比如lscpu显示CPU(s): 8负载 2 是正常的如果CPU(s): 2负载也是 2那就已经在满负荷运行了。还要看趋势。1 分钟负载高于 5 分钟和 15 分钟说明任务刚进来可能是突发15 分钟负载一直高于核数说明系统持续过载不是偶然波动。w的常用参数不需要太多日常直接w就够。写脚本时可以用w -h去掉表头只取得第一行的负载信息方便解析。注意w显示的是“当前那一刻”的负载和用户状态。要监控变化建议配合watch或定时执行而不是只看一次。4. top实时进程监控的常青命令4.1 top 界面关键区域top启动后默认全屏刷新界面分成上下两部分。上半部分是系统汇总第一行当前时间、系统运行时间、用户数、负载和w第一行内容一致。第二行Tasks显示总任务数、正在运行、睡眠、停止、僵尸任务数量。第三行%Cpu(s)显示 us用户态、sy内核态、ni调整过优先级的用户态、id空闲、wa等待 IO、hi硬中断、si软中断、st被偷走的时间。第四、五行内存和 swap 的使用情况。下半部分是进程列表PID USER PR NI VIRT RES SHR S %CPU %MEM TIME COMMANDPID进程号。USER运行用户。PR优先级。NInice 值。VIRT虚拟内存总量。RES常驻物理内存。SHR共享内存。S进程状态。%CPUCPU 占用率。%MEM内存占用率。TIME累计 CPU 时间。COMMAND进程命令。新手最容易误解的是%CPU。超过 100% 不是 bug而是这个进程有多个线程在多个逻辑 CPU 上并行计算。比如 8 核机器上某个进程跑了 4 个线程%CPU可能显示 400%。这里要看的是它有没有把你期望的核数吃满而不是被 100% 这个数字吓到。4.2 top 交互操作和常用参数top支持很多交互键优先级最高的是这几个按1切换显示每个逻辑 CPU 的使用情况。按P按 CPU 占用率排序。按M按内存占用排序。按T按累计 CPU 时间排序适合找长时间消耗资源的进程。按c切换显示完整命令行。按u输入用户名只看该用户进程。按k输入 PID 发送信号可退出进程。按q退出。常用参数top -d 2 top -p 1234 top -H -p 1234 top -bn1top -d 2每 2 秒刷新一次默认是 3 秒。top -p 1234只监控指定 PID。top -H -p 1234以线程模式查看指定进程排查多线程应用卡死时很有用。top -bn1批处理模式只输出一次后退出适合脚本采集。4.3 用 top 定位 CPU 或内存异常系统卡顿时先看汇总行的负载再看%Cpu(s)如果us很高说明用户态计算密集找进程列表里%CPU最高的那个。如果wa很高说明 CPU 在等磁盘 IO。这时候高 CPU 进程不一定真有计算任务更多是磁盘读写慢需要结合iostat或iotop进一步看磁盘。如果si很高说明系统在不断进行 swap 换入换出内存压力已经很大。如果st很高说明这台机器可能是虚拟机宿主机资源竞争严重Guest 内部能做的优化有限。进程列表里看S状态列如果出现大量D状态不可中断睡眠通常和磁盘 IO 有关出现大量Z状态僵尸进程说明父进程没有回收子进程需要重点排查父进程。5. free查看内存是否真的不够5.1 free 输出里的关键字段free -h的输出比较直观total used free shared buff/cache available Mem: 31G 10G 8.2G 300M 13G 20G Swap: 8.0G 0B 8.0Gtotal物理内存总量。used系统认为已使用的内存。free完全没有被使用的内存。shared临时文件系统等共享内存通常不用太关注。buff/cache用于缓冲和缓存的内存内核可以回收。available估算出的、在不触发 swap 的前提下还可以分配给新程序的内存。这里最容易犯的错是只看free。很多 Linux 机器运行一段时间后free会非常小但available很大因为大量内存被内核用作文件缓存。这些缓存可以随时回收所以系统并不会因为free小而出问题。判断内存是否充足核心看available。常用参数free -h人类可读格式推荐优先使用。free -m以 MB 为单位适合脚本解析。free -s 3 -c 5每 3 秒输出一次最多输出 5 次。free默认单位 KB阅读不直观生产上很少直接裸跑。5.2 用 available 判断而不是 free判断思路可以这样定available持续接近 total 的 10% 以下内存压力较大。available一度很多但业务高峰期明显下降需要看是不是缓存策略导致。swap 长期为 0说明内存还没到需要交换的程度。swap 使用率持续增长说明物理内存可能一直不够。如果想把free用在巡检脚本里建议直接取 available。下面是一个简单示例free -h | awk /^Mem:/ {print 可用内存: $7}这里$7对应 available 列。不同发行版输出可能有差异建议先在本机跑一次确认列位置。5.3 swap 与内存不足的关系swap 是磁盘上的一块空间用来临时存放不常用的内存页。当物理内存不够时内核会把部分数据从内存交换到 swap。代价是磁盘速度远低于内存所以程序一旦大量读回 swap性能会下降得很明显。有些人遇到内存紧张就执行echo 3 /proc/sys/vm/drop_caches这个命令会清理页缓存、目录项和 inode 缓存。我不建议把它当成日常操作。因为缓存清理后虽然free数字变大了但文件系统读取性能会下降而且这是临时手段不能解决真正的内存不足问题。真正需要做的是先看available和 swap 趋势再定位哪个进程占用高top按M排序或者用ps aux --sort-%mem | head -n 15。注意Linux 内存优化逻辑和 Windows 完全不同。free小、buff/cache大大多数时候是正常状态不要一看到缓存就手动清理。6. df磁盘占用和 inode 检查6.1 df -h 输出和最常用的场景df -h是最常用的磁盘查看命令Filesystem Size Used Avail Use% Mounted on /dev/sda3 98G 55G 38G 60% / tmpfs 3.1G 0 3.1G 0% /dev/shmFilesystem文件系统设备或伪文件系统。Size分区总大小。Used已使用空间。Avail可用空间。Use%使用百分比。Mounted on挂载点。需要先看挂载点再判断是哪个分区出问题。比如根分区/满和/home满影响范围完全不同。如果业务数据在/data那你更应该关注/data对应的 Filesystem而不是只看根分区。df -T可以额外显示文件系统类型比如 ext4、xfs、overlay。容器场景经常能看到 overlay 文件系统容量来自宿主机的分区处理方式要结合宿主机来看。6.2 df -i 处理 inode 打满的问题很多人会忽略df -idf -i输出类似Filesystem Inodes IUsed IFree IUse% Mounted on /dev/sda3 6553600 6540000 13600 100% /这里显示的是 inode 使用情况。inode 是文件系统用来记录文件元数据的索引单元。每个文件或目录至少占用一个 inode。即使磁盘容量还有空间如果 inode 用完系统仍然无法创建新文件。常见触发场景是小文件特别多比如邮件队列、消息队列、临时缓存、解压大量小文件。遇到“写不进文件但 df -h 还有空间”时一定要跑一下df -i。如果IUse%达到 100%就需要清理旧文件或者把数据迁移到支持更多 inode 的文件系统。6.3 磁盘满后的定位思路磁盘满之后系统会出现各种症状日志写不进去、服务启动失败、用户无法登录、数据库异常。定位时按顺序做df -h看哪个挂载点满。df -i排除 inode 满。du -h -d 2 /路径或du -sh /路径/* | sort -hr | head -n 20找大目录。看日志目录比如/var/log通常最容易占满。如果删除了大文件后空间没有释放用lsof | grep deleted查看是否有进程持有已删除文件的句柄。这种情况需要重启该进程或正确处理文件释放。清理日志不要直接删正在写入的日志文件否则进程仍然持有句柄空间不会释放。更稳妥的做法是把日志文件清空或者先判断日志策略再处理。7. 组合使用一套负载到磁盘的排查顺序7.1 遇到机器变慢时的标准顺序我这里给一套我自己常用的排查顺序基本能覆盖大部分普通 Linux 服务器问题# 1. 当前负载和登录情况 w # 2. CPU 核数和型号 lscpu # 3. 动态进程资源和 CPU 状态 top -bn1 -o %CPU | head -n 30 # 4. 内存可用量 free -h # 5. 磁盘容量和 inode df -h df -i不要一次性同时跑一堆命令而是先看每一步结果再决定下一步怎么走。比如第一步w显示负载是 12第二步lscpu显示CPU(s)是 4那系统基本已经过载。接着用top找占用 CPU 最高的进程再配合free和df看是不是内存或磁盘问题。如果第一步w显示负载很低但客户反馈访问慢那就要偏重网络层、应用层比如端到端延迟、数据库连接数、后端服务日志而不是继续纠结内存和磁盘。7.2 容易误判的几个点这部分我踩过不少坑总结成几个高频误判点负载高不等于 CPU 高。负载包含任务排队可能是因为 IO 等待。只看 CPU 使用率会漏掉磁盘问题。free字段小不等于内存不足。必须看available否则容易做无用的缓存清理。top 中%CPU超过 100% 不代表异常可能是多线程并行要结合进程的线程数判断。df -h正常不代表可以创建文件。小文件多的时候df -i可能已经 100%。lscpu不显示型号不代表没有 CPU 信息常见于虚拟化环境核数和架构通常仍可读。这些误判的共同点是先入为主地认为命令输出中某个字面数字异常却忽略了它所在的上下文。7.3 给脚本采集留的参考做巡检脚本时有时候不需要完整界面输出只需要关键指标。可以这样采集lscpu | grep -E ^CPU\(s\)|Model name uptime top -bn1 | head -n 5 free -m df -h / df -i /如果要把输出保存到日志建议每条命令前带上下一次时间戳。比如echo $(date %Y-%m-%d %H:%M:%S) uptime free -m df -h脚本采集和人工排查最大的区别是脚本看重稳定输出人工看重异常判断。不要只搜命令参数而是先搞清楚每个字段在什么情况下是正常值。这几个命令不是学一遍就行的。真正能帮你的是把每次输出和业务场景对应起来大文件导出时 CPU 高不奇怪数据库启动时内存波动也正常。我自己的习惯是先固定一套排查顺序再按任务需求补参数。先学会看字段再理解场景最后把命令变成肌肉记忆。
Linux性能排查必备：lscpu、top、free、df五大命令实战
Linux 排查 CPU、内存、磁盘和负载最常用的一组命令就是lscpu、w、top、free、df。很多新手习惯只看top和df -h结果遇到内存明明还有空间却 swap 一直在涨、磁盘df正常却写不进文件这类问题就很难定位。这篇文章按真实运维排查顺序把这 5 个命令拆开讲清楚每个命令的输出字段、常用参数、判断标准以及几个容易误判的坑。适合刚接触 Linux 的开发者也适合准备面试、做系统巡检的运维人员。1. 先搞清楚这些命令各自解决什么问题1.1 五个命令并不是同一类工具lscpu是一台机器的 CPU 架构信息汇总属于静态信息。它告诉你这台机器有几个逻辑 CPU、什么架构、什么型号但不会持续刷新也不会告诉你当前 CPU 忙不忙。w是一个综合状态命令。它能显示当前时间、系统已经运行多久、登录了几个用户以及系统平均负载。重点在“当前”这个时间点而不是历史趋势。top是动态监控工具。它会每隔一段时间刷新进程列表让你看到哪些进程占用 CPU 和内存高也可以看到整个系统有多少任务在运行、多少任务在排队。free是瞬时内存快照。它看的是物理内存和 swap 的使用量不包含进程细节也不显示谁占了内存。df是文件系统磁盘占用查看命令。它显示的是分区、挂载点、容量、剩余空间以及 inode 使用情况。这五个命令各管一段CPU 信息、整体负载、进程资源、内存容量、磁盘容量。把它们组合起来基本能覆盖一台 Linux 机器最常见的基础问题。1.2 不同场景应该先看哪个命令遇到“系统变卡”这种模糊问题我建议不要直接开top而是先按下面这个顺序判断系统响应慢先看w或uptime确认负载高不高。负载高再用lscpu看逻辑 CPU 数量只有拿到核数才能判断负载是否真的过高。负载正常但交互卡顿用top看进程和 CPU 状态确认有没有进程异常占用。怀疑内存不足用free -h看 available 和 swap。怀疑磁盘空间不足用df -h和df -i看容量和 inode。命令选择不是看你会哪些而是看你现在想回答什么问题。2. lscpu确认 CPU 数量、核数、型号和虚拟化情况2.1 lscpu 输出字段怎么读在终端输入lscpu输出是一段 key-value 格式的信息。重点关注这些字段字段含义判断价值ArchitectureCPU 架构常见 x86_64、aarch64决定软件包能否直接安装CPU(s)逻辑 CPU 总数判断负载是否过高的关键参数Thread(s) per core每颗物理核支持的线程数超线程信息Core(s) per socket每颗物理 CPU 的物理核数物理核数量Socket(s)物理 CPU 插槽数整机有几颗 CPUModel nameCPU 型号确认性能水平Hypervisor vendor虚拟化厂商说明是否在虚拟机中这里最容易踩的坑是CPU(s)不是物理核数而是逻辑 CPU 数量。比如一台机器实际有 2 个 Socket每个 Socket 8 核每核 2 线程那逻辑 CPU 就是2 * 8 * 2 32CPU(s)显示 32。这个数字要记下来因为它直接关系到后面的负载判断。如果只想快速提取型号和核数可以加grep筛选lscpu | grep -E Model name|^CPU\(s\)|Core\(s\) per socket|Socket\(s\)|Thread\(s\) per core2.2 lscpu 常用参数和常见异常lscpu默认输出足够日常使用但有几个参数偶尔很有用lscpu -e以列表格式显示每个逻辑 CPU 对应的核、socket、NUMA 节点。做 CPU 绑核或排查 NUMA 不均衡时这个输出更直观。lscpu -J输出 JSON 格式适合脚本处理。lscpu -p输出可解析格式每行一个逻辑 CPU适合写自动化采集。实际使用中还有个常见现象是“lscpu不展示型号”。我遇到比较多的情况是云服务器或虚拟机环境Model name一栏可能是空或者只显示CPU而不是具体型号。这不一定是命令出错很多时候是宿主机没有把 CPU 型号透传给虚拟机。这时候可以补看cat /proc/cpuinfo | grep -i model name | head -n 1如果/proc/cpuinfo里也没有那就要么是被虚拟化屏蔽要么是/proc信息特殊处理。遇到这种情况不用慌CPU(s)、Core(s) per socket这些核数信息通常还是准确的不影响判断负载。3. w一条命令同时摸清负载和登录情况3.1 w 的第一行和表头信息输入w输出分两部分。第一行类似16:30:05 up 10 days, 2:34, 3 users, load average: 0.82, 0.64, 0.55这一行里16:30:05是当前系统时间。up 10 days, 2:34表示系统已经运行 10 天 2 小时 34 分。3 users表示当前有 3 个登录会话。load average: 0.82, 0.64, 0.55是系统平均负载分别表示过去 1 分钟、5 分钟、15 分钟的平均值。第二行是各登录用户的详情USER TTY FROM LOGIN IDLE JCPU PCPU WHAT root pts/0 192.168.1.10 16:20 0.00s 0.05s 0.05s w zhangsan pts/1 192.168.1.20 10:10 40:20 1.20s 0.10s top字段含义USER登录用户名。TTY登录终端。FROM从哪里登录可能是 IP 或主机名。LOGIN登录时间。IDLE用户空闲时间。JCPU占用的累计 CPU 时间。PCPU当前进程占用的 CPU 时间。WHAT用户当前正在执行的命令。w最适合干的事情是快速判断当前系统到底有没有异常登录、谁在跑长时间任务。如果某台机器负载很高先用w看到某个用户正在跑top或make基本可以顺着用户定位到进程。3.2 用 w 判断当前负载是否异常很多人看到load average就紧张但单独看数字没有意义必须结合逻辑 CPU 数量。判断标准可以这样定负载小于CPU(s)说明系统还有余量。负载等于CPU(s)说明 CPU 基本跑满。负载持续大于CPU(s)说明有任务在排队系统已经过载。比如lscpu显示CPU(s): 8负载 2 是正常的如果CPU(s): 2负载也是 2那就已经在满负荷运行了。还要看趋势。1 分钟负载高于 5 分钟和 15 分钟说明任务刚进来可能是突发15 分钟负载一直高于核数说明系统持续过载不是偶然波动。w的常用参数不需要太多日常直接w就够。写脚本时可以用w -h去掉表头只取得第一行的负载信息方便解析。注意w显示的是“当前那一刻”的负载和用户状态。要监控变化建议配合watch或定时执行而不是只看一次。4. top实时进程监控的常青命令4.1 top 界面关键区域top启动后默认全屏刷新界面分成上下两部分。上半部分是系统汇总第一行当前时间、系统运行时间、用户数、负载和w第一行内容一致。第二行Tasks显示总任务数、正在运行、睡眠、停止、僵尸任务数量。第三行%Cpu(s)显示 us用户态、sy内核态、ni调整过优先级的用户态、id空闲、wa等待 IO、hi硬中断、si软中断、st被偷走的时间。第四、五行内存和 swap 的使用情况。下半部分是进程列表PID USER PR NI VIRT RES SHR S %CPU %MEM TIME COMMANDPID进程号。USER运行用户。PR优先级。NInice 值。VIRT虚拟内存总量。RES常驻物理内存。SHR共享内存。S进程状态。%CPUCPU 占用率。%MEM内存占用率。TIME累计 CPU 时间。COMMAND进程命令。新手最容易误解的是%CPU。超过 100% 不是 bug而是这个进程有多个线程在多个逻辑 CPU 上并行计算。比如 8 核机器上某个进程跑了 4 个线程%CPU可能显示 400%。这里要看的是它有没有把你期望的核数吃满而不是被 100% 这个数字吓到。4.2 top 交互操作和常用参数top支持很多交互键优先级最高的是这几个按1切换显示每个逻辑 CPU 的使用情况。按P按 CPU 占用率排序。按M按内存占用排序。按T按累计 CPU 时间排序适合找长时间消耗资源的进程。按c切换显示完整命令行。按u输入用户名只看该用户进程。按k输入 PID 发送信号可退出进程。按q退出。常用参数top -d 2 top -p 1234 top -H -p 1234 top -bn1top -d 2每 2 秒刷新一次默认是 3 秒。top -p 1234只监控指定 PID。top -H -p 1234以线程模式查看指定进程排查多线程应用卡死时很有用。top -bn1批处理模式只输出一次后退出适合脚本采集。4.3 用 top 定位 CPU 或内存异常系统卡顿时先看汇总行的负载再看%Cpu(s)如果us很高说明用户态计算密集找进程列表里%CPU最高的那个。如果wa很高说明 CPU 在等磁盘 IO。这时候高 CPU 进程不一定真有计算任务更多是磁盘读写慢需要结合iostat或iotop进一步看磁盘。如果si很高说明系统在不断进行 swap 换入换出内存压力已经很大。如果st很高说明这台机器可能是虚拟机宿主机资源竞争严重Guest 内部能做的优化有限。进程列表里看S状态列如果出现大量D状态不可中断睡眠通常和磁盘 IO 有关出现大量Z状态僵尸进程说明父进程没有回收子进程需要重点排查父进程。5. free查看内存是否真的不够5.1 free 输出里的关键字段free -h的输出比较直观total used free shared buff/cache available Mem: 31G 10G 8.2G 300M 13G 20G Swap: 8.0G 0B 8.0Gtotal物理内存总量。used系统认为已使用的内存。free完全没有被使用的内存。shared临时文件系统等共享内存通常不用太关注。buff/cache用于缓冲和缓存的内存内核可以回收。available估算出的、在不触发 swap 的前提下还可以分配给新程序的内存。这里最容易犯的错是只看free。很多 Linux 机器运行一段时间后free会非常小但available很大因为大量内存被内核用作文件缓存。这些缓存可以随时回收所以系统并不会因为free小而出问题。判断内存是否充足核心看available。常用参数free -h人类可读格式推荐优先使用。free -m以 MB 为单位适合脚本解析。free -s 3 -c 5每 3 秒输出一次最多输出 5 次。free默认单位 KB阅读不直观生产上很少直接裸跑。5.2 用 available 判断而不是 free判断思路可以这样定available持续接近 total 的 10% 以下内存压力较大。available一度很多但业务高峰期明显下降需要看是不是缓存策略导致。swap 长期为 0说明内存还没到需要交换的程度。swap 使用率持续增长说明物理内存可能一直不够。如果想把free用在巡检脚本里建议直接取 available。下面是一个简单示例free -h | awk /^Mem:/ {print 可用内存: $7}这里$7对应 available 列。不同发行版输出可能有差异建议先在本机跑一次确认列位置。5.3 swap 与内存不足的关系swap 是磁盘上的一块空间用来临时存放不常用的内存页。当物理内存不够时内核会把部分数据从内存交换到 swap。代价是磁盘速度远低于内存所以程序一旦大量读回 swap性能会下降得很明显。有些人遇到内存紧张就执行echo 3 /proc/sys/vm/drop_caches这个命令会清理页缓存、目录项和 inode 缓存。我不建议把它当成日常操作。因为缓存清理后虽然free数字变大了但文件系统读取性能会下降而且这是临时手段不能解决真正的内存不足问题。真正需要做的是先看available和 swap 趋势再定位哪个进程占用高top按M排序或者用ps aux --sort-%mem | head -n 15。注意Linux 内存优化逻辑和 Windows 完全不同。free小、buff/cache大大多数时候是正常状态不要一看到缓存就手动清理。6. df磁盘占用和 inode 检查6.1 df -h 输出和最常用的场景df -h是最常用的磁盘查看命令Filesystem Size Used Avail Use% Mounted on /dev/sda3 98G 55G 38G 60% / tmpfs 3.1G 0 3.1G 0% /dev/shmFilesystem文件系统设备或伪文件系统。Size分区总大小。Used已使用空间。Avail可用空间。Use%使用百分比。Mounted on挂载点。需要先看挂载点再判断是哪个分区出问题。比如根分区/满和/home满影响范围完全不同。如果业务数据在/data那你更应该关注/data对应的 Filesystem而不是只看根分区。df -T可以额外显示文件系统类型比如 ext4、xfs、overlay。容器场景经常能看到 overlay 文件系统容量来自宿主机的分区处理方式要结合宿主机来看。6.2 df -i 处理 inode 打满的问题很多人会忽略df -idf -i输出类似Filesystem Inodes IUsed IFree IUse% Mounted on /dev/sda3 6553600 6540000 13600 100% /这里显示的是 inode 使用情况。inode 是文件系统用来记录文件元数据的索引单元。每个文件或目录至少占用一个 inode。即使磁盘容量还有空间如果 inode 用完系统仍然无法创建新文件。常见触发场景是小文件特别多比如邮件队列、消息队列、临时缓存、解压大量小文件。遇到“写不进文件但 df -h 还有空间”时一定要跑一下df -i。如果IUse%达到 100%就需要清理旧文件或者把数据迁移到支持更多 inode 的文件系统。6.3 磁盘满后的定位思路磁盘满之后系统会出现各种症状日志写不进去、服务启动失败、用户无法登录、数据库异常。定位时按顺序做df -h看哪个挂载点满。df -i排除 inode 满。du -h -d 2 /路径或du -sh /路径/* | sort -hr | head -n 20找大目录。看日志目录比如/var/log通常最容易占满。如果删除了大文件后空间没有释放用lsof | grep deleted查看是否有进程持有已删除文件的句柄。这种情况需要重启该进程或正确处理文件释放。清理日志不要直接删正在写入的日志文件否则进程仍然持有句柄空间不会释放。更稳妥的做法是把日志文件清空或者先判断日志策略再处理。7. 组合使用一套负载到磁盘的排查顺序7.1 遇到机器变慢时的标准顺序我这里给一套我自己常用的排查顺序基本能覆盖大部分普通 Linux 服务器问题# 1. 当前负载和登录情况 w # 2. CPU 核数和型号 lscpu # 3. 动态进程资源和 CPU 状态 top -bn1 -o %CPU | head -n 30 # 4. 内存可用量 free -h # 5. 磁盘容量和 inode df -h df -i不要一次性同时跑一堆命令而是先看每一步结果再决定下一步怎么走。比如第一步w显示负载是 12第二步lscpu显示CPU(s)是 4那系统基本已经过载。接着用top找占用 CPU 最高的进程再配合free和df看是不是内存或磁盘问题。如果第一步w显示负载很低但客户反馈访问慢那就要偏重网络层、应用层比如端到端延迟、数据库连接数、后端服务日志而不是继续纠结内存和磁盘。7.2 容易误判的几个点这部分我踩过不少坑总结成几个高频误判点负载高不等于 CPU 高。负载包含任务排队可能是因为 IO 等待。只看 CPU 使用率会漏掉磁盘问题。free字段小不等于内存不足。必须看available否则容易做无用的缓存清理。top 中%CPU超过 100% 不代表异常可能是多线程并行要结合进程的线程数判断。df -h正常不代表可以创建文件。小文件多的时候df -i可能已经 100%。lscpu不显示型号不代表没有 CPU 信息常见于虚拟化环境核数和架构通常仍可读。这些误判的共同点是先入为主地认为命令输出中某个字面数字异常却忽略了它所在的上下文。7.3 给脚本采集留的参考做巡检脚本时有时候不需要完整界面输出只需要关键指标。可以这样采集lscpu | grep -E ^CPU\(s\)|Model name uptime top -bn1 | head -n 5 free -m df -h / df -i /如果要把输出保存到日志建议每条命令前带上下一次时间戳。比如echo $(date %Y-%m-%d %H:%M:%S) uptime free -m df -h脚本采集和人工排查最大的区别是脚本看重稳定输出人工看重异常判断。不要只搜命令参数而是先搞清楚每个字段在什么情况下是正常值。这几个命令不是学一遍就行的。真正能帮你的是把每次输出和业务场景对应起来大文件导出时 CPU 高不奇怪数据库启动时内存波动也正常。我自己的习惯是先固定一套排查顺序再按任务需求补参数。先学会看字段再理解场景最后把命令变成肌肉记忆。 
