内存过度分配导致拒绝服务的本质是available内存趋近于零并触发OOM killer，表现为服务卡死、进程被杀等；排查需聚焦available和swap使用量、定位高RES进程、检查dmesg中的OOM日志及内核内存泄漏。
内存过度分配引发的拒绝服务，本质是系统资源耗尽后无法响应新请求，常见表现为服务卡死、进程被杀、SSH 登录失败或 HTTP 503。这不是单纯的“内存用得多”，而是 可用内存（available）持续趋近于零 + OOM killer 被触发 的组合结果。排查要围绕“谁在吃、为什么吃不放、系统怎么应对”三层展开。
看准关键指标：别被 used 和 free 迷惑
运行 free -h，重点只盯两列：
- available：真正能立刻给新进程用的内存。低于 200MB 就危险，接近 0 时服务已濒临瘫痪；
- Swap used：如果 swap 被大量使用（比如 >1.5G），说明物理内存早已不够，系统靠磁盘硬扛，IO 拉满，响应必然卡顿甚至超时。
不要纠结 used 高——Linux 把空闲内存拿来缓存文件是正常行为，buff/cache 占用高反而是好事；只有 available 持续走低，才说明真实资源告急。
锁定肇事进程：按实际占用排序
用 ps aux --sort=-%mem | head -n10 或 top 后按 大写 M，关注三列：
- %MEM：内存占用百分比；
- RES：实际驻留物理内存（KB），比 VSZ 更真实；
- COMMAND：进程名，特别注意 java、python、node、postgres 等易内存膨胀的服务。
若发现某个进程 RES 稳定在 2G+ 且 %MEM >30%，基本就是它在持续吞食内存。再结合启动时间（START 列）和运行时长，判断是否是新上线或配置变更后才出现异常。
查证 OOM 杀手是否已出手
执行 dmesg -T | grep -i "out of memory\|kill process"，查看最近是否有内核级杀进程记录。典型输出如：
这说明系统已无力维持，只能强制终止进程保全整体。同时检查 /var/log/messages 或 /var/log/syslog 中对应时间点的日志，确认被杀进程的 RSS（anon-rss）大小和当时 total-vm，可反推其内存申请行为是否异常激进。
检查深层内存压力源
有些问题不体现在单个进程上，而是内核级资源耗尽：
- 运行
cat /proc/meminfo | grep -i "SUnreclaim\|Shmem\|HugePages"，若 SUnreclaim（不可回收 slab）>500MB，可能内核对象泄漏（如大量 socket、dentry）； - 若 Shmem（共享内存）异常高，检查
ipcs -m，确认是否有未清理的 IPC 共享段； - 若 HugePages_Total 非零但业务不需要大页，可能是配置残留或恶意程序占用，需清理
vm.nr_hugepages并重启生效。
不复杂但容易忽略
