Memory Tracker de la pratique de gestion de la mémoire de la base de données de graphes NebulaGraph

La gestion de la mémoire de la base de données est un module important dans la conception du noyau de la base de données, et la mémoire mesurable et contrôlable est une garantie importante pour la stabilité de la base de données. De même, la gestion de la mémoire est également essentielle pour la base de données de graphes NebulaGraph.

La fonctionnalité de requête relationnelle à plusieurs degrés de la base de données de graphes fait souvent que la couche d'exécution de la base de données de graphes a une énorme demande de mémoire. Cet article présente principalement la nouvelle fonctionnalité Memory Tracker introduite dans NebulaGraph v3.4. On espère que grâce à l'introduction du module Memory Tracker, un contrôle précis de l'utilisation de la mémoire pourra être réalisé, le risque que graphd et storaged soient OOM tués par le sera réduite et les performances de la base de données de graphes NebulaGraph seront améliorées Stabilité du noyau.

Note : Afin de garder la correspondance avec le code, certains des mots utilisés dans cet article utilisent directement l'anglais, par exemple reserve memory quota.

mémoire disponible

Avant l'introduction de Memory Tracker, voici les connaissances de base pertinentes : la mémoire disponible.

Traiter la mémoire disponible

Ici, nous présentons brièvement comment le système évalue la mémoire disponible dans chaque mode.

mode machine physique

Le noyau de la base de données lira le répertoire système /proc/meminfopour déterminer la mémoire réelle et la mémoire restante de l'environnement actuel. Memory Tracker considère la "mémoire physique réelle" comme "la mémoire maximale qu'un processus peut utiliser" ;

Mode conteneur/groupe de contrôle

Il existe un élément de configuration dans nebula-graphd.confle fichier FLAG_containerizedpour déterminer si la base de données est en cours d'exécution sur le conteneur. Après avoir défini FLAG_containerized(la valeur par défaut est false) sur true, le noyau lira les fichiers sous le chemin du cgroup approprié pour déterminer la quantité de mémoire que le processus actuel peut utiliser ; cgroup a deux versions, v1 et v2, ici nous prenons v2 comme exemple ;

DRAPEAU	Valeurs par défaut	expliquer
FLAG_cgroup_v2_memory_max_path	/sys/fs/cgroup/memory.max	Déterminer l'utilisation maximale de la mémoire par chemin de lecture
FLAG_cgroup_v2_memory_current_path	/sys/fs/cgroup/memory.current	通过读取路径确定当前内存使用量

举个例子，在单台机器上分别控制 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 添加相关配置

--containerized=true
--cgroup_v2_controllers=/sys/fs/cgroup/graphd/cgroup.controllers
--cgroup_v2_memory_stat_path=/sys/fs/cgroup/graphd/memory.stat
--cgroup_v2_memory_max_path=/sys/fs/cgroup/graphd/memory.max
--cgroup_v2_memory_current_path=/sys/fs/cgroup/graphd/memory.current

Memory Tracker 可用内存

在获取“进程可用内存”以后，系统需要将其换算成 Memory Tracker 可 track 的内存，“进程可用内存”与“Memory Tracker 可用内存”有一个换算公式；

memtracker_limit = ( total - FLAGS_memory_tracker_untracked_reserved_memory_mb ) * FLAGS_memory_tracker_limit_ratio

usable_memory

FLAG	默认值	解释	支持动态改
memory_tracker_untracked_reserved_memory_mb	50 M	Memory Tracker 会管理通过 new/delete 申请的内存，但进程除了通过此种方式申请内存外，还可能存在其他方式占用的内存；比如通过调用底层的 malloc/free 申请，这些内存通过此 flag 控制，在计算时会扣除此部分未被 track 的内存。	Yes
memory_tracker_limit_ratio	0.8	指定 Memory Tracker 可以使用的内存比例，在一些场景，我们可能需要调小来防止 OOM。	Yes

这里来详细展开说下 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 模块。

memory_tracker

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，剩下的自己留着；

 // Memory stats for each thread.
 struct ThreadMemoryStats {
   ThreadMemoryStats();
   ~ThreadMemoryStats();
 
   // reserved bytes size in current thread
   int64_t reserved;
   bool throwOnMemoryExceeded{false};
 };

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 异步执行

thenValue([this](StorageRpcResponse<GetNeighborsResponse>&& resp) {
    memory::MemoryCheckGuard guard;
    // memory tracker turned on code scope
    return handleResponse(resp);
})
.thenError(folly::tag_t<std::bad_alloc>{},
    [](const std::bad_alloc&) {
    // handle memory exceed
})

同步执行

memory::MemoryCheckGuard guard; \
try {
    // ...
} catch (std::bad_alloc & e) { \
    // handle memory exceed
}

RPC 的内存检测

RPC 主要解决 Request/Response 对象的序列化/反序列化的内存额度控制问题，由于 storaged reponse 返回的数据均封装在 DataSet 数据结构中，所以问题转化为：DataSet 的序列化、反序列化过程中的内存检测。

序列化：DataSet 的对象构造在 NebulaGraph 算子返回结果逻辑中，默认情况下，已经开启内存检测；

反序列化：通过 MemoryCheckGuard 显式开启，在 StorageClientBase::getResponse's onError 可捕获异常；

错误码

为了便于分辨哪个模块发生问题，NebulaGraph 中还添加了相关错误码，分别表示 graphd 和 storaged 发生 memory exceeded 异常：

E_GRAPH_MEMORY_EXCEEDED = -2600, // Graph memory exceeded
E_STORAGE_MEMORY_EXCEEDED = -3600, // Storage memory exceeded