transmission-daemon疑似内存泄漏的排查方法及监控指标咨询

看起来你遇到了典型的系统OOM（内存不足）问题，而且矛头直指transmission-daemon的内存异常占用——从syslog里能看到它的虚拟内存飙到了32G，刚好撑满你的物理内存，被内核OOM Killer杀掉也在情理之中。结合你提到的MemAvailable两周从32G降到0的趋势，大概率是进程存在内存泄漏的情况。下面给你梳理下可行的排查和监控方法：

一、关于ps的VSZ是否适合监控 #

首先明确：VSZ（虚拟内存大小）可以用来监控趋势，但不能单独作为判断依据。

• VSZ统计的是进程整个虚拟地址空间的大小，其中包含很多未实际占用物理内存的部分（比如映射但未读取的文件、预留但未分配的内存块），所以数值会偏大；
• 建议同时关注RSS（常驻内存大小），它代表进程实际占用的物理内存。你可以用ps aux | grep transmission-daemon或者top/htop持续观察这两个值，如果两者都呈现持续增长的趋势，基本能坐实内存泄漏的问题。

二、更有效的内存追踪方法 #

1. 用pmap分析内存映射详情 #

pmap -x <transmission-daemon的PID>能列出进程所有内存映射区域的详细信息，包括每个区域的大小、权限、对应的文件或匿名内存类型。通过定期对比输出，你可以定位到底是哪部分内存在持续增长——比如是匿名内存（堆内存泄漏的典型特征）还是某个异常的文件映射导致的。

2. 定时采集进程内存状态数据 #

你可以写个简单的shell脚本，定时读取/proc/<PID>/status里的关键内存字段（比如VmSize、VmRSS、VmData、VmStack），同时记录系统的MemAvailable值，把这些数据导出到日志文件里。后续可以用工具（比如gnuplot、Excel）生成趋势图，能更直观地看到内存增长的速率和规律。
举个简单的脚本示例：

#!/bin/bash
PID=$(pgrep transmission-daemon)
while true; do
    echo "$(date +%Y-%m-%d_%H:%M:%S) $(grep -E 'VmSize|VmRSS|VmData' /proc/$PID/status) $(grep MemAvailable /proc/meminfo)" >> mem_monitor.log
    sleep 3600 # 每小时记录一次
done

3. 内存泄漏检测工具（进阶） #

如果想深入排查程序层面的泄漏，可以用valgrind --tool=memcheck运行transmission-daemon，但要注意这个工具会大幅降低程序性能，建议在测试环境复现问题后再使用。如果是生产环境，也可以考虑用perf工具分析内存分配的热点，定位到具体的代码模块。

三、为什么/proc/$PID/mem是空的 #

这个文件是进程的虚拟内存内容，但默认只有root用户能访问，而且很多内存区域是不可读的（比如内核空间、未映射的虚拟地址），所以直接查看它的意义不大，不如用上面提到的工具来分析内存占用情况。

附：你提供的内核OOM日志 #

Nov 29 04:35:30 primo kernel: [1348176.819869] Tasks state (memory values in pages):
Nov 29 04:35:30 primo kernel: [1348176.819870] [  pid  ]   uid  tgid total_vm      rss pgtables_bytes swapents oom_score_adj name
Nov 29 04:35:30 primo kernel: [1348176.819917] [    888]   132   888  8132465  7183145 61280256   428000             0 transmission-da
Nov 29 04:35:30 primo kernel: [1348176.820173] Out of memory: Killed process 888 (transmission-da) total-vm:32529860kB, anon-rss:28732580kB, file-rss:0kB, shmem-rss:0kB, UID:132 pgtables:59844kB oom_score_adj:0

备注：内容来源于stack exchange，提问作者Maarten Deen