可能类似于Linux 内存使用率高于进程总和但我观察到使用的内存既低于又高于进程 RSS 的总和(以 GB 为单位)。
uname -sr
Linux 5.0.9-...
cat /proc/meminfo
MemTotal: 8155920 kB
MemFree: 280200 kB
MemAvailable: 328152 kB
Buffers: 144 kB
Cached: 704380 kB
SwapCached: 15440 kB
Active: 2374160 kB
Inactive: 1195784 kB
Active(anon): 2259104 kB
Inactive(anon): 1026600 kB
Active(file): 115056 kB
Inactive(file): 169184 kB
Unevictable: 238012 kB
Mlocked: 0 kB
SwapTotal: 8388604 kB
SwapFree: 5908220 kB
Dirty: 168 kB
Writeback: 0 kB
AnonPages: 3097284 kB
Mapped: 255492 kB
Shmem: 420252 kB
KReclaimable: 81636 kB
Slab: 346972 kB
SReclaimable: 81636 kB
SUnreclaim: 265336 kB
KernelStack: 14720 kB
PageTables: 70776 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 12466564 kB
Committed_AS: 9429628 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 0 kB
VmallocChunk: 0 kB
Percpu: 2112 kB
HardwareCorrupted: 0 kB
AnonHugePages: 0 kB
ShmemHugePages: 0 kB
ShmemPmdMapped: 0 kB
CmaTotal: 0 kB
CmaFree: 0 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
Hugetlb: 0 kB
DirectMap4k: 4764008 kB
DirectMap2M: 3614720 kB
所有进程的 RSS 总和(从top
输出中单独求和)、slabinfo、buff/cache、swap 的变化不会超过 100 MB,但可用内存将增加 GB后启动 ffmpeg... 在繁重的长期压缩任务上启动 ffmpeg 似乎可以可靠地消除所有磁盘抖动,并每次都显着增加可用内存(良好的临时解决方案,但作为长期解决方案不可接受)。当 ffmpeg 运行时,可用内存会下降,磁盘会崩溃,但可用内存随后会增加 GB,这种行为仅在 ffmpeg 运行时才会存在。如果 ffmpeg 未运行,则可用内存将从导致磁盘抖动的情况变为最多几百 MB。在系统使用的最后两个月左右的时间里,似乎没有其他程序具有相同的效果。有趣又烦人。
答案1
请注意,我主要使用基于 BSD 的系统。但据我看到你的情况看起来非常相似。在我看来,你的数据“按预期”工作。内存优于交换,因为它无限快。所以你的系统正在尽力管理那个记忆,以及仅有的允许应用程序使用它,因为系统认为合适,而不是应用程序。 IOW你的系统消耗内存,以便它可以将该资源代理为它认为合适。反之则不然。
现在我可以补充一下。如果你不这样做批准的。你做可以选择“调整”内核以根据自己的喜好更改其行为。但老实说;我觉得不错。
华泰
答案2
Committed_AS
大于MemTotal
所以你最终会调出页面。当达到阈值时,内存回收将删除一些缓存,将一些页面移出到磁盘,以及类似的活动。
如果您不喜欢这种回收行为,请添加更多 RAM。
程序或内核中的“内存泄漏”实际上失去了已分配内存的跟踪,这是一个严重的声明。请不要将回收行为与使用 Valgrind 或 LeakSanitizer 等工具发现的泄漏混淆。