Linux 服务器故障急救指南:CPU、内存、磁盘满员怎么办?

📅 发布时间:2026/7/8 0:23:07 👁️ 浏览次数:
Linux 服务器故障急救指南:CPU、内存、磁盘满员怎么办?
做测试的兄弟们肯定都遇到过刚才还好好的接口突然超时报错测试环境突然像死机一样命令都敲不动。这时候别慌不用马上喊运维用这套“急救”命令清单3分钟快速定位是代码Bug还是资源耗尽。作为测试工程师掌握这套排查逻辑不仅能提交更有说服力的Bug报告关键时刻还能帮你“救火”。 场景一系统像死机一样卡顿CPU 飙升 100%症状速写命令延迟极高网页打不开输入完回车半天没反应。第一步用top找出“捣乱分子”直接输入top你会看到如下动态视图简化示意top - 11:30:00 up 10 days, 1:20, 3 users, load average: 2.45, 2.10, 1.95 Tasks: 120 total, 2 running, 118 sleeping, 0 stopped, 0 zombie %Cpu(s): 85.0 us, 10.0 sy, 0.0 ni, 5.0 id, 0.0 wa, 0.0 hi, 0.0 si MiB Mem: 8000.0 total, 1000.0 free, 6000.0 used, 1000.0 buff/cache PID USER PR NI VIRT RES SHR S %CPU %MEM TIME COMMAND 1234 root 20 0 400000 350000 5000 R 80.5 4.3 0:15.30 java - 罪魁祸首 5678 deploy 20 0 120000 50000 2000 S 5.0 0.6 0:02.10 nginx 如何看看第一行load average如果数字超过CPU核心数说明负载很重。看%Cpu(s)us用户空间高 ➜程序死循环或计算密集。wa等待I/O高 ➜硬盘读写瓶颈CPU在干等。操作按键盘P大写可以让进程按 CPU 使用率排序。记下第一位的PID比如上面的 1234。第二步查户口它是谁拿到 PID还不知道它是哪个服务用ps确认# -ef 显示所有进程| grep 管道过滤ps-ef|grep1234输出示例root 1234 1 99 11:25 pts/0 00:03:15 java -jar /opt/app/backend.jar这就知道了是/opt/app/backend.jar这个 Java 服务在抽风。 场景二服务被莫名杀掉越来越慢内存溢出 OOM症状速写程序运行一段时间后突然消失或者系统极慢甚至鼠标都动不了。第一步看内存余额free不要只凭感觉直接看数据free-h输出示例total used free shared buff/cache available Mem: 7.7Gi 6.5Gi 200Mi 1.0Mi 1.0Gi 500Mi - 注意这列 Swap: 2.0Gi 1.5Gi 500Mi 如何看看available这是真正能用的内存。如果接近 0系统极度危险。看Swap如果used变大比如这里用了 1.5G说明物理内存不够用被迫把数据搬到了硬盘。这会导致性能呈指数级下降。第二步揪出内存大户还是用top这次按M大写按内存排序。或者使用这条命令直接找出 Top 5 的贪吃蛇ps-aux --sort-%mem|head-n5可视化排查思路否是是系统变慢内存可用吗?查看进程排序发现某进程占用异常高重启服务/限制堆内存检查Swap是否占用物理内存泄漏/不够用 场景三报错“No space left on device”磁盘满了症状速写无法写入日志程序报错退出但用df查看好像还有空间可能是 Inode 满了。第一步宏观检查dfdf-h输出示例Filesystem Size Used Avail Use% Mounted on /dev/sda1 40G 38G 2G 95% / - 危险根目录满了 /dev/sdb1 200G 50G 150G 25% /data第二步精确打击du知道/目录满了但不知道是哪个子目录搞的鬼一层层剥洋葱# 查看根目录下一级文件夹大小并排序du-h --max-depth1/|sort-hr输出示例3.5G /var/log - 罪魁祸首 2.0G /usr 1.5G /opt ...发现/var/log占用最大进去再执行du -h --max-depth1 /var/log就能定位到具体的日志文件。第三步查隐形杀手 Inode如果df -h显示Use%正常但依然报错磁盘满请检查 Inode文件节点数df-i输出示例Filesystem Inodes IUsed IFree IUse% Mounted on /dev/sda1 262144 262100 44 100% / - IUse% 100%说明小文件太多撑爆了 总结急救速查卡建议收藏这张表贴在工位旁故障发生时照着敲故障现象核心排查命令关键指标解决思路CPU 飙升top(按P)%us 80% 或load高找到对应PID排查死循环代码内存溢出free -havailable接近 0找内存占用最高的进程检查配置Swap 飙升vmstat 2si/so频繁变动说明物理内存不足需加内存或优化磁盘满df -h/du -shUse% 100%清理日志文件或临时文件Inode 满df -iIUse% 100%清理海量小文件如session碎片写在最后学会这些命令我们测试就不再是黑盒测试的“点点点”机器而是具备了白盒排查能力的工程师。下次环境再挂先把这串命令跑一遍截图甩给开发绝对是Bug定级的最强证据