Linux Kernel模块内存泄露分析

假如通过“Free”查看内存几乎耗尽，但通过 top/ps 命令却看不出来用户态应用程序占用太多的内存空间， 那么内核模块可能发生了内存泄露

SLAB 是Linux内核中按照对象大小进行分配的内存分配器。

通过SLAB的信息来查看内核模块占用的内存空间：

方法1. 查看meminfo文件

方法2. 查看slabinfo文件

一般查看slabinfo文件就足以，如果发现slabinfo中占用内存过大，那基本可以断定，内核模块出现了内存泄露了

还有个命令 slabinfo 也是可以看，其实也是去读 /proc/slabinfo 后可视化出来

Linux内核的Kmemleak实现内存泄露检测

看看下面这个函数是哪里导致的内存泄漏呢？

一眼可能不容易看出上面的有什么问题，有kmalloc，有kfree 成对出现的。

问题正好出在 pr_debug 这个函数中的参数传递， 熟悉函数调用传参的人应该会知道编译器一般对参数的处理采用堆栈的方式，是一个先进后出的过程，这样参数的执行一般是逆序的（由于编译器实现的不同，这个过程不是确定的），这样kfree会在kmalloc之前运行，导致每次运行都会泄漏一点内存。

Resolving Memory Leaks In Linux Kernel

Slab Allocator

Proc Info

Using Crash Debugger

OOM Killer(Out of Memory Killer) 是当系统内存严重不足时 linux 内核采用的杀掉进程，释放内存的机制。

OOM Killer 通过检查所有正在运行的进程，然后根据自己的算法给每个进程一个 badness 分数，拥有最高 badness 分数的进程将会在内存不足时被杀掉。

它打分的算法如下:

某一个进程和它所有的子进程都占用了很多内存的将会打一个高分。

为了释放足够的内存来解决这种情况，将杀死最少数量的进程（最好是一个进程）。

内核进程和其他较重要的进程会被打成相对较低的分。

上面打分的标准意味着，当 OOM killer 选择杀死的进程时，将选择一个使用大量内存，有很多子进程且不是系统进程的进程。

简单来讲，oom-killer 的原则就是损失最小、收益最大，因此它会让杀死的进程数尽可能小、释放的内存尽可能大。在数据库服务器上，MySQL 被分配的内存一般不会小，因此容易成为 oom-killer 选择的对象。

“既然发生了 OOM，那必然是内存不足，内存不足这个问题产生原因很多。

首先第一个就是 MySQL 自身内存的规划有问题，这就涉及到 mysql 相应的配置参数。

另一个可以想到的原因就是一般部署 MySQL 的服务器，都会部署很多的监控和定时任务脚本，而这些脚本往往缺少必要的内存限制，导致在高峰期的时候占用大量的内存，导致触发 Linux 的 oom-killer 机制，最终 MySQL 无辜躺q牺牲。”

---