一次find命令导致的内存问题排查


=Start=

缘由:

线上扫描加了个find命令,然后很多机器的磁盘IO就开始告警了,这个是意料之中的事情,毕竟该命令会增加读盘操作么;比较诡异的问题在于,部分机器的内存升高的比较厉害。。。我的天呐,要是把重要业务搞挂了我可怎么办。。。细思极恐

出了问题不可怕,「常在河边走,哪有不湿鞋」,通过定位原因,学习经验,以后避免就是了。

正文:

参考解答:
「内存的去向主要有3个:1.进程消耗;2.slab消耗;3.pagetable消耗。」

find可能引发的内存增长主要是因为slab消耗,且主要是inode和dentry的缓存:

$ cat /proc/slabinfo | grep --color -iE "inode|dentry"
$
$ cat /proc/slabinfo |awk '{print $1,$3*$4/1024,"KB"}' | sort -k2 -n
$ cat /proc/slabinfo |awk '{print $1,$3*$4/1024,"KB"}' | sort -k2 -n | tail

什么是pagecache/inodes/dentries?以及Linux内存的管理方法:


Linux系统对内存和swap的使用方式是什么样的?

  1. 有内存时先用内存;
  2. 内存不够了用swap;
  3. 内存充足了再把swap里的热点数据置换出来;
参考链接:

=END=

,

《“一次find命令导致的内存问题排查”》 有 4 条评论

  1. 发生 SLAB 内存泄漏该怎么办
    https://blog.arstercz.com/what-to-do-when-linux-slab-memory-leak/
    `
    通常应用程序主要通过类似 malloc 等标准函数来进行内存的分配使用, 不过在 Linux 中, 内核无法使用标准函数, 一般通过 SLAB Allocator 机制来进行内存的分配. 各个子系统, 驱动以及内核模块等都可以通过 SLAB Allocator 机制分配内存, 同时该机制还可以当作缓存来使用, 这点主要是针对经常分配并释放的对象. 从内核 2.6 版本开始, slab 分配器有两个替代分配器:

    分配器 用途
    slob 主要用于嵌入式系统, 代码量少, 算法简单
    slub 主要用于服务器等大型系统, 优化内存开销

    通常的服务器系统都使用 slub 分配器, 内核, 模块或驱动用完内存后都需要释放掉内存, 如果一直占用着内存, 系统可能会频繁的 OOM(Out of Memory) 杀掉用户空间的进程, 更有可能耗尽系统内存引起内核崩溃. 在如下信息中, 系统已经没有多少内存可用, 其中 SUnreclaim 为 slab 的一部分, 占据了大量的内存:

    如何诊断这种问题? 可以通过以下几种方式找到一些有用的线索:
    通过 debugfs 查找线索
    通过 slub 查找线索
    通过 kmemleak 查找线索
    通过 perf 查找线索
    通过 systemtap 查找线索
    `

    slab-allocator
    https://hammertux.github.io/slab-allocator

    kmalloc-1024 slab caches take all resources
    https://access.redhat.com/solutions/1546313

    keep track of slab leaks
    https://access.redhat.com/solutions/358933

    track slab allocations using perf
    https://access.redhat.com/solutions/2850631

    track slab allocations with systemtap
    https://access.redhat.com/articles/2850581

    debug-kernel-space-memory-leak
    https://www.bo-yang.net/2015/03/30/debug-kernel-space-memory-leak

    kmemleak 检测内核内存泄漏
    http://linuxperf.com/?p=188

    诊断 SLUB 问题
    http://linuxperf.com/?p=184

    诊断 SLAB 问题
    http://linuxperf.com/?p=148

发表评论

您的电子邮箱地址不会被公开。