couchbase元数据开销警告。62%的RAM被密钥和元数据占用

好吧，因为我没有10次重复，所以我无法发布图片，但我会尝试在文本中解释

我有一个7节点的Couchbase（社区）集群，有4个存储桶。 最近，我（经常）收到其中一个存储桶的元数据开销警告的垃圾邮件。。 弹出警告，如下所示：

ID=1:CAESEA---rldZ5PhdV4msSdEchI
CONTENT=z2TjZEzkZ84=

元数据开销警告。分配给节点“xxx”上存储桶XXXX的内存中有62%以上被密钥和元数据占用

我已经读到，这通常是一个信号，桶需要更多的内存。但我不认为这是我的问题。我猜我只是有很多元数据。 当我查看数据存储桶选项卡时，该存储桶具有RAM/配额使用率64GB/75GB。所以对我来说，大约有11GB（75-64GB）可用。

如果我查看Bucket AnalyticsVBUCKET RESOURCES指标，我会发现RAM中有59GB用户数据，RAM中有46GB元数据。因此，据我所知，一个内存总量为75GB的存储桶上应该有105GB的RAM

但这对我来说并不重要，很明显这里有些东西我不明白。 是的，75GB中的46GB约占62%。但是，59GB的用户数据应该在RAM中呢？

编辑： 典型的文档可以如下所示：

ID=1:CAESEA---rldZ5PhdV4msSdEchI
CONTENT=z2TjZEzkZ84=

还有我的问题。我该怎么办？这种情况在我的情况下是可以接受的。如果是这样，我是否更改该警告的阈值（由于某种原因，该警告设置为50%，因此我不建议读取该阈值）

还是分配更多内存？如果是这样的话，如果已经有11GB的可用空间，这对我有什么帮助

---

请帮助我澄清这些数字，并建议我是否需要采取任何行动。

首先，元数据使用的内存比例高并不一定会有问题，这只是意味着缓存实际文档的可用内存更少。如果您的应用程序运行良好，那么它可能适合您的用例。但是，话虽如此，我还是想试着回答一下您的问题，如果您确实想改进，那么应该改变什么：

如果我查看Bucket Analytics VBUCKET RESOURCES度量，我会发现RAM中有59GB的用户数据，RAM中有46GB的元数据。因此，据我所知，一个内存总量为75GB的存储桶上应该有105GB的RAM

IIRC“RAM中的用户数据”包括“RAM中的元数据”——因此您总共使用了59 GB的数据，其中46 GB是元数据

还有我的问题。我该怎么办？这种情况在我的情况下是可以接受的。如果是这样，我是否更改该警告的阈值（由于某种原因，该警告设置为50%，因此我不建议读取该阈值）。 还是分配更多内存？如果是这样的话，如果已经有11GB的可用空间，这对我有什么帮助

因此，基本上您存储了大量非常小的文档，因此与实际文档大小相比，每个文档的元数据开销（约48字节加上密钥长度）非常高

11GB自由空间主要由桶配额和高水印之间的差异构成

以下是一些改进方法：

为存储桶分配更多RAM（如您所述）-如果服务器配额中有任何未分配的内存

向节点添加更多内存（并分配给服务器配额和存储桶）

减少副本的数量（如果您可以接受的话）-目前您基本上要将每个对象（及其元数据）存储三次-一次用于活动vBucket，两次用于两个副本vBucket集

将文档更改为具有较短的键-这将减少每个文档的平均元数据

将多个文档合并为一个——这将减少文档数量，从而减少总体元数据开销

---

现在我有+10个重复，我是否要添加屏幕截图？这~2亿个对象的平均值大小是多少？每个节点运行多少RAM？并不是说它是完全相关的，但看起来您正在使用交换空间。您使用的是什么操作系统，如果是Linux，您的交换设置为0。另外，我看到您在RAM中驻留的对象只有5.27%。这是故意的吗？因为你正在弹出很多东西。关键是大约29字节。值约为8字节。Linux，256GB内存/节点，swappiness=0在新项目激增时拍摄的屏幕截图。从50米到200米左右。现在已经稳定，缓存未命中率为0.115，活动文档为43%（仍然很低），couchbase使用了大约66%的RAM。Rest由缓存使用。使用swap being的原因是swappiness在前一段时间被设置为1。我猜这只是交换的残余，从那以后就再也没有被访问过。。但是我现在也为这个桶分配了更多的内存。因为我有备用的公羊。但为了更长远的解决方案，我想我会尝试做4。五,。