Aerospike 进程占用大量内存答案

【问题标题】：Aerospike process taking lot of memoryAerospike 进程占用大量内存
【发布时间】：2018-09-29 10:33:16
【问题描述】：

Aerospike 社区版构建 3.12.0

我们有一个由 32 个节点组成的集群，其中一个命名空间有多个集合。我在日志中看到以下内容：

2018 年 9 月 29 日 15:36:21 GMT+0530：INFO（信息）：（ticker.c:462）{myNamespace} 内存使用：总字节 23816040182 索引字节 3222810368 sindex 字节 0 数据字节 20593229814使用-pct 49.29

2018 年 9 月 29 日 15:36:21 GMT+0530: INFO (info): (ticker.c:170) NODE-ID bb99a89200a0102 CLUSTER-SIZE 32

2018 年 9 月 29 日 15:36:21 GMT+0530: INFO (info): (ticker.c:253) system-memory: free-kbytes 5095788 free-pct 9 heap-kbytes (30851170,49358076,52596736) heap -效率-pct 58.7

2018 年 9 月 29 日 15:36:21 GMT+0530：信息（信息）：（ticker.c:267）进行中：tsvc-q 0 info-q 0 nsup-delete-q 0 rw-hash 0 代理-hash 0 树-gc-q 0

所以我的理解是这有 (23816040182+3222810368) = 27038850550 字节i.e. 27G。我的盒子上有 52G RAM，但 aerospike 进程消耗了 90% 的 RAM：

>ps aux  | grep asd
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND    
root     28994 14.3 90.5 59059460 49552192 ?   Ssl  Jun22 20539:09 /usr/bin/asd --config-file /etc/aerospike/aerospike.conf


>free -mh
             total       used       free     shared    buffers     cached
Mem:           52G        51G       303M         0B        12M       3.7G
-/+ buffers/cache:        48G       4.0G
Swap:           0B         0B         0B

对于同一节点，我在 UI 中看到以下内容：

所以，Data + index 只有 27G，而使用的内存是 49G。无法理解这种巨大的差异以及如何避免这种情况。

我们也删除了大约1.2亿行，但在内存使用方面仍然没有太大改善，唯一的选项似乎是重启盒子，这可能与这个issue有关。

【问题讨论】：

标签： linux ram aerospike

【解决方案1】：

看起来你的记忆实际上是支离破碎的，但让我们分解一下不同的数字：

1-memory-usage: total-bytes 23816040182 index-bytes 3222810368 sindex-bytes 0 data-bytes 20593229814 used-pct 49.29

占用的总内存为 23816040182 字节（~22.18 GiB），这是您在主索引 3222810368（50,356,412 条记录，每条 64 字节）和数据本身（因为您是内存中的数据）中的总和)，即 20593229814 (~19.2 GiB)。主索引部分位于共享内存中。

2-system-memory: free-kbytes 5095788 free-pct 9 heap-kbytes (30851170,49358076,52596736) heap-efficiency-pct 58.7

报告的可用系统内存在 3.12 版本中不准确。不幸的是，您的可用内存较少（请参阅修复 [AER-5810] - (STATS) 日志记录器过度报告版本 3.16.0.4 中可用的可用系统内存）。

更有趣的是堆的使用，（来自log reference manual）你可以读作：

heap-kbytes - 按顺序：（heap_allocated_kbytes、heap_active_kbytes、heap_mapped_kbytes）。
heap-efficiency-pct：提供 jemalloc 堆碎片的指示。这表示 heap_allocated_kbytes / heap_mapped_kbytes 比率。数字越小，碎片率越高。

您分配了 30851170 KiB（约 29.4 GiB），但总共分配了 52596736 KiB（映射约 50.1 GiB），这表明效率不高（效率为 58.7%），表明存在一些碎片。顺便说一下，这不包括共享内存。对于 19 GiB 的数据，分配的 29 GiB 似乎有点高。我本来期望使用的所有其他内部结构的开销更少。

主要问题是效率低下，但碎片化。您是否有任何机会启用了 THP？我实际上找到了这篇文章 (Understanding Linux Memory Usage)，它还查看了那些内存报告详细信息并查看了可能导致此问题的 Huge Pages 配置。

【讨论】：