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数量比较多的应用场景,比如数据库,好吧,数据库,数据库。。。