直接看dmesg输出是否有page allocation failure或out of memory关键字，这是最硬证据；挂起前日志中断、syslog停写、ssh卡死但ping通，可锁定为内核级内存分配阻塞。
怎么确认系统挂起是内存分配失败导致的
直接看 dmesg 输出里有没有 page allocation failure 或 Out of memory 关键字，这是最硬的证据。挂起前如果内核日志突然中断、syslog 停止写入、ssh 连接卡死但 ping 仍通，基本可锁定为内核级内存分配阻塞，而非用户态进程崩溃。
为什么 free -h 显示还有内存却挂起
free -h 的 available 值只是估算，不反映连续页可用性。挂起常见于以下情况：
-
MemAvailable看似充足，但/proc/meminfo中PageTables或Slab占用过高（尤其SUnreclaim> 1GB），说明内核对象吃掉大量不可回收内存 - NUMA 架构下某 node 的
MemFree接近 0，而进程被绑在该 node 上，numastat -m可验证 -
DirectMap4k异常膨胀（dmesg | grep DirectMap），表明 page table 消耗过多低地址空间，挤压了内核分配窗口 - 内核参数
vm.min_free_kbytes设置过低，导致 kswapd 来不及回收，vm.zone_reclaim_mode=0时跨 node 分配又受阻
如何快速抓取挂起前的内存现场
挂起后重启会丢失关键状态，必须提前部署轮询采集：
PyCharm 2026.2.0.1 Linux版
下载
PyCharm 2026.2.0.1 Linux版提供 JetBrains 官方 2026.2.0.1 版本安装包，适合需要指定 PyCharm 版本进行 Python 项目开发、运行和调试的用户。
- 用
watch -n 5 'grep -E "MemFree|MemAvailable|Slab|PageTables" /proc/meminfo'持续记录内存分项变化 - 定时执行
grep -r "AnonHugePages" /proc/*/smaps 2>/dev/null | awk '$2 > 5000000' | head -5，捕获大页碎片化苗头 - 检查 cgroup 限制：
find /sys/fs/cgroup/memory -name memory.usage_in_bytes -exec sh -c 'echo {} && cat {}' \;，确认是否局部 OOM - 若使用 systemd，
journalctl -b -o short-monotonic | grep -i "allocation\|oom\|fork"可提取启动后所有相关报错
挂起后从日志里定位根本原因
重启后立即执行以下命令，不要依赖 journalctl -b -1（可能被覆盖）：
-
dmesg -T | grep -A 5 -B 5 "page allocation failure\|Out of memory"，注意时间戳和紧跟其后的order:值（如Order:3表示需 8 个连续页） -
cat /var/log/messages | grep -i "kernel.*unable to allocate"，部分发行版仍写入这里 - 查 pid_max 耗尽：
cat /proc/sys/kernel/pid_max和ps -eLf | wc -l对比，若接近则不是内存问题而是进程数上限 - 检查 swap 状态：
swapon --show和cat /proc/swaps，优先级错配会导致部分 swap 不启用，SwapCached高但SwapFree低就是典型征兆
真正棘手的是那些没有明显 OOM 日志却反复挂起的情况——往往卡在 GFP_ATOMIC 分配路径上，此时 vm.min_free_kbytes 和 NUMA 平衡比加内存更关键。
