Linux运维场景实践：进程、磁盘、网络、日志与权限排查

接手这套系统也有几年时间了，最烦看那种把几十条命令铺开背一遍的文章。真正到了线上，CPU 突然飙到 90%、磁盘明明删了大文件却还是满、服务半夜自己挂掉，这时候你脑子里能快速调出来并且敢直接敲下去的命令，才是最有价值的。

这一篇“Linux系统运维相关命令实践(二)”延续一贯的实用风格，不系统背命令，而是按真实运维场景来拆。哪些命令能救命，哪些命令容易踩坑，命令跑完之后输出怎么理解，我会尽量讲透。进程管理、磁盘清理、网络排查、日志检索、systemd 服务管理、用户权限这几个方向，基本覆盖了日常遇到的大部分故障类型。适合刚接触 Linux 服务端的同学，也适合已经上岗一段时间、想补强排查思路的运维朋友。

1. 负载飙高时的第一反应：用对命令才能快速锁定元凶

不少刚入行的同事一看到 load average 过 5 就紧张，马上跑去 kill 进程，这个处理顺序其实是反的。负载高不一定只是 CPU 忙，还可能出在 IO 等待、内存换页、进程状态异常这些隐性因素上。你不看指标下判断，很容易误杀业务进程，甚至把正常的批量任务中断掉。

1.1 三个指标看方向，别只看 top 第一行

登录服务器之后，我的习惯是先敲三个命令，每个都只看数秒，再做下一步判断：

bash复制uptime
top -b -n 1 | head -15
vmstat 1 3

第一个命令用来看负载历史趋势。load average 后面三个数字分别是 1 分钟、5 分钟、15 分钟的平均负载。如果 1 分钟明显高于 15 分钟，说明是刚刚突发的；如果三个数字都高，说明持续了一段时间，不可能敲一条命令就恢复，得认真排查。

第二个命令用来确认当前 CPU 使用率的构成。top 输出里需要注意三列：us 用户态占用、sy 内核态占用、wa IO 等待。如果 wa 很高，那么 CPU 其实在等磁盘，单纯扩容 CPU 没有用，要先查日志落盘是不是过猛、磁盘是不是有坏道。

第三个命令我很推荐保留这个习惯。vmstat 1 3 里的 r 表示可运行进程数，b 表示不可中断睡眠进程数，si/so 表示内存交换页。如果 r 长期大于 CPU 核心数，说明确实是计算密集，再看 so 如果持续不为 0，大概率是内存不够导致频繁换页，CPU 大量时间耗在换页上，这种情况就得先加内存而不是加 CPU。

1.2 定位具体进程，用一条组合命令

指标方向确认之后，需要找出是哪一个进程在捣乱。虽然 top 交互界面按一下大写 P 可以按 CPU 排序，但在故障现场我更习惯直接输出一条排序后的快照：

bash复制ps -eo user,pid,ppid,pcpu,pmem,stat,comm --sort=-pcpu | head -20

pcpu 列是按照 CPU 使用率降序排列的，pmem 列可以顺带看内存。这条命令的优势是可以直接记录现场，后续写故障报告、比对历史数据都有依据。

如果进程不固定，一会儿 PID 是 A，过一会儿又被新进程替代，那有可能是脚本或者定时任务在疯狂拉起进程。这时候就得往上查它的父进程 PID。ppid 那一列就是关键线索，翻到父进程以后再用 pstree -ap 看父子关系，基本能判断出是谁在背后反复拉起子进程。我遇到过最典型的案例是 crontab 里写了一个死循环脚本，每分钟执行一次，每次都不退出，结果服务器上一堆同名脚本进程，负载直接被拖爆。

1.3 遇到 D 状态进程，先别急着 kill

ps 输出里的 STAT 列如果显示 D，代表进程处于不可中断睡眠状态，绝大多数情形是在等磁盘 IO 返回。这种状态有个特点，你发 kill -9 给它，它也可能一直杀不掉，因为内核在等待底层 IO 完成，进程根本不会响应信号。

碰到 D 状态进程大量堆积，正确思路是顺着 wa 指标往下查。可以用 iostat -x 1 3 看磁盘的 %util 和 await，%util 到 100%、await 超过几百毫秒，基本坐实 IO 瓶颈。再往下就是看哪块盘在忙、是不是有云盘因为快照或备份被拖慢。这类问题多半要靠扩容、迁移或优化读写模式解决，而不是靠结束进程解决。

1.4 顺手记录故障现场，别等复盘时抓瞎

每当服务器异常，我会先把以下信息存到临时文件：

bash复制date > /tmp/fault_time.txt
uptime >> /tmp/fault_time.txt
ps -eo pid,ppid,pcpu,pmem,stat,comm --sort=-pcpu | head -30 >> /tmp/fault_time.txt
ss -antp >> /tmp/fault_time.txt 

等恢复之后，这些记录就是排查报告的原始素材。很多时候你当时觉得能记住，但连续处理两个故障后记忆就混淆了，有一个只读快照，后续复盘效率会高很多。

2. 磁盘明明删了文件却不释放空间：找到隐藏的句柄才是关键

磁盘运维大概是日常工单里最频繁的一类。真正有坑的不是“空间满”本身，而是“删了大文件之后空间还是满”。很多初级运维在这个问题前会反复执行 rm -f，越删越怀疑人生，最后发现是文件被运行中的进程占用着，目录里看不到了，但空间一直被占住。

2.1 先用 du 找到真正的大目录

排查磁盘空间，第一步永远是确认是哪个分区满了：

bash复制df -h

然后顺着挂载点