内存碎片引发系统问题分析

14年淘宝双十一收藏夹业务依然使用我们OceanBase0.3版本，在0点抢购开始前出现大量查询请求超时，导致业务限流降级，收藏夹不可用时间达10分钟，和同事一起讨论分析了问题原因，简记再此。

现象：

使用perf分析后，发现mmap()系统调用引发的find_vma()占用了大量CPU，是外部请求超时的罪魁祸首。

背景&原因：：

1.进程地址空间，使用VMA描述，VMA有红黑树和链表两级管理结构；

2.OceanBase 0.3版本内存使用太不检点了，没有统一管理的内存池，只要大于64kb的内存申请，都是直接调用mmap()，这样无疑会的导致系统碎片太多，即VAM数量非常多，4000+;

3.linux kernel 2.6.32中，如果mmap()没有指明需要map的地址，则会从64TB最高用户空间地址开始查找可以分配的地址，方法就是从高到低，依次找相邻的两个VMA，检查之间的地址空间是否足够大，而查找每个VMA都是调用find_vma()，如果vma很多，碎片严重，每次mmap()都会多次调用find_vma();

4.每次mmap都会持mm_struct（内核中管理线性区的结构）的写锁，阻塞所有对虚拟地址的读（比如代码中访问某个指针）

5.内核线性区的代码注释明确说，其不适用于VMA数量比较多的应用场景，比如数据库，好吧，数据库，数据库。。。