Linux服务器内存泄漏排查：从系统指标到进程级定位的完整方案

小编 • • 服务器

服务器内存泄漏的典型表现与初步判断

Linux服务器运维中，内存泄漏是最常见也最棘手的问题之一。典型症状包括：可用内存持续下降、Swap使用量攀升、OOM Killer随机杀进程、服务响应变慢。在Kubernetes环境下，单个Pod的内存泄漏还可能触发Eviction导致Pod被驱逐。

排查的第一步是确认问题性质。执行 free -h 查看整体内存分布：

$ free -h
              total        used        free      shared  buff/cache   available
Mem:           62Gi       48Gi       2.0Gi       256Mi        12Gi        10Gi
Swap:         8.0Gi       6.5Gi       1.5Gi

当available持续走低且buffer/cache无法回收时，基本可以确认存在内存泄漏。注意 free 列的值低不一定有问题——Linux会将空闲内存用于缓存，这是正常行为。关键看 available 是否在持续下降。

使用slabtop和proc追踪内核级内存消耗

有时候内存泄漏不在用户态进程，而在内核的Slab分配器中。dentry cache、inode cache等内核数据结构如果积累过多，会占用大量内存且不显示在进程的RSS中。检查内核Slab占用：

$ cat /proc/meminfo | grep -i slab
Slab:             81920 kB
SReclaimable:     65536 kB
SUnreclaim:       16384 kB

当SUnreclaim持续增长，说明内核有不可回收的Slab对象泄漏。用slabtop可以看具体是哪种对象在增长：

$ slabtop -s c
 OBJS ACTIVE  USE OBJ SIZE  SLABS OBJ/SLAB CACHE SIZE NAME
2852880 2851000  99%    0.19K  142644       20    1141152K dentry
1420320 1419800  99%    0.76K   273140        5    2185120K inode_cache

dentry和inode cache是文件系统相关的缓存，正常情况下可回收。但如果进程持续打开文件而不关闭，这些缓存就会积累。紧急处理方式是强制回收：

# 强制回收dentry和inode缓存
$ sync && echo 3 > /proc/sys/vm/drop_caches

这只是临时措施，根本原因需要定位到是哪个进程在疯狂打开文件句柄。

进程级内存分析：从pmap到eBPF精准定位

确认是用户态进程泄漏后，需要找到具体进程。按RSS排序：

$ ps aux --sort=-%mem | head -10
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
appuser   8732  2.5 42.7 32587412 28037432 ?   Sl   Jun15 1234:56 java -Xmx24g -jar app.jar
www-data  9105  0.8 12.3 8234100 8096124 ?    Sl   Jun15  456:78 nginx: worker process

找到可疑进程后，用 pmap -x 查看其详细内存映射：

$ pmap -x 8732 | tail -20
total kB       28037432 27501234 5432108

对于Java应用，jmap和jcmd是更有效的工具：

# 生成堆直方图
$ jcmd 8732 GC.class_histogram

# 导出堆转储用于离线分析
$ jcmd 8732 GC.heap_dump /tmp/heapdump.hprof

对于C/C++程序，可以使用Valgrind的memcheck或AddressSanitizer。但生产环境更推荐使用eBPF工具bcc/memleak，它的开销远低于Valgrind：

# 跟踪指定PID的内存分配未释放
$ /usr/share/bcc/tools/memleak -p 8732

# 输出示例：
# Attaching to pid 8732, Ctrl+C to quit.
# allocs = 15432, losses = 3210
# 
# top 5 allocations:
#     3210 bytes in 321 allocations from:
#         malloc_return_0x7f2a3c001000+0x10
#         [unknown] [conn_pool.c:142]
#     2100 bytes in 210 allocations from:
#         malloc_return_0x7f2a3c002000+0x20
#         [unknown] [request_handler.c:89]

容器环境下的内存泄漏排查差异

在Docker和Kubernetes环境中，排查内存泄漏有额外复杂性。容器的内存统计与宿主机的 /proc/meminfo 是隔离的，需要查看容器的cgroup数据：

# 查看容器内存使用（在容器内或宿主机对应cgroup路径）
$ cat /sys/fs/cgroup/memory/memory.usage_in_bytes
$ cat /sys/fs/cgroup/memory/memory.limit_in_bytes

# Kubernetes中查看Pod内存
$ kubectl top pod -n production --sort-by=memory
$ kubectl describe pod app-server-7d4f8 | grep -A5 "Limits"

K8s环境中，内存泄漏的排查步骤：第一，确认Pod的memory request和limit设置是否合理；第二，检查是否是JVM堆外内存泄漏（NIO Direct Buffer、JNI分配等），这类泄漏不反映在JMX的堆内存指标中；第三，对于多容器Pod，逐个排查sidecar容器的内存占用。

长期监控与自动化告警

排查完一次内存泄漏后，建立长期监控防止复发。Prometheus + Grafana的内存监控方案中，以下几个指标最为关键：

# Prometheus查询：可用内存低于20%告警
100 - ((node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) * 100) > 80

# RSS增长趋势（过去1小时增量）
process_resident_memory_bytes - (process_resident_memory_bytes offset 1h) > 1073741824

告警规则需要区分缓进式泄漏（可用内存每天下降固定量）和突发式泄漏（短时间内RSS暴涨）。缓进式泄漏适合用导数函数 deriv() 检测趋势，突发式泄漏适合用阈值告警。两者组合使用才能覆盖完整场景。

服务器故障排查的标准化流程

将内存泄漏排查沉淀为标准化操作手册，核心步骤：确认症状（free/meminfo）→ 区分内核/用户态（slabtop/ps）→ 定位进程（ps/pmap）→ 分析根因（jmap/memleak/eBPF）→ 修复验证 → 建立监控。每次排查都应记录泄漏原因和修复方案，形成知识库，避免同类问题反复出现。

原创文章，作者：小编，如若转载，请注明出处：https://www.yunthe.com/linux-fu-wu-qi-nei-cun-xie-lou-pai-cha-cong-xi-tong-zhi/

赞 (0)
小编小编
0
上一篇 10小时前
下一篇 10小时前

相关推荐

Linux服务器内存泄漏排查：从系统指标到进程级定位的全链路方案

小编 • • 服务器

服务器运维中，内存泄漏是最常见也最难排查的问题之一。一台运行正常的Web服务器，可用内存从32GB缓慢降至几百MB，Swap使用量持续攀升，最终触发OOM Killer杀掉关键进程。本文从系统级监控到进程级代码定位，给出一套可操作的全链路排查方案。

系统层内存指标采集与异常判定

free -h是第一步，但仅看available列不够。关键要看Slab缓存和Page Cache的变化趋势。执行以下命令获取详细内存分布：

# 查看内存整体分布
cat /proc/meminfo | grep -E 'MemTotal|MemFree|MemAvailable|Buffers|Cached|Slab|SReclaimable|SUnreclaim'

# 查看Slab缓存细分
cat /proc/slabinfo | sort -k3 -n -r | head -20

# 监控内存变化趋势（每5秒采样）
vmstat -s; sleep 5; vmstat -s

异常判定标准：MemAvailable持续下降且不恢复（排除缓存自动释放场景）；SUnreclaim持续增长说明内核Slab有泄漏；Swap使用量持续上升且si/so列非零。

进程级内存占用定位与排序

系统层确认存在内存异常后，需定位到具体进程。ps和top按RSS排序只是起点，更精确的方式是按PSS（Proportional Set Size）排序，因为PSS将共享库内存按引用进程数均摊，更真实反映进程实际占用：

# 按PSS排序（需smem工具）
smem -t -k -s pss | tail -20

# 或用/proc直接读取（无需安装额外工具）
for pid in $(ls /proc | grep -E '^[0-9]+$'); do
  if [ -f /proc/$pid/status ]; then
    name=$(grep Name /proc/$pid/status | awk '{print $2}')
    rss=$(grep VmRSS /proc/$pid/status | awk '{print $2}')
    echo "$pid $name VmRSS:${rss}KB"
  fi
done | sort -k4 -n -r | head -20

定位到可疑进程后，需进一步判断泄漏来源是堆内存、线程栈还是内存映射区域。/proc/pid/smaps提供了每段内存的详细属性，其中的Rss、Pss、Shared_Clean、Private_Dirty等字段可区分共享和私有内存。

使用eBPF实现低开销在线内存追踪

传统排查方式需要在目标进程上挂接gdb或valgrind，对生产环境影响较大。eBPF技术可以在内核态埋点，开销极低（通常不到1% CPU），适合生产环境在线排查。

# 使用bpftrace追踪进程的malloc/free调用
bpftrace -e '
uprobe:/lib/x86_64-linux-gnu/libc.so.6:__libc_malloc
/pid == TARGET_PID/
{
  @malloc_size[pid] = hist(arg0);
}

uprobe:/lib/x86_64-linux-gnu/libc.so.6:__libc_free
/pid == TARGET_PID/
{
  @free_count[pid] = count();
}'

memleak是BCC工具集自带的内存泄漏检测工具，可输出未释放的分配调用栈：

# 追踪目标进程的内存分配（-p指定PID）
sudo memleak-bpfcc -p TARGET_PID

# 或按进程名追踪
sudo memleak-bpfcc -c "java -jar app.jar"

输出结果会列出未释放内存的调用栈和累计分配大小，直接指向泄漏代码路径。

Java应用堆内存泄漏专项排查

Java应用的内存泄漏往往不在Native层，而在JVM堆中。排查流程：

# 1. 确认JVM堆内存趋势（每10秒采样）
jstat -gcutil PID 10s

# 2. 导出堆直方图，看哪些对象占用最多
jmap -histo:live PID | head -30

# 3. 导出堆转储（注意：会导致STW）
jmap -dump:format=b,file=heap.hprof PID

# 4. 用MAT或VisualVM分析hprof文件
# 重点关注：Dominator Tree中占用最大的对象
# Leak Suspects报告自动检测的疑似泄漏点

常见Java内存泄漏模式：ThreadLocal未清理（线程池复用时尤其危险）；静态集合不断追加但无清理逻辑；监听器/回调注册后从未注销；大对象缓存在WeakHashMap中但key被强引用。

Go程序内存泄漏排查路径

Go的内存泄漏排查使用pprof工具链。在程序中引入net/http/pprof后，通过HTTP端点采集内存profile：

# 采集当前内存profile
curl -o mem.pprof http://localhost:6060/debug/pprof/heap

# 对比两个时间点的增量
curl -o mem1.pprof http://localhost:6060/debug/pprof/heap
# 等待10分钟
curl -o mem2.pprof http://localhost:6060/debug/pprof/heap

# 用go tool pprof分析增量
go tool pprof -base mem1.pprof mem2.pprof

# 在交互式终端中输入top20查看增长最多的对象
(pprof) top20
(pprof) web  # 生成调用图（需graphviz）

Go常见泄漏场景：goroutine泄漏（channel阻塞导致goroutine永远不退出，可通过runtime.NumGoroutine()监控）；全局slice/map只追加不删除；闭包捕获大变量导致无法GC。

长期监控与自动告警配置

一次性排查解决不了反复出现的泄漏。需搭建持续监控体系：Prometheus采集node_memory相关指标，配合Grafana面板可视化。告警规则示例：

# Prometheus告警规则：可用内存低于10%且持续30分钟
- alert: MemoryPressure
  expr: node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes < 0.1
  for: 30m
  labels:
    severity: warning
  annotations:
    summary: "实例可用内存低于10%"

# OOM Killer触发告警
- alert: OOMKilled
  expr: increase(node_vmstat_oom_kill[5m]) > 0
  labels:
    severity: critical

对于关键业务进程，配置cgroup内存限制并开启OOM通知，在进程被杀前收到预警，自动触发内存快照采集，为事后分析保留现场。

原创文章，作者：小编，如若转载，请注明出处：https://www.yunthe.com/linux-fu-wu-qi-nei-cun-xie-lou-pai-cha-cong-xi-tong-zhi/

赞 (0)
小编小编
0
上一篇 17小时前
下一篇 17小时前

相关推荐