【问题标题】:Couchbase Metadata overhead warningCouchbase 元数据开销警告
【发布时间】:2014-05-26 16:37:19
【问题描述】:

我有一个具有以下规格的 Couchbase (v 2.0.1) 集群:

  • 5 个节点
  • 1 桶
  • 每个节点 16 GB RAM(总计 80 GB)
  • 每个节点 200GB 磁盘(总计 1Tb)

目前我在这个存储桶中有 201.000.000 个文档,并且只有 200GB 的磁盘在使用中。

对于每个节点,我每分钟都会收到以下警告:

Metadata overhead warning. Over 51% of RAM allocated to bucket "my-bucket" on node "my-node" is taken up by keys and metadata. 

Couchbase 文档声明如下:

表示一个存储桶现在正在使用超过 50% 的已分配空间 RAM 用于存储元数据和密钥,减少 RAM 量 可用于数据值。

我知道这可能是一个有用的指标,表明我可能需要将节点添加到我的集群中,但我认为考虑到存储桶可用的资源量,这不是必需的。

常规存储桶分析:

我怎么知道是什么产生了这么多元数据?

有没有办法配置容差百分比?

【问题讨论】:

    标签: couchbase nosql


    【解决方案1】:

    每个文档都有元数据和存储在内存中的密钥。元数据为 56 个字节。将其添加到您的平均密钥大小,并将结果乘以您的文档计数,以得出元数据和内存中密钥的总字节数。因此所需的 RAM 受文档计数、密钥大小和副本数(副本数 + 1)的影响。您可以在http://docs.couchbase.com/couchbase-manual-2.5/cb-admin/#memory-quota 找到详细信息。具体公式为:

    (documents_num) * (metadata_per_document + ID_size) * (no_of_copies)
    

    您可以从控制台(或通过 REST 或命令行界面)获取有关集群使用的用户和元数据的详细信息。查看“VBUCKET RESOURCES”部分。感兴趣的具体值是“RAM 中的用户数据”和“RAM 中的元数据”。从您的屏幕截图中,您肯定会耗尽您的内存容量。您已超过低水位线,因此系统将从内存中弹出不活动的副本文档。如果您越过高水位线,系统将开始从内存中弹出活动文档,直到达到低水位线。任何对弹出文档的请求都需要后台磁盘提取。从您的屏幕截图中,您的内存中的活动文档已经不到 5%。

    可以在 2.5.1 版本中更改警告元数据警告阈值。您可以使用位于https://gist.github.com/fprimex/11368614 的脚本。或者,您可以简单地利用脚本中的 curl 命令并为您的集群插入正确的值。据我所知,这在 2.5.1 之前不起作用。

    请记住,虽然这些警报(最大开销和最大磁盘使用量)现在可以调整,但它们的存在是有原因的。以默认值触发这些警报中的任何一个(尤其是在生产中)是一个值得关注的主要原因,应该通过增加每个节点上的 RAM 和/或磁盘或添加节点来尽快处理。这些值可针对特殊情况进行调整。即使在开发/测试场景中,如果您遇到这些警报,您的节点性能也可能会受到严重影响。例如,如果您的节点的 RAM 超过 50% 被元数据占用,则不要对基准测试结果下结论。

    【讨论】:

    • 正如你提到的升级到 2.5.1。值得指出的是,在以后的版本中,弹出策略更改为现在只有在达到高水位线后才会弹出数据。
    • 嗨,我添加了 VBucket 资源。应用公式:(207000000 项 × (56+27) 字节 ×2 份)= 34362000000 字节 ~ 32GB。据此,它不应达到 RAM 的 50%。有什么方法可以不将元数据保存在内存中?谢谢
    • 我从新的 VBUCKET RESOURCES 屏幕截图中看到元数据 RAM 使用情况显示为 36.8GB。这有点接近您的 ~32GB 计算。也许密钥大小在计算中略有偏差。当然,在处理大量文档时会放大一个小的差异。至于不保存元数据,在 2.5.1 及更早的版本中没有办法实现。在下一个版本中,Couchbase 计划提供一个可调内存功能,允许您有选择地弹出元数据和从内存中弹出的文档的密钥。这将有助于低居民百分比的场景。
    猜你喜欢
    • 2015-12-12
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2018-07-22
    • 2021-03-11
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多