Linux Aerospike进程占用大量内存

Aerospike社区版构建3.12.0

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

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

2018年9月29日15:36:21 GMT+0530:INFO（信息）：（股票代码c:170）节点ID bb99a89200a0102集群大小32

2018年9月29日15:36:21 GMT+0530:INFO（信息）：（ticker.c:253）系统内存：空闲KB 5095788空闲pct 9堆KB（308511704935807652596736）堆效率pct 58.7

2018年9月29日15:36:21 GMT+0530:INFO（信息）：（股票代码c:267）进行中：tsvc-q 0 INFO-q 0 nsup-delete-q 0 rw哈希0代理哈希0 tree-gc-q 0

所以我所理解的是它有（23816040182+322210368）=27038850550字节27G。我的盒子上有52克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中看到以下内容：

因此，数据+索引仅为27G，而使用的内存为49G。无法理解这种巨大的差异以及如何避免这种情况

---

我们还删除了大约1.2亿行，但在内存使用方面仍然没有太大的改进，唯一的选项似乎是重新启动该框，这可能与此有关。

您的内存实际上是碎片化的，但让我们对不同的数字进行细分：

1-

内存使用：总字节23816040182索引字节322810368 sindex字节0数据字节20593229814已使用pct 49.29

占用的总内存为23816040182字节（~22.18 GiB），这是主索引322810368（50356412条记录，每个记录64字节）和数据本身（内存中的数据）的总和，即20593229814（~19.2 GiB）。主索引部分位于共享内存中

2-

系统内存：可用KB 5095788可用pct 9堆KB（308511704935807652596736）堆效率pct 58.7

报告的可用系统内存在版本3.12中不准确。不幸的是，您的可用性较低（请参阅版本3.16.0.4中可用的修复[AER-5810]-（STATS）Log ticker over reports free system memory）

更有趣的是堆的使用情况，（来自），您可以将其理解为：

• 堆KB—顺序为：（，）

• 堆效率pct：提供jemalloc堆碎片的指示。这表示堆\u分配的\u KB/堆\u映射的\u KB比率。数字越小表示碎片率越高

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

---

然而，主要问题是效率低下，即碎片化。您是否有可能启用THP？事实上，我找到了这篇文章（），其中还介绍了内存报告的细节，以及可能导致这种情况的巨大页面配置

看起来你的记忆实际上是碎片化的，但让我们把不同的数字细分：

1-

内存使用：总字节23816040182索引字节322810368 sindex字节0数据字节20593229814已使用pct 49.29

占用的总内存为23816040182字节（~22.18 GiB），这是主索引322810368（50356412条记录，每个记录64字节）和数据本身（内存中的数据）的总和，即20593229814（~19.2 GiB）。主索引部分位于共享内存中

2-

系统内存：可用KB 5095788可用pct 9堆KB（308511704935807652596736）堆效率pct 58.7

报告的可用系统内存在版本3.12中不准确。不幸的是，您的可用性较低（请参阅版本3.16.0.4中可用的修复[AER-5810]-（STATS）Log ticker over reports free system memory）

更有趣的是堆的使用情况，（来自），您可以将其理解为：

• 堆KB—顺序为：（，）

• 堆效率pct：提供jemalloc堆碎片的指示。这表示堆\u分配的\u KB/堆\u映射的\u KB比率。数字越小表示碎片率越高

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

然而，主要问题是效率低下，即碎片化。您是否有可能启用THP？事实上，我找到了这篇文章（），其中还介绍了内存报告的细节，以及可能导致这种情况的巨大页面配置