图数据库 NebulaGraph 的内存管理实践之 Memory Tracker
数据库的内存管理是数据库内核设计中的重要模块,内存的可度量、可管控是数据库稳定性的重要保障。同样的,内存管理对图数据库 NebulaGraph 也至关重要。
图数据库的多度关联查询特性,往往使图数据库执行层对内存的需求量巨大。本文主要介绍 NebulaGraph v3.4 版本中引入的新特性 Memory Tracker,希望通过 Memory Tracker 模块的引入,实现细粒度的内存使用量管控,降低 graphd 和 storaged 发生被系统 OOM kill 的风险,提升 NebulaGraph 图数据库的内核稳定性。
注:为了同代码保持对应,本文部分用词直接使用了英文,e.g. reserve 内存 quota。
可用内存
在进行 Memory Tracker 的介绍之前,这里先介绍下相关的背景知识:可用内存。
进程可用内存
在这里,我们简单介绍下各个模式下,系统是如何判断可用内存的。
物理机模式
数据库内核会读取系统目录 /proc/meminfo
,来确定当前环境的实际内存和剩余内存,Memory Tracker 将“实际物理内存”作为“进程可以使用的最大内存”;
容器/cgroup 模式
在 nebula-graphd.conf
文件中有一个配置项 FLAG_containerized
用来判断是否数据库跑在容器上。将 FLAG_containerized
(默认为 false)设置为 true 之后,内核会读取相关 cgroup path 下的文件,确定当前进程可以使用多少内存;cgroup 有 v1、v2 两个版本,这里以 v2 为例;
举个例子,在单台机器上分别控制 graphd 和 storaged 的内存额度。你可以通过以下步骤:
step1:设置 FLAG_containerized=true
;
step2:创建 /sys/fs/cgroup/graphd/
,/sys/fs/cgroup/storaged/
,并配置各自目录下的 memory.max
;
step3:在 etc/nebula-graphd.conf
,etc/nebula-storaged.conf
添加相关配置
Memory Tracker 可用内存
在获取“进程可用内存”以后,系统需要将其换算成 Memory Tracker 可 track 的内存,“进程可用内存”与“Memory Tracker 可用内存”有一个换算公式;
memtracker_limit = ( total - FLAGS_memory_tracker_untracked_reserved_memory_mb ) * FLAGS_memory_tracker_limit_ratio
这里来详细展开说下 memory_tracker_limit_ratio
的使用:
在混合部署环境中,存在多个 graphd 或 storaged 混合部署是需要调小。比如 graphd 只占用 50% 内存,则需在 nebula-graphd.conf 中将其手动改成 0.5;
取值范围:
memory_tracker_limit_ratio
除了(0,1]
取值范围外,还额外定义了两个特殊值:2
:通过数据库内核感知当前系统运行环境的可用内存,动态调整可用内存。由于此种方式非实时,有一定的概率会感知不精准;3
:limit 将被设成一个极大值,起到关闭 Memory Tracker 的效果;
Memory Tracker 的设计与实现方案
下面,讲下 Memory Tracker 的设计与实现。整体的 Memory Tracker 设计,包含 Global new/delete operator、MemoryStats、system malloc、Limiter 等几个子模块。这个部分着重介绍下 Global new/delete operator 和 MemoryStats 模块。
Global new/delete operator
Memory Tracker 通过 overload 全局 new/delete operator,接管内存的申请和释放,从而做到在进行真正的内存分配之前,进行内存额度分配的管理。这个过程分解为两个步骤:
第一步:通过 MemoryStats 进行内存申请的汇报;
第二步:调用 jemalloc 发生真正的内存分配行为;
jemalloc:Memory Tracker 不改变底层的 malloc 机制,仍然使用 jemalloc 进行内存的申请和释放;
MemoryStats
全局的内存使用情况统计,通过 GlobalMemoryStats 和 ThreadMemoryStats 分别对全局内存和线程内部内存进行管理;
ThreadMemoryStats
thread_local
变量,执行引擎线程在各自的 ThreadMemoryStats 中维护线程的 MemoryStats,包括“内存 Reservation 信息”和“是否允许抛异常的 throwOnMemoryExceeded”;
Reservation
每个线程 reserve 了 1 MB 的内存 quota,从而避免频繁地向 GlobalMemoryStats 索要额度。不管是申请还是返还时,ThreadMemoryStats 都会以一个较大的内存块作为与全局交换的单位。
alloc:在本地 reserved 1 MB 内存用完了,才问全局要下一个 1 MB。通过此种方式来尽可能降低向全局 quota 申请内存的频率;
dealloc:返还的内存先加到线程的 reserved 中,当 reserve quota 超过 1 MB 时,还掉 1 MB,剩下的自己留着;
throwOnMemoryExceeded
线程在遇到超过内存额度时,是否 throw 异常。只有在设置 throwOnMemoryExceeded
为 true 时,才会 throw std::bad_alloc
。需要关闭 throw std::bad_alloc
场景见 Catch std::bac_alloc
章节。
GlobalMemoryStats
全局内存额度,维护了 limit 和 used 变量。
limit:通过运行环境和配置信息,换算得到 Memory Tracker 可管理的最大内存。limit 同 Limiter 模块的作用,详细内存换算见上文“Memory Tracker 可用内存”章节;
used:原子变量,汇总所有线程汇报上来的已使用内存(包括线程 reserved 的部分)。如果 used + try_to_alloc > limit,且在
throwOnMemoryExceeded
为 true 时,则会抛异常std::bac_alloc
。
Catch std::bac_alloc
由于 Memory Tracker overload new/delete 会影响所有线程,包括三方线程。此时,throw bad_alloc
在一些第三方线程可能出现非预期行为。为了杜绝此类问题发生,我们采用在代码路径上主动开启内存检测,选择在算子、RPC 等模块主动开启内存检测;
算子的内存检测
在 graph/storage 的各个算子中,添加 try...catch
(在当前线程进行计算/分配内存) 和 thenError
(通过 folly::Executor
异步提交的计算任务),感知 Memory Tracker 抛出 std::bac_alloc
。数据库再通过 Status 返回错误码,使查询失败;
在进行一些内存调试时,可通过打开 nebula-graphd.conf
文件中的 FLAGS_memory_tracker_detail_log
配置项,并调小 memory_tracker_detail_log_interval_ms
观察查询前后的内存使用情况;
folly::future 异步执行
同步执行
RPC 的内存检测
RPC 主要解决 Request/Response 对象的序列化/反序列化的内存额度控制问题,由于 storaged reponse 返回的数据均封装在 DataSet 数据结构中,所以问题转化为:DataSet 的序列化、反序列化过程中的内存检测。
序列化:DataSet 的对象构造在 NebulaGraph 算子返回结果逻辑中,默认情况下,已经开启内存检测;
反序列化:通过 MemoryCheckGuard
显式开启,在 StorageClientBase::getResponse's onError
可捕获异常;
错误码
为了便于分辨哪个模块发生问题,NebulaGraph 中还添加了相关错误码,分别表示 graphd 和 storaged 发生 memory exceeded 异常:
延伸阅读
什么是 malloc 以及动态内存分配:https://en.wikipedia.org/wiki/C_dynamic_memory_allocation
jemalloc
Facebook 对 jemalloc 的优化:https://engineering.fb.com/2011/01/03/core-data/scalable-memory-allocation-using-jemalloc/
谢谢你读完本文 (///▽///)
版权声明: 本文为 InfoQ 作者【NebulaGraph】的原创文章。
原文链接:【http://xie.infoq.cn/article/7f84f57014c0feb85d8f03465】。
本文遵守【CC BY-NC-ND】协议,转载请保留原文出处及本版权声明。
评论