Flood Sung你有没有遇到过这种场景：线上服务突然告警，CPU 使用率飙到 100%，或者某个端口死活连不上，又或者磁盘空间被某个神秘大文件占满，你打开终端却愣了几秒，不知道该先敲哪条命令。我干 Linux 运维和日常开发调试这么多年，发现一个很朴素的道理：排查故障的快慢，不取决于你背了多少命令，而取决于你脑子里有没有一条清晰的排查主线，以及手上有没有一套顺手、够用的命令工具箱。这篇文章想结合我自己的实操经验，把 Linux 故障排查中最常用的一批命令按场景重新梳理一遍，标题虽然是 "Top 100"，但我不想给你堆一个没头没尾的列表，而是按“先看什么、再看什么、最后看什么”的思路，把命令串成一套能直接拿去用的排查流程。无论你是刚入门的小白，还是已经写过一些脚本的开发者，这篇文章都能帮你把排查思路理得更顺。
1. 先想清楚再敲命令：故障排查的正确姿势
很多新手拿到一台出问题的机器，第一反应是随便敲几条命令碰运气，比如 free -h 看一下内存、df -h 看一下磁盘，然后就没有然后了。这种操作不是不行，但效率极低。我自己的经验是，排查任何问题之前，先花 30 秒回答三个问题：这是什么类型的故障，影响范围有多大，最近发生了什么变更。这三个问题决定了你接下来的排查方向。
1.1 从症状到根因的排查流程
故障排查本质上是一个“缩小范围”的过程。比如你发现服务连不上，可能的环节包括：网络不通、DNS 解析失败、端口没监听、防火墙拦截、服务进程崩溃、资源耗尽等。一条链路十几个环节，不可能挨个试，所以要先通过现象做粗筛。
我习惯把排查分成四层：第一层是资源层，确认 CPU、内存、磁盘、网络这些基础资源是否正常；第二层是进程与服务层，确认相关进程是否存活、状态是否健康；第三层是日志层，从系统日志、应用日志里找异常；第四层才是深挖层，比如抓包、性能分析、内核参数调整。每一层都有对应的一批命令，但使用顺序并不是固定的，而是根据症状特征来选择。
举个例子，如果网站打开很慢，我会先看 top 和 uptime，确认是不是 CPU 或负载的问题；再 free -h 看内存；然后 df -h 看磁盘；这几条都正常的话，再去看网络、看日志。这样做的好处是，绝大部分基础设施层面的问题都能在几分钟内定位到大致方向，而不是像无头苍蝇一样乱撞。
1.2 命令清单的分类逻辑与使用思路
既然要整理一份 "Top 100" 级别的命令清单，就必须先给命令分类。我按实际故障排查场景把命令分成六大类：系统信息与硬件状态、进程与服务管理、网络诊断、日志分析、文件与权限排查、性能分析。每一类在特定故障场景下各有侧重，但很多命令是交叉的，比如 lsof 既可以在网络排查里用，也可以在文件权限排查里用。
还要提醒一点：命令多不代表都要记下来。你需要掌握的，其实是每个类目下最核心的十几条，再配合 man、--help 和 apropos 这些自带的“查询命令”，这样即使遇到没见过的命令，也能快速搞懂用法。我从来不去硬背参数，常年用的其实就那么几十条，剩下的都是现查现用。这篇文章里我会把使用频率最高、最不容易出错的用法整理出来，尽量给到可以直接抄走的格式。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 系统信息与硬件状态类命令
排障第一步，往往要先确认这台机器“是什么状态”。很多人上来就查应用日志，结果查了半天才发现是机器负载已经爆了，白白浪费时间。所以先把系统基础状态的命令摸清楚。
2.1 快速确认系统身份与当前状态
uname -a 是查看内核版本、主机名、硬件架构最快的方式，比如你要确认内核是不是太老、是不是 32 位架构，这条命令一眼就能看出来。hostnamectl 在 systemd 系统上更好用，能同时看到操作系统版本、内核版本、机器 ID，在排查“不同机器环境差异”时特别有用。
uptime 看系统运行时间和平均负载，这个命令输出的 load average 有三个数值，分别是 1 分钟、5 分钟、15 分钟的平均负载。我个人的判断经验是：如果 1 分钟负载明显高于 15 分钟负载，说明系统正在经历一个短期的负载高峰；如果三个数值都很高，说明问题已经持续了一段时间，这时候需要进一步用 top 定位到底是哪个进程在消耗资源。
bash复制uname -a
hostnamectl
uptime
cat /etc/os-release
cat /etc/os-release 在确认发行版版本号时很常用，尤其是不同发行版的包管理器不同、默认日志路径不同，先确认系统版本可以避免很多误操作。date 和 timedatectl 也值得关注，因为时间不同步会导致日志定位错乱、证书校验失败、分布式系统协调出问题等。我曾经排查过一次“服务间歇性不可用”，最后发现是多台机器时间偏差了十几秒导致的，排查过程相当曲折，所以现在每到一台新机器我都会顺手看一眼时间。
2.2 CPU 与内存：先看整体，再查细分
top 是看全局状态的首选命令。它能在同一屏里显示负载、CPU 使用率、内存使用、以及按 CPU 占用排序的进程列表。我第一次用它的时候觉得信息太密，其实只需要关注几点：最上面的 load average、%Cpu(s) 那一行的 us（用户态）、sy（内核态）、wa（I/O 等待）、id（空闲），以及进程列表里排在最前面的几个进程。
free -h 查看内存使用情况时，很多人只盯着 used 那一列，其实更应该关注的是 available，这个值才是估算系统还有多少可用内存的参考。Linux 的内存机制会把空闲内存用作 cache，所以 free 命令里 used 大并不代表内存紧张，available 小才是真正紧张。
bash复制top
free -h
vmstat 1 5
mpstat -P ALL 1 3
vmstat 是一个很容易被低估的命令。它每秒输出一行的方式，能连续观察 CPU 运行队列、内存换页、I/O 读写的实时变化。比如你看到 r 列（运行队列）长期大于 CPU 核数，说明 CPU 已经饱和；si 和 so 列如果持续非零，说明内存在频繁换入换出，这时候就该考虑加内存或优化应用了。
mpstat -P ALL 在排查多核 CPU 问题时非常有用，它能分别显示每个 CPU 核心的使用率。之前我排查过一个性能问题，整体 CPU 使用率才 50%，但业务就是卡顿，用 mpstat 一看，发现是某个线程被拼命调度到一个核上，导致单核跑满了，多核没有均衡负载。
2.3 磁盘与文件系统状态
df -h 和 df -i 是我每天都会用到的命令。df -h 看磁盘空间，df -i 看 inode 使用情况。这里有一个很经典的坑：磁盘空间明明还有剩余，但创建文件时报“No space left on device”，这种情况十有八九是 inode 被耗尽了。因为大量小文件会消耗 inode，而 inode 数量在格式化时就固定了，不能像磁盘空间一样动态扩展。
du -sh * 是在某个目录下快速统计各个子目录占用空间的常用命令，适合用来找“谁吃掉了磁盘空间”。排查时可以配合 du -h --max-depth=1 /path 这种写法，只显示一层目录大小，避免输出过多。lsblk 查看块设备树形结构，能一眼看清分区、挂载点、容量之间的关系。blkid 则用于查看分区的 UUID 和文件系统类型，在配置 fstab 挂载时尤其有用。
bash复制df -hT
df -i
du -sh /var/log/*
lsblk -f
mount | column -t
还有一个很容易被忽略的命令是 find，它可以按大小搜索文件。比如磁盘满时，用 find / -xdev -size +1G -exec ls -lh {} \; 能找出所有超过 1GB 的大文件。注意这里的 -xdev 参数很关键，它限定只在当前文件系统查找，不会跑到其他挂载点去，效率会高很多。
2.4 硬件与内核日志的初步判断
dmesg 是一条经常被遗忘但价值极高的命令，它输出内核环形缓冲区里的消息，记录了硬件识别、驱动加载、磁盘错误、OOM 杀进程等关键事件。比如你发现某个进程突然消失了，dmesg | tail -n 50 可能会看到 Out of memory: Kill process 或者 segfault 之类的记录，这是定位问题的第一手线索。
bash复制dmesg -T | tail -n 50
dmesg -T | grep -i error
lspci -nnk
lsusb
lspci 可以查看 PCI 设备列表，在排查网卡、显卡、NVMe 硬盘是否被系统识别时很有用。lsusb 则看 USB 设备。这两个命令都建议加上 -v 或者 -nn 选项，可以显示设备和驱动的详细信息。比如 lspci -nnk 会顺便显示内核驱动的使用情况，对判断“驱动没加载”这类问题帮助很大。
另外，lscpu 可以快速查 CPU 的型号、核数、架构、虚拟化支持等，在确认“机器规格是否符合预期”时比 cat /proc/cpuinfo 的输出更友好。
3. 进程、服务与日志诊断命令
系统资源正常情况下，就要把目光聚焦到进程和服务上。这一块是故障排查中操作最频繁的部分，也是命令组合最多样的部分。
3.1 进程查找与状态判断
ps 命令是进程排查的基础，但 ps aux 这个组合我用了很多年，它几乎能一次给出所有需要的信息：用户、PID、CPU 占用、内存占用、启动时间、终端、命令行。要动态观察进程状态，可以用 top -p PID 单独盯一个进程。
bash复制ps aux --sort=-%cpu | head -n 10
ps aux --sort=-%mem | head -n 10
pgrep -af java
pidof nginx
pgrep 按名字查找进程比 ps | grep 更干净，pgrep -af 可以显示完整命令行。pidof 直接返回 PID，适合在脚本里使用，比如 kill $(pidof nginx)。pstree -ap 可以查看进程树，在排查“父子进程关系”“僵死进程”“守护进程重启逻辑”时特别直观。比如你发现某个服务进程被反复拉起，用 pstree 一眼就能看出负责拉起的父进程是谁，顺藤摸瓜找到原因。
这里要特别提一下进程状态，ps aux 输出的 STAT 列，常见的 Z 是僵尸进程，D 是不可中断的睡眠状态（通常是 I/O 阻塞）。如果你看到大量 D 状态的进程，大概率是磁盘或者网络 I/O 出了严重问题，这时候排查重点应该放在存储和网络层，而不是去杀进程，因为 D 状态的进程是杀不掉的。
3.2 实时动态监控与进程干预
top 是最通用的实时监控工具，但它的交互命令很多人没怎么用过。按 1 可以展开每个 CPU 核的使用情况，按 P 按 CPU 排序、按 M 按内存排序、按 T 按运行时间排序，这些在排障时都很实用。htop 如果有装的话体验更好，支持直接鼠标操作、树状显示、颜色高亮，但生产服务器没装也没有关系，top 够用。
bash复制top -Hp PID
kill -9 PID
kill -TERM PID
renice -n -5 -p PID
排查线程问题时，top -Hp PID 可以查看某个进程内部的所有线程。要知道 Java 应用之类的多线程程序，频繁的 CPU 占用往往集中在少数几个线程上，先用这个命令找到线程 ID，再配合 jstack 之类的工具把线程堆栈导出来，就能定位到具体的代码块。这个手法在我排查线上 Java 服务 CPU 飙高的问题时，几乎每次都能快速命中。
kill 命令要谨慎使用，默认 kill PID 发的是 TERM 信号，给程序一个优雅退出的机会；kill -9 PID 则是强制终止，会有丢数据或者残留共享内存之类的副作用。所以在生产环境里，我一般先发 TERM 信号等几秒，不行再上 KILL。renice 可以调整进程优先级，适合在“某个进程太吃 CPU，但一时又不能重启”的场景下临时降低它的优先级，把资源让给别的业务。
3.3 systemd 服务诊断三板斧
现在主流发行版都用 systemd 管理服务，所以 systemctl 和 journalctl 是排查服务故障的核心工具。我个人把它们总结为三板斧：查状态、看日志、试重启。
bash复制systemctl status nginx
systemctl list-units --failed
systemctl show nginx -p MainPID,ActiveState
systemctl restart nginx
systemctl status nginx 是一个非常关键的组合命令，它不光显示服务的运行状态，还能直接显示最近几条该服务的日志记录，非常省事。systemctl list-units --failed 能快速罗列所有失败状态的服务，适合在系统刚启动后或者批量服务异常时做初步体检。
systemctl show 可以查看服务的所有配置属性，比如你想确认服务的主进程 PID、是否开机自启、资源限制等，都可以用它来查。做应急处理时，systemctl restart 是小马过河一样的存在——它能快速恢复服务，但也可能掩盖问题真相。我的原则是“先查清楚再重启”，除非是危急到不恢复就要出大事，才先重启再看日志。因为一旦重启，内存里的日志、临时状态、线索都会消失。
3.4 日志分析命令的组合用法
日志是排障时最重要的信息来源，但日志文件的体积往往非常大，所以熟练掌握日志查看命令的组合用法是基本功。
tail -f /var/log/messages 是实时跟踪日志的最常用方式，适合边触发问题边观察输出。tail -n 200 /var/log/syslog 则适合直接看最新的 200 行。less 这种分页工具我特别推荐，因为日志文件动辄几千行甚至几万行，用 less 打开后可以直接用 / 搜索关键字，按 G 跳到最后，按 gg 跳到开头，比 cat 加 grep 效率高很多。
bash复制tail -n 200 /var/log/syslog
less +G /var/log/syslog
grep -i "error" /var/log/syslog | tail -n 50
journalctl -u nginx --since "1 hour ago"
讲到 systemd 系统，就必须说 journalctl。journalctl -u 服务名 可以查看指定服务的日志；journalctl --since "10 min ago" 或 --until 可以按时间范围过滤；journalctl -f 可以实时跟进；journalctl -p err 按日志级别过滤。这些参数组合起来，能让你在几分钟内从海量日志里捞出有用的错误信息。
不过有个坑要提醒：journald 默认的日志大小是有限制的，按 journalctl --disk-usage 可以看到占了多少空间。如果 var/log/journal 没做持久化配置，重启之后旧日志会丢，所以对于需要长期留日志的服务器，建议配置 Storage=persistent。
4. 网络故障排查命令实战
网络可以说是 Linux 排障里最容易出问题、也最考验经验的领域。因为网络链路太长，从网卡、交换机、路由器到 DNS、防火墙、负载均衡，任何一个环节出问题，表现的症状可能都一样：连不上、超时、时好时坏。所以这一块我特别想详细展开。
4.1 连通性诊断：从 ping 到 mtr
ping 虽然基础，但它是网络排查的起点。用 ping -c 4 目标IP 可以测试基本的网络连通性，观察丢包率和延迟。如果 ping 不通，先把 IP 层的问题排除掉；如果通了但应用连不上，再往上层排查。
bash复制ping -c 4 10.0.0.1
ping -c 4 google.com
traceroute -n 8.8.8.8
mtr -n 8.8.8.8
traceroute 是查看数据包经过每一跳路由的经典工具，在判断“卡在哪一跳”时很有效。mtr 更好用，它结合了 ping 和 traceroute 的功能，能持续显示每一跳的丢包率和延迟。我第一次用 mtr 排查一个跨地域访问很慢的问题时，很快就发现某个中间节点丢包率高达 30%，省去了大量猜来猜去的时间。
不过用这两个工具时要注意：不少云厂商和运营商节点会主动丢弃 ICMP 包，导致 traceroute 显示 * * *，但这并不代表链路一定断了，还需要结合其他验证方式确认。
4.2 端口与服务连接状态排查
排查端口问题时，ss 是首选命令，它是 netstat 的现代替代品，输出更快、信息更全。ss -lntp 可以查看所有监听中的 TCP 端口以及对应的进程；ss -antp 可以查看所有 TCP 连接的状态、对端地址和进程。
bash复制ss -lntp
ss -antp | grep :3306
netstat -lntp
lsof -i :8080
一个非常经典的场景是：你把某个服务启动后，发现端口没有被监听，或者端口被其他进程占用了。这时候用 ss -lntp 一看便知。lsof -i :8080 在定位“端口被谁占用”这个问题时特别好用，它直接显示占用该端口的进程 PID 和名字，省得再去 ps 里猜。
不过要提醒的是，ss 的输出里状态有很多种，比如 LISTEN、ESTABLISHED、SYN_SENT、TIME_WAIT、CLOSE_WAIT 等。如果看到大量 TIME_WAIT 连接，这是 TCP 正常回收机制的表现，通常不必惊慌；但如果 CLOSE_WAIT 数量持续涨，说明程序没有正确关闭连接，这往往是代码层面的问题，需要去查应用。
4.3 DNS 解析问题排查
很多“连不上”的问题，最后排查下来是 DNS 解析失败。dig 是排查 DNS 中最有力的命令工具，dig 加域名就可以看到解析结果、查询耗时、DNS 服务器地址等详细内容。nslookup 是一种更简单的查询方式，输出可能更易懂；不过我的日常建议是只用 dig 就够了。
bash复制dig example.com
dig @8.8.8.8 example.com
nslookup example.com
cat /etc/resolv.conf
有一次一个网站时好时坏，我用 dig 一查发现解析结果出来的 IP 一会儿是 A 井一会儿是 B 井，再继续查下去发现是对端 DNS 配置不一致导致的轮询异常。所以说在查网络问题时，先确认域名解析是不是正确，能少走很多弯路。getent hosts 域名 也是一个有用的命令，它走的是系统级 NSS 解析流程，比 dig 更贴近应用真实看到的结果。
4.4 抓包与临时端口测试
当网络问题到了“应用层探测都正常但业务却不通”的阶段，就需要抓包了。tcpdump 是命令行抓包的标配，它能按协议、端口、主机、方向过滤，还能把包保存成 pcap 文件供后续分析。但这个命令需要 root 权限，而且抓包本身有一定性能开销，生产环境慎用但必要。
bash复制tcpdump -i eth0 -nn port 8080
tcpdump -i any -n host 10.0.0.2
nc -vz 10.0.0.2 8080
nc -lvnp 9000
nc（netcat）是另一个非常灵活的工具。nc -vz 目标IP 端口 可以快速测试某个端口是否能连通；nc -lvnp 端口 可以在本机临时监听一个端口，用于测试防火墙规则、模拟服务等。我经常用 nc 来临时开一个端口，然后验证防火墙策略是不是已经把不该放的端口都挡住了。
抓包分析有一个很实用的思路：如果在应用层看到连接被重置（RST），但 Ping 通、端口也开着，那大概率是防火墙或者中间设备做了拦截。抓包看到握手包发出去了，但对面不回 SYN-ACK，则可能是对端服务根本没在工作。只要顺着包的流向看，很多问题都能找到线索。
4.5 路由、IP 与防火墙的控制项
ip addr 和 ip route 是查看 IP 和路由表的标准命令。ip addr show 可以确认网卡是否启用、IPv4/IPv6 地址是否正确；ip route 则查看默认网关和路由规则。在“机器上不了网”的场景里，很大概率是网关配置错误或者路由表缺失。
bash复制ip addr show
ip route show
ip link set eth0 up
iptables -L -n -v --line-numbers
防火墙也是网络排障的重点对象。iptables -L -n -v 可以列出当前所有防火墙规则，并显示每一条规则匹配的包数量。如果发现某条规则计数一直为 0，说明根本没走这条路；如果计数很大但服务还是不通，有可能是规则顺序不对或者策略本身就是放行但后续被拦截。nftables 作为 iptables 的继任者，在较新发行版上用 nft list ruleset 查看规则。
另外，新学一个技巧：很多发行版默认开启 firewalld，实际底层的规则文件分别在 /etc/firewalld/ 目录里，排查时可以直接查看具体 zone 的配置。不过在写博文时我不会展开太多发行版差异，重点是先把 iptables 这类“通用层”讲清楚，具体到系统再去查对应文档。
5. 文件、权限与存储排查命令
文件和权限问题虽然不像网络那么神秘，但也会在关键时刻卡住你。比如磁盘明明有空间，但创建文件失败；比如应用跑不起来，一查日志是 Permission denied；比如某个文件删不掉，因为正在被进程占用。这些问题都有对应的排查命令。
5.1 文件定位与系统目录排查
find 是文件查找的首选，功能非常强大。按名称找、按大小找、按时间找、按权限找、按所有者找都可以。我常用的几个组合如下：
bash复制find /var/log -name "*.log" -mtime +7
find / -type f -size +500M -exec ls -lh {} \;
find /tmp -type f -atime +3 -exec rm -rf {} \;
mtime 表示修改时间，atime 是访问时间，ctime 是元数据变更时间，这三个时间在排查“这些文件什么时候变的”时很好用。-exec 后面接命令可以在找到文件后直接执行，比如批量清理旧日志，但是执行 rm 之类的操作一定要先干跑一遍确认文件列表没有偏差。
locate 靠数据库索引查找文件，速度极快，但问题是索引可能不新，新创建的文件查不到，所以它更适合“找我大概知道在哪但一时想不起来”的场景。which 和 whereis 用于查看命令路径，which 看的是 PATH 里的可执行文件，whereis 还可以看源文件、帮助文档的位置。
5.2 权限与属主问题的诊断
遇到权限问题，ls -l 是第一反应，但输出太简略。更详细的权限分析我会用 stat 和 getfacl。stat 可以看到文件的所有者、组、权限模式、访问时间、修改时间、文件大小，甚至 inode 号。getfacl 则显示文件的 ACL 访问控制列表，在排查“为什么权限看起来正常但还是无权访问”时特别有用。
bash复制ls -l /path/to/file
stat /path/to/file
getfacl /path/to/file
id username
groups username
分析权限时，我见过很多新手会忽略 id 命令。其实很多权限问题根本不是文件权限配置错了，而是进程启动的用户不对，或者用户不在某个附加组里。比如你以 www-data 用户身份运行服务，但日志目录的属主是 root，那服务就写不了日志。先用 id 看好当前用户和所属组，再对照文件属主和权限位，问题往往一目了然。
还有一个小技巧：namei -l /path/to/long/nested/dir 可以沿路径逐层显示每一层目录的权限，非常方便查出“到底哪一层目录的 x 权限缺失才导致进不去”。这个命令知道的人不多，但真的能救命。
5.3 文件被占用的典型案例
删除文件时提示“Device or resource busy”是很经典的问题，原因是有进程正在使用这个文件。这时候用 lsof 就能查到是哪个进程占用的：
bash复制lsof /path/to/file
lsof +D /path/to/dir
fuser -v /path/to/file
lsof 是“list open files”的缩写，它可以列出所有打开的文件。lsof +D /某个目录 还可以递归列出该目录下被打开的所有文件。fuser -v 也是一个很直接的命令，它显示占用指定文件或目录的进程 PID 和命令名。在卸载磁盘、删除目录之前，用 fuser -k /path 可以强制杀掉占用该目录的进程，不过要注意这很暴力，操作前先确认清楚。
说实话，我遇到过很多次“磁盘空间满了但找不到大文件”的场景，最后发现是某个进程把一个大文件删除后，空间没有释放。原因在于文件被进程打开，虽然目录项里的文件已经删了，但 inode 仍然被引用，所以 df 看到的空间依然被占用。碰到这种情况，用 lsof | grep deleted 就能找到所有已删除但仍被占用的文件，将对应进程重启或杀掉之后，空间才会真正释放。这是一个非常实用、也非常经典的排查技巧。
6. 四个高频故障场景的命令组合演练
把基础命令都过了一遍之后，最关键的还是要会组合使用。所以我选了四个我在日常工作里遇到频率最高的故障场景，把前面讲到的命令串成一个完整的排查流程，你可以直接照着用。
6.1 场景一：CPU 使用率突然飙高
第一步用 uptime 看负载，如果确认负载高了，立即用 top -c 查看占用 CPU 最高的进程。-c 参数会显示完整的命令行，方便你判断是哪个服务的问题。如果占用高的进程是 Java 或者 Python 应用，再用 top -Hp PID 定位到具体线程，记下线程 ID。
bash复制top -c
top -Hp PID
把线程 ID 从十进制转成十六进制（用 printf %x 线程ID），然后通过 jstack PID | grep -A 20 十六进制线程ID 拿到对应线程的堆栈。这个过程可以帮助我们精确定位到具体代码行。比如前阵子一个数据同步服务 CPU 飙高，按这个流程查下去，发现是一个字符串处理代码在循环里做了大量正则匹配，优化之后 CPU 立刻降下来了。
如果是系统本身的问题，比如内核线程占用高，那就得结合 mpstat -P ALL 看看是不是某个 CPU 核被打满、是否和我们当前分析的目标一致。
6.2 场景二：磁盘空间莫名写满
先用 df -h 看是哪个文件系统满了，再用 df -i 看 inode 是否正常，因为之前提到过 inode 耗尽也会导致写入失败。接着按 du -h --max-depth=1 / 从根目录开始逐层往下看，找到具体是哪个目录占的空间最大。
bash复制df -hT
df -i
du -h --max-depth=1 / 2>/dev/null | sort -hr | head -n 20
定位到大目录之后，再用 find 搜索该目录下的超大文件，比如 find /data -xdev -size +1G -exec ls -lh {} \;。如果找到了大文件但不敢确认能不能删，可以先确认它属于哪个进程：lsof +D /data 查看是否被占用。还有一些特殊情况，比如日志文件被无限增长、临时目录堆积了缓存、数据库 binlog 没清理，这些都需要根据找到的具体内容来判断。
删文件的时候我再提醒一个技巧：先 ls -lh 确认文件大小和类型，再考虑用 truncate -s 0 文件 把文件清零而不是直接删。这种方式可以不影响正在写日志的服务，因为服务持有的是文件句柄，清零之后句柄依然有效，不会导致服务中断。
6.3 场景三：服务端口起不来
我先用 systemctl status 服务名 查看服务状态，如果是 failed，立即看 journalctl -u 服务名 -n 50 获取最近日志。如果服务是运行中但端口没起，确认一下服务是否真的绑定到了你期望的端口：
bash复制ss -lntp | grep 端口号
lsof -i :端口号
如果端口提示被占用，用 lsof -i :端口号 找出占用进程，再决定是杀掉它还是换端口。如果端口没被占用但服务就是起不来，那就要重点看配置文件和防火墙了。配置文件路径错、权限不对、语法错误都很常见，比如 Nginx 的 nginx -t 可以做配置文件的语法测试。防火墙这边用 iptables -L -n 或者 firewalld 对应检查。
这里我想特别强调一个很常见的坑：服务进程监听在 127.0.0.1 上，但外部通过局域网 IP 访问时自然不通。因为你只监听了回环地址，没有监听所有接口。遇到“本机能访问，外部访问不了”的问题，一定要先检查监听地址到底是不是 0.0.0.0。用 ss -lntp 一眼就能看出来。
6.4 场景四：内存占用持续上升
内存持续上涨的根因往往是应用内存泄漏。第一步用 free -h 确认整体内存趋势，再用 top -c 按内存排序找到占用最大的进程。接着用 ps -o pid,ppid,rss,vsz,cmd -p PID 查看重点进程的资源使用情况。RSS 是常驻物理内存，VSZ 是虚拟内存，这两个值结合起来可以判断进程到底吃了多少实际内存。
判断内存是否泄漏，一个比较直接的方法是连续多次采样：间隔 10 秒执行一次 ps 或 top，记录 RSS 的变化。如果某个进程的 RSS 只涨不降，并且随着时间持续走高，那大概率就是内存泄漏了。smem 也是一个好用的工具，因为它能统计进程实际映射的内存（PSS），比 RSS 更准确，尤其是涉及共享库时。不过 smem 不是默认安装的，需要单独装。
确认进程之后，按语言类型去分析：Java 用 jmap -heap PID 看堆内存情况，jstat -gcutil PID 1000 观察 GC 频率；Python 可以用内置的 tracemalloc；C++ 就用 valgrind。生产环境里如果内存已经告急，优先考虑先重启服务应急，同时把堆 dump 下来做离线分析。这也是个老经验：先恢复服务再排查根因，不要因为好奇导致业务长时间中断。
7. 经验心得：排查顺序、常用技巧与避坑指南
命令都讲完了，最后分享一些我踩过坑之后总结出来的心得。这些内容在文档里不太容易看到，但实操中非常管用。
7.1 我习惯的排查顺序
遇到任何一个故障，我现在的排查顺序基本固定下来了：先看资源层（CPU、内存、磁盘、网络基础状态），再看进程层（相关进程是否活着、状态是否正常），接着看日志层（系统日志、应用日志中的异常），最后才做深挖（抓包、性能分析、内核参数）。这个顺序不是绝对的，但能确保我在陷入复杂细节之前，先把最浅显、最常见的问题排除掉。
有一个经验是：在排查的时候，把每一步执行的命令和输出都记录下来。说的难听一点，人脑的记忆并不可靠，尤其当你同时排查多台机器、多个服务的时候。记下关键输出、时间点、改动内容，后面写复盘报告或者别人接手时都能节省大量时间。我习惯用一个临时日志文件，history | tail -n 50 > /tmp/debug-时间戳.log，不需要太正式，但至少要有记录。
7.2 几个容易踩的坑与对应处理
top 里的 CPU 使用率并不完全等同于“负载”，因为有大量进程在等待 I/O 时，CPU 使用率可能不高，但系统却感觉很慢。这时候要用 vmstat 的 wa 列或者 iostat 看 I/O 等待。很多人一看 CPU 不高就以为系统没压力，实际上瓶颈可能完全在磁盘。
另一个常见的坑是 kill -9 之前没有先发 TERM 信号。一些服务在收到 TERM 时会做优雅关闭，把临时文件清理掉，把状态落盘；直接 KILL 可能留下脏数据。我现在除非是进程已经完全无响应，否则一定先给 TERM。
再有一个坑是关于日志的：journalctl 默认不会保留很久的历史日志，具体保留策略看配置。有些服务器日志目录满了，我删了 journal 日志后才发现重启后又自动生成了很多。合理的方式是按 journalctl --vacuum-size=200M 来限制日志大小，而不是直接删文件。
提到删除，还有一个老调重弹的操作：删除文件之前，先确认当前工作目录。不要在 / 目录底下养成随手 rm -rf 的习惯。这条教训是用很多事故换来的，每次执行高危删除命令前，我都会再三核对路径，哪怕多花 10 秒钟也值得。
7.3 一些后续可以继续深挖的方向
这篇文章覆盖了最常用的排查命令，但 Linux 性能分析和故障排查远不止这些。如果你发现自己经常处理性能相关问题，下一步可以学习 perf、bpftrace、eBPF 这一类的动态追踪工具，它们能深入到内核视角观察系统行为；也可以学习 strace、ltrace 来追踪进程的系统调用和库函数调用，定位那些日志里完全看不出来的隐蔽问题。
存储层面可以了解 iostat、iotop、blktrace，或者直接看 /proc/diskstats 和 /sys/block/*/stat 里的原始计数器。网络层面可以继续深入 Wireshark、tshark 这类图形化和命令行抓包分析工具。我自己最近在补的是 eBPF 相关的排查方法，它能做到在不改应用代码的情况下观测到很细粒度的内核事件，对线上排查帮助巨大。
还有一点想建议：每个 Linux 管理员都应该准备一台自己的测试虚拟机，没事就在上面故意制造一些故障（比如占满磁盘、杀关键进程、配错路由），然后用这里的命令去排查。这种“主动制造故障”的练习方式，比看多少篇博客都管用。我在带新人时，经常让他们先干这种事，练的是手感，也是遇到故障时的条件反射。等你能从容地在一个被你自己搞坏的机器上，按图索骥地定位、恢复，再去处理真实的线上问题，心态就会完全不同。
最后再说一个小技巧：善用 man、help、apropos 三个“查命令的命令”。man 看详细文档，--help 看快速用法，apropos 按关键字搜索相关命令。遇到不认识的命令，先 man 或 apropos，再自己上手试，远比死记硬背高效。记住，命令只是工具，真正值钱的是你面对故障时的思路和冷静。希望这篇文章能帮你在下次遇到 Linux 故障时，少一点手忙脚乱，多一点从容。