一、紧急处理：快速释放内存
1、通过ssh连接服务器，结束高内存；
top -o %MEM
kill -9 PID
2.清理缓存与临时文件
echo 3 > /proc/sys/vm/drop_caches #释放页缓存、denies等
rm -rf /tmp/* (谨慎清理临时文件)
二、深度排查：
安装apt install atop或yum install atop
查看历史：atop -r atop_日期
2.检查oom记录（内存溢出）
dmesg | grep -i "out of memory" #查看内核OOM日志
cat /var/log/messages | grep -i "oom"或grep -i "oom" /var/log/messages
三、docker容器通过--memory参数限制
docker run --memory=2g <image>
docker update --oom-score-adj=-1000 <container>
2.系统优化参数
echo 10 > /proc/sys/vm/overcommit_memory 允许内存超额分配
sysctl -w vm.swappiness=10 减少交换空间使用
配置日志轮转：编辑/etc/logrotate.conf,限制日志文件大小
================================================
立即排查步骤
一、检查系统日志
以下命令，查找OOM发生的详细记录和具体哪个进程被终止了
grep -i "oom" /var/log/messages
dmesg | grep -i "out of memory"
确认当前内存状态
使用 free -h 和 top 命令，查看内存和交换空间的使用情况，以及当前占用内存资源最多的进程。
根本原因与解决方案
导致OOM的常见原因及对策：
二、应用程序内存泄漏
排查：重点观察在 top 或 ps 命令中，是否有进程的 RES (常驻内存) 值在持续增长且不释放。
解决：修复代码中的内存泄漏问题；对于Java应用，可使用 jmap 生成堆转储文件进行分析
1.Slab内存占用过高
排查：执行 cat /proc/meminfo | grep -i slab，如果 Slab 值异常高，则可能是内核对象（如 dentry 缓存）占用了大量内存
2.临时解决：可以尝试手动清理Slab缓存（需root权限）：
echo 2 > /proc/sys/vm/drop_caches
注意：此操作会清空内核缓存（如目录项缓存），可能导致系统性能短暂下降，但能快速释放内存。
三、系统配置与优化
调整Overcommit策略：在 /proc/sys/vm/overcommit_memory 中，将其设置为 2 可以完全禁用overcommit，从而在一定程度上避免OOM的发生，但这可能会使一些需要大量分配虚拟内存的程序（如Java）启动失败。
调整特定进程的OOM优先级：通过修改 /proc/<PID>/oom_score_adj 文件（例如，将其设为 -1000 来保护关键进程）
硬件资源不足
如果应用本身的内存需求就很大，那么最直接的解决方案就是增加服务器的物理内存。