PolarDB-X 是如何用15M内存跑1G的TPCH

在数据时代 过多耗内存的大查询都有可能压垮整个集群 所以其内存管理模块在整个系统中扮演着非常重要的角色。

而PolarDB-X 作为一款分布式数据库 其面对的数据可能从TB到GB字节不等 同时又要支持TP和AP Workload 要是在计算过程中内存使用不当 不仅会造成TP和AP相互影响 严重拖慢响应时间 甚至会出现内存雪崩、OOM问题 导致数据库服务不可用。

CPU和MEMORY相对于网络带宽比较昂贵 所以PolarDB-X 代价模型中 一般不会将涉及到大量数据又比较耗内存的计算下推到存储DN DN层一般不会有比较耗内存的计算。这样还有一个好处 当查询性能不给力的时候 无状态的CN节点做弹性扩容代价相对于DN也低。

鉴于此 所以本文主要对PolarDB-X计算层的内存管理进行分析 这有助于大家有PolarDB-X有更深入的理解。

PolarDB-X内存管理机制的设计 主要为了几类问题

让用户更容易控制每个查询的内存限制
预防内存使用不当 导致内存溢出进而引发OOM
避免查询间由于内存争抢出现相互饿死现象
避免AP Workload使用过多内存 严重拖慢TP Workload

业界解决方案

在计算层遇到的内存问题 业界其他产品也会遇到。这里我们先看下业界对此类问题是如何解决的。

PostgreSQL

为了面对内存问题 PG的内存管理有两大特点:

内存按照一定的比例 分为四大区域(Shared Buffers、Temp Buffers、Work Mem、Maintenance Work Mem)
在查询过程算子主要使用Work Mem区域内存 且每个算子都是预先分配固定内存的 但内存不够时 需要与硬盘进行swap

所以PG在生产中要求业务方合理配置内存比例 配置不当的话会极大的降低系统的性能。

一般有两种方式去指导业务方配置 估计方法与计算方法。

第一种是可以根据业务量的大小和类型 一般语句运行时间 来粗略的估计一下。第二种方式是通过对数据库的监控 数据采集 然后计算其大小。

Flink

接下来我们看看作为大数据库实时领域非常流行的计算引擎Flink 他的内存管理特点是

引入了一套基于字节流的数据结构 在JVM虚拟机上实现了类似C申请和释放内存的池化管理
内存主要分为三块: 网络内存池、系统预留的内存池、计算内存池。
为每个算子设置一个[min-memory, max-meory]?调度上可以保证每个算子初始化的时候预先分配min memory 在计算过程中不断从计算内存池申请内存 当申请失败或者内存使用超过算子预先定义max memory的时候 主动触发数据落盘。

Flink相对于PG来说 在计算过程中引入了动态管理机制 但这种机制是有限的。主要应该有两点考虑:?

整个计算是动态的 其实是很难权衡哪个算子抢占权重高 如果任意放开 肯定会影响性能
Flink是流水线计算模型 类似PartialAgg算子一定不落盘 所以一旦PartialAgg占用过多内存 导致下游没有内存可用 而PartialAgg又一定会往下游发送数据 这样必然会导致Dead Lock。

Spark

说到计算层的内存管理 就不得不提SPARK。SPARK早在2015年就提出了Project Tungsten。

当然钨丝计划的提出 主要是为了不要让硬件成为Spark性能的瓶颈 无限充分利用硬件资源。而其中内存管理的设计不仅仅可以减少JVM内存释放的开销和垃圾回收的压力 结合落盘能力可以支持海量数据的查询。

Spark 内存管理和Flink很像的 这里就不展开来说。但是它支持完全动态内存抢占 这种动态内存抢占主要体现在 Excution和Storage内存可以相互强制 Task间可以相互抢占 Task内部可以相互抢占。Spark这里假设了每个Task动态抢占内存的能力相当于 理论值都是1/N (N表示进程内部Task数量)。

Spark其实是可以这么假设的 他是典型的MR模型 只有Map端计算完后 才调度Reduce端 所有在一个进程内部多个Task你可以简单认为都是Map Task。当某个Task使用的内存不足1/2N时 它会等到其他Task释放内存。而Task间最多可以抢占的阈值也是1/N 而Task内算子是可以完全相互动态抢占的。

Spark的计算模型决定了他可以做到不预先为每个Task和算子预先分配内存 随着N的变化 动态调整每个Task的抢占能力。个人觉得这种动态抢占内存的方案 相对于其他计算引擎优越不少。但是由于Spark主要是针对大数据的ETL场景 稳定性至关重要 尽量避免任务重试。所以对每个Task抢占的上界都做了约束(Task Memory 1/N * Executor Memory) 确保每个Task都有内存执行任务。

Presto

Presto是由 Facebook 推出的一个基于Java开发的开源分布式SQL查询引擎。它的特点是:

采用的是逻辑内存池 来管理不同类型的内存需求。
Presto整体将内存分为三块: System Pool、Reserved Pool、General Pool。
Presto内存申请其实是不预分配的 且抢占是完全随机的 理论上不设定Task抢占的上限 但为了出现某个大查询把内存耗尽的现象 所以后台会有定时轮训的机制 定时轮训和汇总Task使用内存 限制Query使用的最大内存 同时当内存不够用的时候 会对接下来提交的查询做限流 确保系统能够平稳运行。

考虑到Presto是基于逻辑计数方式做内存管理 所以是不太精准的。但逻辑计算的好处是 管理内存成本比较低 这又往往适合对延迟要求特别低的在线计算场景。

PolarDB-X内存管理

业界基本上都会将内存分区域管理 针对于计算层主要区别在于: 内存是否预分配和查询过程中是否支持动态抢占。而PolarDB-X 是存储计算分离的架构 CN节点是无状态的 且主要针对于HTAP场景 所以对实时性要求比较高。

能否充分使用内存 对我们的场景比较关键。所以我们采取类似Presto这种无预分配内存 且支持动态抢占内存方案。除此之外 我们会根据不同的WorkLoad来管理内存 充分满足HTAP场景。

统一的内存模型

PolarDB-X内存也是分区域管理。结合自身的计算特点 按照不同的维度会有不同的划分和使用方式。

结合HTAP特性 我们将内存池划分为
System Memory Pool 系统预留的内存 主要用于分片元数据和数据结构、临时对象;
Cache Memory Pool 用于管理Plan Cache和其他LRU Cache的内存
AP Memory Pool: 用于管理WorkLoad是AP的内存;
TP Memory Pool: 用于管理WorkLoad是TP的内存;

相对于业界其他产品来说 我们主要划分出了AP和TP的内存区域。这么做是为了做TP/AP Workload在内存使用上的资源隔离。

结合我们的计算层次结构 我们按照树形结构去管理内存:

一个TP Workload的查询 我们会从TP Memory 申请出Query Memory 然后按照我们的计算层次关系 又会划分出Task/Pipeline/Driver/Operator Memory。

这样的好处是 我们可以动态监测不同维度下的内存使用情况。这里唯一要注意的是在Query Memory下 我们额外会创建一个Planner Memory 用于管理查询时和DN交互的数据对象的内存。

结合算子对内存申请和释放的行为 我们对一个Operator Memory划分为两个内存块: Reserve和Revoke。

Reserve Memory顾名思义就是算子一旦申请了内存就一定不会被动释放 直到该算子运行结束 主动释放内存 比如Scan算子 主要和DN交互数据的 一般都采样流式实现 每次运行都从DN获取一批数据 然后发送给下游 该算子一般不支持数据落盘 所以Scan算子都是申请Reseve Memory。

而Revoke Memory表示算子申请内存后 可以通过触发数据落盘的方式被动释放 将申请到的Revoke Memory归还到内存池 以供其他算子使用。比如HashAgg算子 都是申请Revoke Memory 但它申请的内存过多 导致这个查询其他算子无内存可用 就会被框架触发HashAgg数据落盘 将其申请的内存统统归还给内存池。

这里需要注意PolarDB-X对于Reserve和Revoke两块内存并没有按比例严格划分 这两者是可以完全相互抢占的。

内存对象

对于内存管理上 比较重要的实现类就是Memory Pool和MemoryAllocatorCtx。其中Memory Pool提供了申请和释放内存的API。

考虑到内存是按树形结构管理起来的 申请一次内存会涉及到多次函数调用 所以这里封装了MemoryAllocatorCtx对象 用于确保每次申请/释放内存的最小单位是512Kb 避免对MemoryPool相关函数多次调用的开销。且MemoryAllocatorCtx对象会记录上一次内存申请失败的大小 是框架用于判断内存是否不够用的重要标志。

interface?MemoryPool?{//申请reserve 内存ListenableFuture ? allocateReserveMemory(long size);//尝试着申请reserve 内存boolean tryAllocateReserveMemory(long size, ListenableFuture ? allocFuture);//申请revoke 内存ListenableFuture ? allocateRevocableMemory(long size);//释放reserve 内存void freeReserveMemory(long size);//释放revoke 内存void freeRevocableMemory(long size);}

在内存的使用上 我们采样的是非预分配模型 在计算调度上不需要额外考虑每个算子的使用内存。每个算子都是在执行期间按需去申请释放内存的 但这并不是意味着算子就可以任意去申请内存。

一旦所有的算子使用内存之和超过查询规定的最大内存 或者内存不够用的时候 我们都会阻塞当前查询 为此我们在原有的MemoryPool基础之上派生出了BlockingMemory 同样的为了方便AP和TP Workload基于内存做自适应的资源隔离 我们进一步派生出了AdaptiveMemory。

BlockingMemory 内存申请过中 会根据内存是否超过一定的阈值 创建阻塞对象 该对象会被执行线程引用。一般来说全局内存或者Query内存超过一定的阈值(0.8)的时候 就会触发当前算子申请内存失败 并且主动退出执行 这个和Spark算子申请不到内存后 阻塞当前线程的行为是不一致的。

AdaptiveMemory 用于做TP/AP的内存管理 在申请过程中会根据AP和TP的内存占比做一些自适应调整 比如触发限流、query自杀、大查询落盘等操作。

动态抢占内存机制

在内存申请和释放的行为上 我们采样的都是非阻塞模型 这种设计可以很好的和我们的时间片执行框架结合。结合这种设计 PolarDB-X算子都是不预分配内存的 各个算子都是在运行过程中完全动态抢占内存。

这钟动态抢占内存主要体现在: AP Memory 和TP Memory之间、Query Memory之间以及Operator Memory的Revoke和Reserve之间。

而实现这种抢占机制的基本单元依然是Driver 由下图可知 Driver会在运行过程中会根据当前Worload的内存空间、Query Used Memory 和 Operator Used Memory 来判断执行线程是否需要让出执行线程 被内存阻塞。一旦发现内存不够用的话 会主动退出执行队列 加入到阻塞队列 直到内存空间满足一定的条件 才会唤醒该Driver。

Driver被内存阻塞主要条件是

当内存池子(AP/TP Memory Pool)内存不足阈值的0.8之时 申请内存的算子会在下一刻会被暂停执行 等待被触发数据落盘 以到达释放内存的目的。
当前查询申请的总内存超过当前Max Query Memory阈值的0.8之后 申请的算子会被暂停执行等待被被触发数据落盘 以到达释放内存的目的。

当Driver被内存阻塞后 Driver会退出执行线程 将线程资源拱手相让给其他Driver。同时会回调MemoryRevokeService服务 该服务主要是基于内存大小和Pipeline的依赖关系挑选出耗内存的Driver进行标记。

当内存不够时 CN会基于Used Memory Size对Task做排序 依次对占用大内存的Task打标记 Taks内部则基于依赖关系 对Pipeline做排序 依次对父节点的Pipeline打标 Pipeline内部首先基于Driver Used Memory Siz做排序后 再结合Operator前后依赖关系 来决定Operator的内存释放顺序。

这里唯一需要注意的是MemoryRevokeService只是对需要释放内存的Operator进行打标记 然后唤醒对应的Driver 等待被调度的时候由执行线程池来触发数据落盘。

这里可能会有一个疑问 为什么打标记的同时不立刻触发数据落盘释放内存呢。由于Driver被落盘标记的时候 也有可能正在执行线程池执行 如果这个时候触发Driver执行落盘操作的时候 Driver会有并发安全的问题。所以我们将Driver的落盘动作和执行动作都交给执行线程池统一处理。

从上图还可知 一旦Driver被MemoryRevokeService唤醒 就调度到执行线程池中 首先做自我巡检 判断当前Driver是否包含SPILL标记 如果是的话 就需要触发Driver上相应算子做数据落盘的动作 这里唯一需要注意的是算子真正做数据落盘的逻辑是完全异步的 不占用执行线程。

一旦Driver开始做异步落盘后 也会主动退出执行线程 直到异步落盘结束后 才会唤醒当前Driver。整个过程确保了执行线程的资源不会被卡住。

基于负载的内存隔离

PolarDB-X在HTAP场景下是希望做到AP Workload不影响TP Workload。但当系统承载的都是AP Workload时 AP可以充分利用所有资源 当系统承载的都是TP Worload时 TP可以充分利用所有的资源。这里头我们巧妙了利用了TP Memory的阈值来到达目的。

Driver 执行过程中 按需申请内存 如果内存足够 会反复被调度执行
当Driver被内存阻塞时 判断其Workload
如果是AP 则通过MemoryRevokeService服务触发数据落盘 如果是TP Workload 则在触发数据落盘的同时 会判断当前TP Memory是否超过TP Memory Pool 若不是 则说明AP Workload使用内存过多 则回调AP Workload做调整
回调的方式有两种 触发部分AP Worload自杀 且触发Ap Worload 基于令牌桶的方式做滑动限流。

其中系统触发AP Worload自杀的回调机制 是比较危险的 默认是关闭的。而一旦触发AP Worload限流 则令牌桶流入的速率会减半 这样接下来的AP workload请求可能获取不到Token 而只能排队等待。

默认我们将TP Memory Pool的值设置为内存最大可利用资源的80% 表示在没有AP查询时 TP可以使用100%资源 在没有TP查询时 AP可以使用100%资源 当TP和AP Worload比较高时 AP最大只能占用20%的资源。

数据测试基于15MB的内存跑通1g TPCH 这里我们截取了几个比较耗内存的Query统计了落盘文件的数量。

测试了TPCC和TPCH混跑情况下 AP 对TP的影响。这部分测试也涵盖了CPU的资源隔离 后面我们会单独开一篇谈谈PolarDB-X基于负载的资源隔离技术。在不开启TPCH的情况下 tpmc保持在3.2w-3.4w之间; 再开启TPCH后 tpmc基本可以维持在3w以上 且有抖动10%左右。

总结

从上表对比来看

PolarDB-X算子不预分配内存 而是在计算过程中按需去申请内存 可以充分提高内存利用率
支持Workload/Query/Operator维度的内存动态抢占 比较适合HTAP场景 可以通过设置不同维度的阈值 尽可能确保在内存上TP Workload不受AP的干扰
相对于PostgreSQL/Flink/Spark来 PolarDB-X释放内存的时机是Lazy的。就是说当算子内存不够的时候 算子并不是立即落盘释放内存的 而是退出执行线程 由另外一个服务计算出更加耗内存的算子 这种方案可以挑选更加耗内存的查询或者算子做数据落盘 避免对小查询造成影响。但Lazy的方式存在一定的风险 可能在一瞬间内存未及时释放 而运行的查询申请内存过多 导致OOM 但好在PolarDB-X是计算存储分离的架构 计算层是无状态的
PolarDB-X 相对于Presto 动态内存抢占的粒度更加细 将Workload也纳入考虑。但Presto在实现的细节上会考虑大查询间内存的相互影响。而在HTAP场景下 我们更加注重AP对TP的影响 AP内查询间并没有额外的机制去保证内存不受影响。

从业界产品来看 每个产品在内存管理上都有各自的特点 这和产品本身的定位是有一定关系。而PolarDB-X作为一款计算存储分离的HTAP数据库来说 其计算层目前采用的完全动态内存抢占方案 可以做到充分使用内存 避免AP对TP的影响。

欢迎大家对我们持续关注

本文转自网络，原文链接：https://developer.aliyun.com/article/785217
本站部分内容转载于网络，版权归原作者所有，转载之目的在于传播更多优秀技术内容，如有侵权请联系QQ/微信：153890879删除，谢谢！