服务器内存占用过高排查方法

# 以 MB 为单位查看内存总览
free -m

# 持续观察（每 1 秒刷新），看 available 是否在持续下降
free -m -s 1

# 最权威的原始数据
cat /proc/meminfo | egrep 'MemTotal|MemFree|MemAvailable|Buffers|Cached|SwapTotal|SwapFree|SwapCached|SReclaimable|Shmem'

真正的应用占用 ≈ MemTotal - MemFree - Buffers - Cached - SReclaimable + Shmem

# 1) 是否发生 swap 换入换出：si/so 长期非零说明物理内存真的不够了
vmstat 1 5
# 关注 si(swap in)、so(swap out) 两列，以及 free、buff、cache 三列的变化趋势

# 2) 是否已经被 OOM Killer 杀过进程（这是最硬的证据）
dmesg -T | grep -i -E 'oom|killed process'
journalctl -k --since '24 hours ago' | grep -i 'killed process'

# 按内存占用排序，看前 15 个进程
ps aux --sort=-%mem | head -15

# 只看关键列：RSS（实际驻留物理内存，KB）、VSZ（虚拟地址空间）
ps -eo pid,user,rss,vsz,comm --sort=-rss | head -15 | \
  awk '{printf "%s\t%s\t%.0fMB\t%.0fMB\t%s\n",$1,$2,$3/1024,$4/1024,$5}'

# 单进程详细内存映射（pmap -x 看每个映射段的 RSS）
pmap -x 12345 | tail -5
pmap -X 12345 | sort -k3 -rn | head -10

# 更准确的统计：PSS 把共享库按进程数分摊，USS 是进程独占部分
smem -s pss -r | head -15        # 按进程排序
smem -u -k                        # 按用户汇总
smem -P nginx -k                  # 只统计某类进程

grep -E 'VmRSS|VmSwap|VmSize|RssShmem|RssFile|RssAnon' /proc/12345/status
# RssAnon 高 = 堆/栈等匿名内存，是应用真正在用的部分
# RssFile 高 = 文件映射（程序文件、mmap 的文件、page cache 映射），可回收性更高

PID=12345

# 1) 先看 GC 健康度：每秒采样，共 10 次
jstat -gcutil $PID 1000 10
# 关键列：E(Eden)、O(Old)、M(Metaspace)、YGC/YGCT、FGC/FGCT
# 若 O 区长期 99% 且 FGC 持续上涨 → 堆内存不足或存在泄漏

# 2) 看堆内对象分布（不触发 Full GC，开销小，可线上执行）
jmap -histo:live $PID | head -30

# 3) 堆转储（会触发 Full GC 并暂停应用，务必在低峰期执行，文件约为堆大小）
jmap -dump:format=b,file=/tmp/heap.hprof $PID
# 分析工具：Eclipse MAT、VisualVM、JProfiler

# 线程数过多（每个线程默认栈 1 MB，1000 线程就是 1 GB）
ps -Lp $PID | wc -l

# 查看 JVM 启动参数，确认 -Xmx、-Xms、-XX:MaxDirectMemorySize、-Xss
jcmd $PID VM.flags
jinfo -flags $PID

# 直接内存与元空间使用
jcmd $PID VM.native_memory summary | head -30   # 需启动时加 -XX:NativeMemoryTracking=summary

# 用 sar 回看历史趋势（需提前开启 sysstat）
sar -r -s 08:00:00 -e 20:00:00     # 看当天 kbmemused/kbmemfree 曲线
sar -r 1 60                        # 现场连续采样 60 秒

# 简易趋势采样脚本：每 30 秒记录一次 available 与 TOP 进程，跑一夜看曲线
cat > /tmp/mem-trend.sh <<'EOF'
#!/bin/bash
LOG=/tmp/mem-trend.log
while true; do
  echo "=== $(date '+%F %T') ===" >> $LOG
  grep -E 'MemAvailable|SwapFree' /proc/meminfo >> $LOG
  ps -eo pid,rss,comm --sort=-rss | head -6 >> $LOG
  sleep 30
done
EOF
chmod +x /tmp/mem-trend.sh && nohup /tmp/mem-trend.sh &

# 宿主机层面：内核 OOM 日志
dmesg -T | grep -i -E 'killed process|out of memory' | tail -20

# K8s 层面：看 Pod 的 Last State 与退出原因
kubectl get pod  -o yaml | grep -A5 lastState
kubectl describe pod  | egrep -i 'OOM|Killed|Reason|memory'

# Docker 层面
docker inspect --format '{{.State.OOMKilled}} {{.State.ExitCode}}' 

# cgroup v2：查看容器内存上限、当前用量与事件计数
cat /sys/fs/cgroup/memory.max
cat /sys/fs/cgroup/memory.current
cat /sys/fs/cgroup/memory.events      # oom_kill 计数非零 = 确实被 OOM 杀过

# 容器内存限制 2 GB 时的推荐配置（堆约占 60%~70%，剩下留给元空间、线程栈、直接内存）
java -Xms1200m -Xmx1200m -XX:MaxMetaspaceSize=256m -XX:+HeapDumpOnOutOfMemoryError \
     -XX:HeapDumpPath=/data/dump -jar app.jar

# Java 8u191+ / Java 11+ 可直接让 JVM 感知容器限制
java -XX:+UseContainerSupport -XX:MaxRAMPercentage=70.0 -jar app.jar

# 用 systemd 给单个服务设内存上限（超出时该服务 OOM，不影响整机）
systemctl set-property myapp.service MemoryMax=2G
systemctl show myapp.service | grep -E 'MemoryMax|MemoryHigh'

# 调整 swap 使用倾向（0=尽量不用 swap，100=积极使用；数据库服务器建议设 1~10）
sysctl vm.swappiness
sysctl -w vm.swappiness=10
echo 'vm.swappiness=10' >> /etc/sysctl.conf