常见问题：自管理 MongoDB 诊断

调整TCP保活值：

您需要重新启动mongod和mongos进程，以便新的系统级keepalive设置生效。

调整 TCP 重传超时

我的工作集大小是否必须适合 RAM？

不。

如果缓存没有足够的空间来加载更多数据，WiredTiger 会从缓存中逐页删除以腾出空间。

默认的WiredTiger内部缓存大小假设每台机器上只有一个 mongod 实例。如果一台机器上包含多个MongoDB实例，则应降低此设置以适应其他 mongod 实例。

如果您在一个容器（例如，lxc、cgroups、Docker等）中运行 mongod，而这个容器无法访问系统中的全部RAM，您必须将 storage.wiredTiger.engineConfig.cacheSizeGB 设置为一个小于容器中可用RAM的值。确切的数量取决于容器中运行的其他进程。请参阅 memLimitMB。

要查看缓存和驱逐的统计信息，请使用 serverStatus 命令。字段 wiredTiger.cache 包含有关缓存和驱逐的信息。

...
"wiredTiger" : {
   ...
   "cache" : {
      "tracked dirty bytes in the cache" : <num>,
      "bytes currently in the cache" : <num>,
      "maximum bytes configured" : <num>,
      "bytes read into cache" :<num>,
      "bytes written from cache" : <num>,
      "pages evicted by application threads" : <num>,
      "checkpoint blocked page eviction" : <num>,
      "unmodified pages evicted" : <num>,
      "page split during eviction deepened the tree" : <num>,
      "modified pages evicted" : <num>,
      "pages selected for eviction unable to be evicted" : <num>,
      "pages evicted because they exceeded the in-memory maximum" : <num>,,
      "pages evicted because they had chains of deleted items" : <num>,
      "failed eviction of pages that exceeded the in-memory maximum" : <num>,
      "hazard pointer blocked page eviction" : <num>,
      "internal pages evicted" : <num>,
      "maximum page size at eviction" : <num>,
      "eviction server candidate queue empty when topping up" : <num>,
      "eviction server candidate queue not empty when topping up" : <num>,
      "eviction server evicting pages" : <num>,
      "eviction server populating queue, but not evicting pages" : <num>,
      "eviction server unable to reach eviction goal" : <num>,
      "pages split during eviction" : <num>,
      "pages walked for eviction" : <num>,
      "eviction worker thread evicting pages" : <num>,
      "in-memory page splits" : <num>,
      "percentage overhead" : <num>,
      "tracked dirty pages in the cache" : <num>,
      "pages currently held in the cache" : <num>,
      "pages read into cache" : <num>,
      "pages written from cache" : <num>,
   },
   ...

有关一些关键缓存和驱逐统计信息的说明，例如 wiredTiger.cache.bytes currently in the cache 和 wiredTiger.cache.tracked dirty bytes in the cache，请参阅 wiredTiger.cache。

要调整WiredTiger内部缓存的大小，请参阅 storage.wiredTiger.engineConfig.cacheSizeGB 和 --wiredTigerCacheSizeGB。避免将WiredTiger内部缓存大小增加到其默认值以上。

我该如何计算我应用程序需要的多少RAM?

使用WiredTiger，MongoDB同时利用WiredTiger内部缓存和文件系统缓存。

默认的WiredTiger内部缓存大小是以下两者中较大的一个：

• RAM的50%（减去1 GB），或

• 256 MB。

例如，在一个总共有4GB RAM的系统上，WiredTiger缓存使用1.5GB的RAM（0.5 * (4 GB - 1 GB) = 1.5 GB）。相反，在一个总共有1.25GB RAM的系统上，WiredTiger将256 MB分配给WiredTiger缓存，因为这比总RAM减去1GB的一半还多（0.5 * (1.25 GB - 1 GB) = 128 MB < 256 MB）。

默认情况下，WiredTiger为所有集合使用Snappy块压缩，并为所有索引使用前缀压缩。压缩默认值可在全局级别进行配置，也可以在创建集合和索引时按集合和索引设置。

在WiredTiger内部缓存与磁盘格式之间使用不同的数据表示形式

• 文件系统缓存中的数据与磁盘格式相同，包括数据文件压缩的任何好处。文件系统缓存由操作系统用于减少磁盘I/O。

• 在WiredTiger内部缓存中加载的索引与磁盘格式有不同的数据表示形式，但仍然可以利用索引前缀压缩来减少RAM使用。索引前缀压缩从索引字段中删除常见的公共前缀。

• WiredTiger内部缓存中的集合数据未压缩，并使用与磁盘格式不同的表示形式。块压缩可以提供显著的磁盘存储节省，但数据必须未压缩才能由服务器进行操作。

使用文件系统缓存，MongoDB自动使用WiredTiger缓存或其他进程未使用的所有空闲内存。

要调整WiredTiger内部缓存的大小，请参阅 storage.wiredTiger.engineConfig.cacheSizeGB 和 --wiredTigerCacheSizeGB。避免将WiredTiger内部缓存大小增加到其默认值以上。

默认的WiredTiger内部缓存大小假设每台机器上只有一个 mongod 实例。如果一台机器上包含多个MongoDB实例，则应降低此设置以适应其他 mongod 实例。

如果您在一个容器（例如，lxc、cgroups、Docker等）中运行 mongod，而这个容器无法访问系统中的全部RAM，您必须将 storage.wiredTiger.engineConfig.cacheSizeGB 设置为一个小于容器中可用RAM的值。确切的数量取决于容器中运行的其他进程。请参阅 memLimitMB。

要查看缓存和驱逐率的统计信息，请查看wiredTiger.cache字段，该字段由serverStatus命令返回。

在一个新的分片集群中，为什么所有数据都保留在一个分片上？

您的集群必须有足够的数据才能使分片有意义。分片通过在分片之间迁移数据块，直到每个分片具有大致相同数量的数据块来实现。

默认数据块大小为128兆字节。MongoDB将在集群中数据块的不平衡超过迁移阈值之前不会开始迁移。此行为有助于防止不必要的块迁移，这可能会降低集群的整体性能。

如果您刚刚部署了一个分片集群，请确保您有足够的数据使分片有效。如果您没有足够的数据来创建超过八个128兆字节的数据块，则所有数据都将保留在一个分片上。您可以选择降低数据块大小设置，或者向集群添加更多数据。

作为一个相关问题，系统仅在插入或更新时拆分数据块，这意味着如果您配置了分片但不继续执行插入和更新操作，数据库将不会创建任何数据块。您可以选择等待您的应用程序插入数据或 手动拆分数据块。

最后，如果您的分片键的基数较低，MongoDB可能无法在数据中创建足够的拆分。

为什么在分片集群中一个分片会收到不成比例的流量？

在某些情况下，单个分片或集群的一部分将接收到不成比例的流量和工作负载。在几乎所有情况下，这是由于分片键没有有效地允许写入扩展。

还可能存在“热点数据块”。在这种情况下，您可能可以通过拆分并迁移这些数据块的部分来解决该问题。

您可能需要考虑使用不同的分片键重新分片您的集合来纠正此模式。选择不同的分片键。

什么可以阻止分片集群平衡？

如果您刚刚部署了您的分片集群，您可能需要考虑针对数据仍然保留在单个分片的新集群的故障排除建议。

如果集群最初是平衡的，但后来数据分布不均，请考虑以下可能的原因

• 您已从集群中删除或删除了大量数据。如果您已添加附加数据，它可能具有与分片键相关的不同分布。

• 您的分片键具有低基数，MongoDB无法进一步分割数据块。

• 数据集的增长速度快于平衡器在集群中分配数据的能力。这很少见，通常是以下结果

  • 给定数据增长速度，平衡窗口太短。

  • 写入操作的不均匀分布需要更多数据迁移。您可能需要选择不同的分片键来解决此问题。

  • 分片之间的网络连接性差，可能导致迁移数据块耗时过长。调查您的网络配置和分片之间的互连。

为什么分片迁移会影响分片集群的性能?

如果迁移影响了您的集群或应用程序的性能，请考虑以下选项，具体取决于影响性质

1. 如果迁移只是偶尔中断您的集群，您可以限制平衡窗口以防止在高峰时段进行平衡活动。确保有足够的时间来防止数据再次变得不平衡。

2. 如果平衡器总是以损害整体集群性能的方式迁移分片

   • 您可能想要尝试减小分片大小以限制迁移的大小。

   • 您的集群可能已经过载，您可能想要尝试向集群添加一个或两个分片以分散负载。

也可能是因为您的分片键导致您的应用程序将所有写入操作都导向单个分片。这种活动模式可能需要平衡器在写入后不久迁移大部分数据。您可能需要考虑使用重新分片集合并使用提供更好分片键来提供更好的写入扩展性。