Linux 系统资源突然耗尽的预警信号

available 接近 0 就该警觉——它才是真实可用内存，低于总内存10%（如8G机器长期≤800M）表明内核正频繁交换，响应延迟明显；dmesg中“Killed process”即OOM已发生，需查oom_score_adj和RSS定位真凶。

free -h 显示 available 接近 0 就该警觉了

linux 的 free -h 输出中，available 列才是你真正能用的内存——它已扣除内核预留、不可回收缓存等。很多人盯着 free 列看，结果发现“明明还有 200M free，怎么就 OOM 了？”，这就是典型误判。

当 available 持续低于总内存的 10%（比如 8G 机器长期 vmstat 1 5 中的 so（swap out）值若稳定 > 0，说明内核已在拼命把内存页写入磁盘，响应延迟会肉眼可感。

• 别等 Out of memory: Kill process 日志出现才行动——那已是最后防线
• buff/cache 高不等于问题，但若 available 同步走低，说明缓存正在“挤占”可用空间
• 云服务器尤其要注意：某些厂商监控只报 used%，而忽略 available，容易漏掉真实压力

dmesg 看到 “Killed process” 就是 OOM 已发生

一旦进程被内核强制终止，dmesg | grep -i "out of memory" 必定有输出，格式类似：
Out of memory: Kill process 12345 (python) score 892 or sacrifice child。
这里的 score 是内核打的“死亡分数”，越高越可能被杀；python 是进程名，12345 是 PID。

这不是警告，是事故回溯证据。重点不是“谁被杀了”，而是“为什么它得分这么高”——通常因为 RSS（实际物理内存占用）过大，或 /proc//oom_score_adj 被手动调高过。

• 别直接 kill -9 日志里的进程——它大概率只是替罪羊，真凶可能是其子进程或上游服务
• 查完日志立刻执行 ps aux --sort=-%mem | head -5，对比当前活进程和日志里死掉的，看是否同一类应用反复中招
• 如果 systemd、sshd 或数据库主进程出现在日志里，说明系统已濒临瘫痪，需立即人工介入

df -i 显示 IUse% = 100% 时，磁盘“满”得无声无息

磁盘空间没满（df -h 显示 Use% touch 报错 No space left on device？十有八九是 inode 耗尽了。

每个文件、目录、软链接都占一个 inode，小文件多的场景（如日志轮转、git 仓库、容器镜像层）极易触发。用 df -i 查看 IUse%，到 100% 就彻底锁死。

• du --inodes -sh /var/log/* 可快速定位哪个目录塞满了小文件
• 临时解法：清空 /var/log/journal（journalctl --vacuum-size=100M）或删旧日志；长期要配置 logrotate 限制文件数
• 注意：rm 删除后 df -i 不立刻下降——得等持有该 inode 的进程关闭句柄，常见于未重启的 java 服务或长期运行的脚本

lsof | grep delete 发现“幽灵占用”最让人后怕

磁盘空间明明 df -h 显示还剩 20G，du -sh / 却只统计出 5G，差额去哪儿了？大概率是“已删除但未释放”的文件——进程还在读写它，内核不敢回收空间。

执行 lsof | grep delete，输出里带 deleted 字样的行就是元凶。第 7 列是字节数，加起来往往就是那“消失的 15G”。

• 关键字段是 PID 和 COMMAND，用 ps -p -o pid,comm,args 确认进程用途
• 运维最常踩的坑：对 nginx、rsyslog 这类常驻进程，直接 kill -HUP 就能重载并释放已删日志文件句柄，无需重启服务
• 如果是业务进程（如 Python 脚本），得看代码里是否 open() 后忘了 close()，或用了 os.remove() 却没同步清理 file descriptor

资源耗尽从来不是突然发生的，只是信号藏得深：available 持续走低、so 值爬升、IUse% 拉满、lsof 里躺着 deleted 文件……这些都不是“可能出问题”，而是“已经出问题，只是还没爆炸”。盯住它们，比等告警邮件有用得多。