☰

内存随着时间的推移而满，“缓冲区/缓存”使用率高，“可用”内存低

tag-icon • tag-icon ubuntu memory out-of-memory
内存随着时间的推移而满，“缓冲区/缓存”使用率高，“可用”内存低

每当我重新启动笔记本电脑时，一切都运行得惊人，并且内存使用率最多为 40%（8GB 之外）。然而，随着时间的推移（大约使用 1 天），内存使用率上升到 90% 以上，并且系统开始交换。

现在，free -mh返回这个：

              total        used        free      shared  buff/cache   available
Mem:           7,7G        1,3G        141M        223M        6,3G        246M
Swap:          7,5G        530M        6,9G

我假设如果进程需要，缓冲/缓存内存可以自由地重新分配，但它似乎大多不可用。

cat /proc/meminfo:

MemTotal:        8055268 kB
MemFree:          145184 kB
MemAvailable:     247984 kB
Buffers:           49092 kB
Cached:           423724 kB
SwapCached:        38652 kB
Active:           881184 kB
Inactive:         791552 kB
Active(anon):     708420 kB
Inactive(anon):   725564 kB
Active(file):     172764 kB
Inactive(file):    65988 kB
Unevictable:         252 kB
Mlocked:             252 kB
SwapTotal:       7812092 kB
SwapFree:        7267624 kB
Dirty:               352 kB
Writeback:             0 kB
AnonPages:       1195320 kB
Mapped:           235860 kB
Shmem:            234068 kB
Slab:            6117796 kB
SReclaimable:     167260 kB
SUnreclaim:      5950536 kB
KernelStack:       10352 kB
PageTables:        30312 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:    11839724 kB
Committed_AS:    6410728 kB
VmallocTotal:   34359738367 kB
VmallocUsed:           0 kB
VmallocChunk:          0 kB
HardwareCorrupted:     0 kB
AnonHugePages:    104448 kB
CmaTotal:              0 kB
CmaFree:               0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:     1361472 kB
DirectMap2M:     5859328 kB
DirectMap1G:     1048576 kB

我发现这些值特别有趣，因为它们与 的 buff/cache 使用情况有很大关联free，但我不知道如何处理它们或下一步该去哪里查看：

SReclaimable:     167260 kB
SUnreclaim:      5950536 kB
Slab:            6117796 kB

接下来我可以去哪里看？什么是slab，有没有办法减少它的内存使用量？

答案1

您应该检查top是否有某些东西实际上正在使用您的 RAM，按内存使用情况排序，或者检查系统监视器中的内存使用情况。

Linux 会借用未使用的内存用于磁盘缓存。这会让您看起来内存不足，但事实并非如此。检查此网页以获取更多说明：https://www.linuxatemyram.com/

在发布的示例中，您实际上有大约 6.5Gb 未使用的内存。您还可以看到交换量非常低（540Mb）。

您可以将缓存释放为在这里解释然后free将在可用字段中显示可用内存：

  • 释放页面缓存：

      # echo 1 > /proc/sys/vm/drop_caches

  • 释放 dentry 和 inode：

      # echo 2 > /proc/sys/vm/drop_caches

  • 释放页面缓存、目录项和索引节点：

      # echo 3 > /proc/sys/vm/drop_caches

或者使用这个命令：

free && sync && echo 3 > /proc/sys/vm/drop_caches && free

关于Slab：
Slab、SReclaimable、SUnreclaim
内核在运行过程中会进行大量的重复操作。某些对象（例如询问文件的特定索引节点）可能每天执行数千次。在这种情况下，明智的做法是将其存储在快速引用列表或缓存中。 Slab 是内核对象的缓存，用于优化那些最常发生的活动。

Slab字段是SReclaimable和SUnreclaim的总和。

尝试对正在使用 Slab SUnreclaim 内存量的问题进行故障排除slabtop。

以上内容旨在以 root 身份运行。

答案2

所以经过一些过度设计故障排除我发现通量似乎导致kmalloc-4096板块缓慢但稳定地增长。我会尝试找出原因并更新此答案。

答案3

附带说明一下，我最近遇到一个top以批处理模式（-b 选项）运行的系统，进程 SLAB 会增长。例如：

# cat /proc/slabinfo | grep proc
proc_inode_cache    5567   5868    440    9    1 : tunables    0    0    0 : slabdata    652    652      0

当我在不运行 top 的情况下启动系统时，proc SLAB 内存消耗会大大降低：

# cat /proc/slabinfo | grep proc
proc_inode_cache     564    846    440    9    1 : tunables    0    0    0 : slabdata     94     94      0

这是因为该top工具遍历 /proc 来获取每个进程的统计信息。这会触发用上次访问的 proc 文件的 inode 填充 proc SLAB。

相关内容