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/ 被手动调高过。
- 别直接
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 文件……这些都不是“可能出问题”，而是“已经出问题，只是还没爆炸”。盯住它们，比等告警邮件有用得多。
