常见问题解答：MongoDB 诊断

调整 TCP keepalive 值：

为使新的系统范围的 keepalive 设置生效，需要重新启动 mongod 和 mongos 进程。

调整 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 内部缓存和文件系统缓存。

从 MongoDB 3.4 开始，默认 WiredTiger 内部缓存大小为以下两者中的较大者：

• （RAM 大小 - 1 GB）的 50%，或

• 256 MB。

例如，在总 RAM 为 4GB 的系统上，WiredTiger 缓存使用 1.5GB RAM (0.5 * (4 GB - 1 GB) = 1.5 GB)。相反，在总 RAM 为 1.25GB 的系统上，WiredTiger 为 WiredTiger 缓存分配了 256 MB，因为这大于总 RAM 的一半减去 1 GB (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。

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

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

集群必须有足够的数据才能进行分片。分片的工作原理是在分片之间迁移数据段，直到每个分片具有大致相同数量的数据段。

默认数据段大小为 128 MB。直到集群中数据段的不均衡超出迁移阈值，MongoDB 才会开始迁移。这种行为有助于防止不必要的数据段迁移，此类迁移可能会降低整个集群的性能。

如果您刚刚部署了分片集群，请确保您有足够的数据来使分片有效。如果您没有足够的数据来创建超过八个 128 MB 的数据段，那么所有数据将保留在一个分片上。降低数据段大小设置，或向集群添加更多数据。

与此相关的问题是，系统只会在插入或更新时分割数据段，这意味着如果配置分片，但不继续进行插入和更新操作，则数据库将不会创建任何数据段。您可以等待应用程序插入数据，也可以手动分割数据段。

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

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

在某些情况下，单个分片或集群的子集会收到不成比例的流量和工作负载。在几乎所有情况下，这都是由于分片键无法有效允许写入扩展而造成的。

您也有可能有“热数据段”。在这种情况下，您也许可以通过分割然后迁移这些数据段的部分内容，来解决问题。

您可能需要考虑使用不同的分片键来对集合进行重新分片，以纠正这种模式。

什么因素可能会阻止分片集群进行均衡？

如果刚刚部署了分片集群，您可能希望考虑数据保留在单个分片上的新集群的故障排除建议。

如果集群最初是均衡的，但后来逐渐出现了数据分布不均匀的情况，请考虑以下可能的原因：

• 您已从集群中删除大量数据。如果您添加了其他数据，其分片键可能具有不同的分配情况。

• 您的分片键具有较低的关联基数，MongoDB 无法进一步拆分数据段。

• 数据集增长速度超过了负载均衡器向集群分发数据的速度。这种情况并不常见，通常由以下原因所致：

  • 考虑到数据增长率，负载均衡窗口太短。

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

  • 分片之间的网络连接较差，这可能导致数据段迁移需要太长时间才能完成。调查您的网络配置以及分片之间的互连。

为什么数据段迁移影响分片集群性能？

如果迁移影响集群或应用程序性能，请根据影响性质考虑以下选项：

1. 如果迁移只是偶尔导致集群中断，则可以限制均衡窗口，防止在高峰时段进行均衡活动。确保留出足够的剩余时间，以防数据再次失衡。

2. 如果均衡器始终会迁移数据段，导致集群整体性能受损：

   • 您可能需要尝试减小数据段的大小，从而限制迁移的大小。

   • 集群可能已过载，您可能需要尝试在集群中添加一两个分片以分散负载。

您的分片键也可能导致您的应用程序将所有写入定向到单个分片。 这种活动模式可能要求负载均衡器在写入数据后立即迁移大多数数据。 您可能需要考虑使用不同的分片键对您的集合进行重新分片，以提供更好的写入扩展比例。