内核实战教程第七期 | 基础模块之内存管理框架与线程模型

这是「从0到1内核实战教程」的最后一期，在前几期教程中，我们分别从存储、SQL、事务这三个核心方面讲解了通用数据库的内核知识，并结合 OceanBase 的实现讲解，相信你已经了解并初步掌握了数据库内核各模块的功能。

在如此复杂的分布式数据库系统实现过程中，你可能对 OceanBase 在生产环境中的测试充满了好奇，9月29日 19:30 从0到1内核实战教程第七期 OceanBase 开源版质量负责人将满足你的好奇心，揭秘 OceanBase 的测试日常。除此之外，本期教程还将为你介绍 OceanBase 高并发、高利用率、高诊断性的内存管理框架和线程模型，这对你日后遇到报错排查问题时会有很大的帮助。

本期能帮你解决什么问题？

1、遇到内存问题时因不了解内容结构，而不知道该如何去下手排查。

2、数据库系统测试时，都进行哪些类型的测试以及使用哪些测试工具？

3、相对于传统的线程模型，OceanBase 的线程模型都做了哪些优化？

直播内容抢“鲜”知

本次直播，将分享三个部分：

1、设计一个通用内存分配器需要考虑哪些因素。

2、如何发现内存安全漏洞的第一现场。

3、一条SQL请求"从生到死"的完整过程。

设计一个通用内存分配器需要考虑哪些因素

因素一：性能

如何提高多核性能：系统性的多路设计及工作线程缓存化。

空闲块索引方法：基于位运算做best-fit, 平衡了性能与利用率

因素二：利用率。

大型服务器程序常态运行下的内存碎片是难以避免的，碎片会降低空间利用率，严重可拖垮系统。严格上说这是不同内存生命周期的顶层模块之间的"磨合"问题，但对于一个追求极致稳定性的系统来说，选择高杠杆的底层优化是必然选择。OceanBase内核认为碎片是一定会存在的，只需要在合适对时机进行碎片清理即可。采用操作系统提供的madvise系统调用进行碎片清理，分为主动与被动两种触发场景，实践显示该机制可显著改善异常场景下的系统可用性。

因素三：可诊断性

怎么知道内存"去哪儿了"呢？每一次malloc调用都约束使用者必须传入归属信息，比如租户id、模块id等信息，这些信息将统一汇总到LOG

使用后台线程in-place遍历内存块，OceanBase内核采用了一种相对高级的处理手法实现了整个遍历过程与分配释放路径零锁冲突，即利用signal_handler捕获段错误，牺牲一点点诊断信息的准确性换取了最高的性能。

内存碎片问题怎么发现呢？在直播中，我们将描述OceanBase内核如何发现内存碎片问题及其诊断思路，以及怎么判定发生了内存泄漏；内存泄漏发生后OceanBase内核提供了什么手段进行诊断。有事前与事后两种机制，可满足绝大部分诊断需求。敬请关注直播。

如何发现内存安全漏洞的第一现场

C/C++程序世界里开发者可以直接操控内存，享受极致性能的同时也催生了无穷无尽的内存安全漏洞。每一个漏洞都可能让产品陷入崩溃并且需要测试与开发人员投入大量的排查精力。随着功能的不断迭代更新，内存安全漏洞是难以避免的，那么OB内核是如何做到快速发现并定位这些漏洞的呢？通过本节学习，相信你会有很大启发。

内存安全漏洞有哪些类型：在直播中将介绍三种常见的基本类型：double-free、use-after-free、buffer overflow

OceanBase内核的解决方案是什么：OceanBase内核利用编译器插桩技术实现了一套高效、强大、通用的内存安全检查方案。

OceanBase内核对所有内存编码了一套元信息，is_poisoned即通过读取元信息判定指定内存是否安全。这个例子里，第二次用'\0'赋值在常规版本会执行成功，但在编译插桩版本将会触发abort，将故障拦在了第一现场！

一条SQL请求"从生到死"的完整过程

本节介绍线程分类及完成一条SQL请求过程的数据流转。