FAQ: Self-Managed MongoDB Diagnostics常见问题解答：自我管理MongoDB诊断

Adjusting the TCP keepalive value:调整TCP保活值：

You will need to restart mongod and mongos processes for new system-wide keepalive settings to take effect.您需要重新启动mongod和mongos进程，以便新的系统范围保活设置生效。

Adjust the TCP Retransmission Timeout调整TCP重传超时

Must my working set size fit RAM?我的工作集大小必须适合RAM吗？

No.不。

If the cache does not have enough space to load additional data, WiredTiger evicts pages from the cache to free up space.如果缓存没有足够的空间加载其他数据，WiredTiger会从缓存中驱逐页面以释放空间。

The default WiredTiger internal cache size value assumes that there is a single mongod instance per machine. 默认的WiredTiger内部缓存大小值假定每台机器只有一个mongod实例。If a single machine contains multiple MongoDB instances, decrease the setting to accommodate the other mongod instances.如果一台机器包含多个MongoDB实例，请减小设置以容纳其他MongoDB实例。

If you run mongod in a container (for example, lxc, cgroups, Docker, etc.) that does not have access to all of the RAM available in a system, you must set storage.wiredTiger.engineConfig.cacheSizeGB to a value less than the amount of RAM available in the container. 如果你在一个无法访问系统中所有可用RAM的容器（例如lxc、cgroups、Docker等）中运行mongod，你必须将storage.wiredTiger.engineConfig.cacheSizeGB设置为小于容器中可用RAM量的值。The exact amount depends on the other processes running in the container. See memLimitMB.确切的数量取决于容器中运行的其他进程。请参阅memLimitMB。

You can only provide one of either storage.wiredTiger.engineConfig.cacheSizeGB or storage.wiredTiger.engineConfig.cacheSizePct.您只能提供storage.wiredTiger.engineConfig.cacheSizeGB或storage.wiredTiger.engineConfig.cacheSizePct中的一个。

To see statistics on the cache and eviction, use the serverStatus command. The wiredTiger.cache field holds the information on the cache and eviction.要查看缓存和驱逐的统计信息，请使用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>,
   },
   ...

For an explanation of some key cache and eviction statistics, such as wiredTiger.cache.bytes currently in the cache and wiredTiger.cache.tracked dirty bytes in the cache, see wiredTiger.cache.有关某些关键缓存和驱逐统计信息的解释，例如当前缓存中的wiredTiger.cache.bytes currently in the cache和缓存中wiredTiger.cache.tracked脏字节，请参阅wiredTigercache。

To adjust the size of the WiredTiger internal cache, see --wiredTigerCacheSizeGB and storage.wiredTiger.engineConfig.cacheSizeGB. 要调整WiredTiger内部缓存的大小，请参阅--wiredTigerCacheSizeGB和storage.wiredTiger.engineConfig.cacheSizeGB。Avoid increasing the WiredTiger internal cache size above its default value. 避免将WiredTiger内部缓存大小增加到默认值以上。If your use case requires increased internal cache size, see --wiredTigerCacheSizePct and storage.wiredTiger.engineConfig.cacheSizePct.如果用例需要增加内部缓存大小，请参阅--wiredTigerCacheSizePct和storage.wiredTiger.engineConfig.cacheSizePct。

How do I calculate how much RAM I need for my application?如何计算我的应用程序需要多少RAM？

With WiredTiger, MongoDB utilizes both the WiredTiger internal cache and the filesystem cache.使用WiredTiger，MongoDB同时利用WiredTigeer内部缓存和文件系统缓存。

The default WiredTiger internal cache size is the larger of either:默认的WiredTiger内部缓存大小是以下两者中的较大值：

• 50% of (RAM - 1 GB), or
• 256 MB.

For example, on a system with a total of 4GB of RAM the WiredTiger cache uses 1.5GB of RAM (0.5 * (4 GB - 1 GB) = 1.5 GB). 例如，在总共有4GB RAM的系统上，WiredTiger缓存使用1.5GB RAM（0.5 * (4 GB - 1 GB) = 1.5 GB）。Conversely, on a system with a total of 1.25 GB of RAM WiredTiger allocates 256 MB to the WiredTiger cache because that is more than half of the total RAM minus one gigabyte (0.5 * (1.25 GB - 1 GB) = 128 MB < 256 MB).相反，在总共有1.25 GB RAM的系统上，WiredTiger将256 MB分配给WiredTigeer缓存，因为这超过了总RAM减去1 GB的一半（0.5 * (1.25 GB - 1 GB) = 128 MB < 256 MB）。

By default, WiredTiger uses Snappy block compression for all collections and prefix compression for all indexes. Compression defaults are configurable at a global level and can also be set on a per-collection and per-index basis during collection and index creation.默认情况下，WiredTiger对所有集合使用Snappy块压缩，对所有索引使用前缀压缩。压缩默认值可以在全局级别进行配置，也可以在集合和索引创建期间根据每个集合和每个索引进行设置。

Different representations are used for data in the WiredTiger internal cache versus the on-disk format:与磁盘格式相比，WiredTiger内部缓存中的数据使用了不同的表示方式：

• Data in the filesystem cache is the same as the on-disk format, including benefits of any compression for data files. The filesystem cache is used by the operating system to reduce disk I/O.文件系统缓存中的数据与磁盘上的格式相同，包括对数据文件进行任何压缩的好处。操作系统使用文件系统缓存来减少磁盘I/O。
• Indexes loaded in the WiredTiger internal cache have a different data representation to the on-disk format, but can still take advantage of index prefix compression to reduce RAM usage. Index prefix compression deduplicates common prefixes from indexed fields.加载在WiredTiger内部缓存中的索引具有与磁盘上格式不同的数据表示形式，但仍然可以利用索引前缀压缩来减少RAM使用。索引前缀压缩可消除索引字段中的常见前缀的重复。
• Collection data in the WiredTiger internal cache is uncompressed and uses a different representation from the on-disk format. Block compression can provide significant on-disk storage savings, but data must be uncompressed to be manipulated by the server.WiredTiger内部缓存中的集合数据是未压缩的，并使用与磁盘格式不同的表示形式。块压缩可以显著节省磁盘存储空间，但数据必须解压缩才能由服务器操作。

With the filesystem cache, MongoDB automatically uses all free memory that is not used by the WiredTiger cache or by other processes.使用文件系统缓存，MongoDB会自动使用WiredTiger缓存或其他进程未使用的所有空闲内存。

To adjust the size of the WiredTiger internal cache, see --wiredTigerCacheSizeGB and storage.wiredTiger.engineConfig.cacheSizeGB. 要调整WiredTiger内部缓存的大小，请参阅--wiredTigerCacheSizeGB和storage.wiredTiger.engineConfig.cacheSizeGB。Avoid increasing the WiredTiger internal cache size above its default value. If your use case requires increased internal cache size, see --wiredTigerCacheSizePct and storage.wiredTiger.engineConfig.cacheSizePct.避免将WiredTiger内部缓存大小增加到默认值以上。如果用例需要增加内部缓存大小，请参阅--wiredTigerCacheSizePct和storage.wiredTiger.engineConfig.cacheSizePct。

The default WiredTiger internal cache size value assumes that there is a single mongod instance per machine. If a single machine contains multiple MongoDB instances, decrease the setting to accommodate the other mongod instances.默认的WiredTiger内部缓存大小值假定每台机器只有一个mongod实例。如果一台机器包含多个MongoDB实例，请减小设置以容纳其他MongoDB实例。

If you run mongod in a container (for example, lxc, cgroups, Docker, etc.) that does not have access to all of the RAM available in a system, you must set storage.wiredTiger.engineConfig.cacheSizeGB to a value less than the amount of RAM available in the container. 如果你在一个无法访问系统中所有可用RAM的容器（例如lxc、cgroups、Docker等）中运行mongod，你必须将storage.wiredTiger.engineConfig.cacheSizeGB设置为小于容器中可用RAM量的值。The exact amount depends on the other processes running in the container. See memLimitMB.确切的数量取决于容器中运行的其他进程。请参阅memLimitMB。

You can only provide one of either storage.wiredTiger.engineConfig.cacheSizeGB or storage.wiredTiger.engineConfig.cacheSizePct.您只能提供storage.wiredTiger.engineConfig.cacheSizeGB或storage.wiredTiger.engineConfig.cacheSizePct中的一个。

To view statistics on the cache and eviction rate, see the wiredTiger.cache field returned from the serverStatus command.要查看缓存和驱逐率的统计信息，请参阅serverStatus命令返回的wiredTiger.cache字段。

In a new sharded cluster, why does all data remain on one shard?在一个新的分片集群中，为什么所有数据都保留在一个分片上？

Your cluster must have sufficient data for sharding to make sense. Sharding works by migrating chunks between the shards until each shard has roughly the same number of chunks.集群必须有足够的数据才能进行分片。分片的工作原理是在分片之间迁移块，直到每个分片的块数大致相同。

The default chunk size is 128 megabytes. MongoDB will not begin migrations until the imbalance of chunks in the cluster exceeds the migration threshold. This behavior helps prevent unnecessary chunk migrations, which can degrade the performance of your cluster as a whole.默认块大小为128 MB。MongoDB将不会开始迁移，直到集群中块的不平衡超过迁移阈值。这种行为有助于防止不必要的块迁移，这可能会降低整个集群的性能。

If you have just deployed a sharded cluster, make sure that you have enough data to make sharding effective. If you do not have sufficient data to create more than eight 128 megabyte chunks, then all data will remain on one shard. Either lower the chunk size setting, or add more data to the cluster.如果您刚刚部署了一个分片集群，请确保您有足够的数据来使分片有效。如果你没有足够的数据来创建超过8个128兆字节的块，那么所有数据都将保留在一个分片上。降低块大小设置，或向集群添加更多数据。

As a related problem, the system will split chunks only on inserts or updates, which means that if you configure sharding and do not continue to issue insert and update operations, the database will not create any chunks. You can either wait until your application inserts data or split chunks manually.作为一个相关的问题，系统只会在插入或更新时分割块，这意味着如果您配置了分片并且不继续执行插入和更新操作，数据库将不会创建任何块。您可以等到应用程序插入数据或手动拆分块。

Finally, if your shard key has a low cardinality, MongoDB may not be able to create sufficient splits among the data.最后，如果分片键基数较低，MongoDB可能无法在数据之间创建足够的分割。

Why would one shard receive a disproportionate amount of traffic in a sharded cluster?为什么一个分片在分片集群中会收到不成比例的流量？

In some situations, a single shard or a subset of the cluster will receive a disproportionate portion of the traffic and workload. In almost all cases this is the result of a shard key that does not effectively allow write scaling.在某些情况下，单个分片或集群的子集将接收不成比例的流量和工作负载。在几乎所有情况下，这都是由于分片键不能有效地允许写扩展造成的。

It's also possible that you have "hot chunks." In this case, you may be able to solve the problem by splitting and then migrating parts of these chunks.也有可能你有“热块”。在这种情况下，你可以通过拆分然后迁移这些块的一部分来解决这个问题。

You may have to consider resharding your collection with a different shard key to correct this pattern.您可能需要考虑使用不同的分片键重新分片集合，以纠正这种模式。

What can prevent a sharded cluster from balancing?什么会阻止分片集群的平衡？

If you have just deployed your sharded cluster, you may want to consider the troubleshooting suggestions for a new cluster where data remains on a single shard.如果您刚刚部署了分片集群，您可能需要考虑针对数据保留在单个分片上的新集群的故障排除建议。

If the cluster was initially balanced, but later developed an uneven distribution of data, consider the following possible causes:如果集群最初是平衡的，但后来数据分布不均，请考虑以下可能的原因：

• You have deleted or removed a significant amount of data from the cluster. If you have added additional data, it may have a different distribution with regards to its shard key.您已从群集中删除或移除了大量数据。如果你添加了额外的数据，它的分片键可能会有不同的分布。
• Your shard key has low cardinality and MongoDB cannot split the chunks any further.分片键基数较低，MongoDB无法进一步分割块。

• Your data set is growing faster than the balancer can distribute data around the cluster. This is uncommon and typically is the result of:数据集增长速度超过了平衡器在集群中分发数据的速度。这种情况并不常见，通常是由于：

  • a balancing window that is too short, given the rate of data growth.考虑到数据增长的速度，平衡窗口太短。
  • an uneven distribution of write operations that requires more data migration. You may have to choose a different shard key to resolve this issue.写操作分布不均，需要更多的数据迁移。您可能需要选择不同的分片键来解决此问题。
  • poor network connectivity between shards, which may lead to chunk migrations that take too long to complete. Investigate your network configuration and interconnections between shards.分片之间的网络连接较差，这可能会导致块迁移需要太长时间才能完成。调查网络配置和分片之间的互连。

Why do chunk migrations affect sharded cluster performance?为什么块迁移会影响分片集群的性能？

If migrations impact your cluster or application's performance, consider the following options, depending on the nature of the impact:如果迁移会影响集群或应用程序的性能，请根据影响的性质考虑以下选项：

1. If migrations only interrupt your clusters sporadically, you can limit the balancing window to prevent balancing activity during peak hours. Ensure that there is enough time remaining to keep the data from becoming out of balance again.如果迁移只是偶尔中断集群，则可以限制平衡窗口，以防止在高峰时段进行平衡活动。确保有足够的时间来防止数据再次失去平衡。

2. If the balancer is always migrating chunks to the detriment of overall cluster performance:如果平衡器总是迁移块，从而损害了整体集群性能：

   • You may want to attempt decreasing the chunk size to limit the size of the migration.您可能希望尝试减小块大小以限制迁移的大小。
   • Your cluster may be over capacity, and you may want to attempt to add one or two shards to the cluster to distribute load.集群可能容量过大，您可能希望尝试向集群添加一个或两个分片来分配负载。

It's also possible that your shard key causes your application to direct all writes to a single shard. This kind of activity pattern can require the balancer to migrate most data soon after writing it. 也有可能是分片键导致应用程序将所有写入都指向一个分片。这种活动模式可能要求平衡器在写入数据后立即迁移大部分数据。You may have to consider resharding your collection with a different shard key that provides better write scaling.您可能必须考虑使用不同的分片键重新分片集合，以提供更好的写入扩展。