Linux服务器内存不足排查清单：从free到内存回收的完整处置流程

Linux服务器出现应用频繁被杀、响应卡顿、SWAP占用居高不下时，通常指向内存资源不足。内存问题的排查要按”确认现状→定位进程→区分缓存与泄漏→回收与隔离”的顺序来走，避免一上来就盲目杀进程或重启。本文给出服务器内存不足时可直接套用的排查流程和处置方法。

先用free和vmstat确认内存真实状态

排查第一步，用free -h查看总体内存分布，重点区分buff/cache与真实可用内存：

# free -h
              total        used        free      shared  buff/cache   available
Mem:           31Gi       8.5Gi       1.2Gi       1.1Gi        21Gi        21Gi

available列是当前可分配给新进程的内存估计值，比free列更真实。buff/cache高不等于内存不够，Linux会把空闲内存用于页缓存，压力上来时会自动回收。真正要警惕的指标是available长期在总内存10%以下，或SWAP持续有使用且波动。

# vmstat 1 5，观察si/so列（swap换入/换出）
procs -----------memory---------- ---swap-- ... 
r  b   swpd   free   buff  cache   si   so
2  0  51230  1210  2048  21305   0    0

si/so长期非零，说明物理内存不足，系统在频繁换页，此时优先找占用大户。

用top和ps定位内存占用Top进程

top -o %MEM -n 1   # 按内存占比排序
ps aux --sort=-%mem | head -15

观察两个指标：RES（物理常驻内存）和%MEM。排查时注意区分RSS虚高的情况——多个线程的进程RSS会重复计算共享内存，用smem命令按USS（唯一内存）排序更准确：

# smem -rs uss | head -15
PID User     Command                        Swap      USS      PSS      RSS

如果某个进程的RSS/PSS持续增长且不回落，基本可以锁定为内存增长异常点。

区分”假占用”与真泄漏：观察趋势而不是瞬时值

单次快照不能判断泄漏。正确做法是连续采集时间序列：每5分钟记录一次进程RSS和系统available，持续1-2小时。泄漏的特征是单调上涨、不回落；缓存抖动的特征是随机波动、长期均值稳定。还可以对可疑进程打开其内存快照：

# 采集进程状态（需root权限）
cat /proc/<pid>/status | grep -E "VmRSS|VmSize|VmSwap"

配合jmap（Java）、gcore+dump（原生程序）进一步分析对象分布，Java进程优先用jmap -histo:live查看对象数量异常增长。

SWAP策略调整与内存阈值告警

临时缓解内存压力，可调整系统swappiness降低交换倾向：

sysctl vm.swappiness=10          # 临时生效
echo "vm.swappiness=10" >> /etc/sysctl.conf  # 持久化

防止问题复发，要在监控里加内存指标：available低于阈值（如8%）告警、SWAP使用率持续大于50%告警、Top进程RSS环比上涨告警。实践里最容易被忽略的是容器场景——cgroup内存限制（memory.limit_in_bytes）打满后进程被OOM Kill，此时用docker stats / kubelet日志看，往往是cgroup限额比真实需求低，而不是进程真的泄露。

常见内存故障根因与对应处理

线上处置原则：能隔离（重启容器）就不杀进程，能调参数就不动代码，所有变更先在灰度环境验证，再推向生产。