Linux 确定内存类型的意义

实际上在排查 OOM 时：

确认内存类型
比
确认内存大小
更重要

因为：

1.5GB 被占用

只能说明：

内存没了

但不能说明：

是谁吃掉的
为什么吃掉的

举个例子

假设看到：

VmRSS: 1600MB

此时有四种完全不同的情况：

情况1：文件缓存(File Cache)

例如：

file-rss: 1400MB

这种一般是：

文件缓存
页缓存(Page Cache)

Linux缺内存时会自动回收。

根本不算泄漏。

情况2：匿名内存(Anonymous)

例如你的：

Anonymous: 1098704 kB

约：

1.1GB

这意味着：

malloc()
calloc()
new
glib对象
GstBuffer

申请的内存。

这种不会自动释放。

OOM最危险。

情况3：共享内存

例如：

Shmem: 800MB

可能是：

DRM
Wayland
共享缓冲区

方向完全不一样。

情况4：DMA Buffer

例如：

MPP
RGA
VPU

申请：

DMA Buffer

有时：

RSS不高

但系统已经OOM。

因为内存跑到驱动里去了。

你的数据说明了什么

你给过：

cat /proc/10449/smaps_rollup

里面：

Anonymous:       1098704 kB
Private_Dirty:   1098732 kB
Pss_File:           2946 kB

翻译一下：

匿名内存      ≈ 1.1GB
文件缓存      ≈ 3MB

几乎全部都是：

用户态申请的内存

而不是：

文件缓存

为什么这个结论很关键

如果看到：

File: 1.1GB
Anonymous: 10MB

我会直接说：

不是泄漏

因为：

Linux文件缓存

很正常。

但现在看到：

Anonymous: 1.1GB

我会立刻怀疑：

GStreamer对象
BufferPool
插件缓存

因为：

匿名内存增长

才符合泄漏特征。

对你这个项目的实际价值

如果你以后要找 Rockchip 或 GStreamer 社区提 Bug，单独说：

67小时后OOM
RSS 1.5GB

价值不大。

开发人员第一句话通常就是：

是File Cache还是Anonymous？

因为：

File Cache增长
≠ Bug

Anonymous增长
≈ 很可能是Bug

你这个案例目前已经能得出的结论

根据：

Out of memory: Killed process gst-launch-1.0
anon-rss: 1627328kB

以及：

Anonymous: 1098704kB
Private_Dirty: 1098732kB

实际上已经能确认：

增长的主要是匿名内存

所以排查方向应该集中在：

GStreamer对象
GstBuffer
BufferPool
textoverlay
videoconvert
mppvideodec
mpph265enc