FAQ: 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, then you should decrease the setting to accommodate the other mongod instances.如果一台机器包含多个MongoDB实例，那么应该减少设置以容纳其他mongod实例。

If you run mongod in a container (e.g. 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。

To see statistics on the cache and eviction, use the serverStatus command. 要查看有关缓存和逐出的统计信息，请使用serverStatus命令。The wiredTiger.cache field holds the information on the cache and eviction.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和缓存中的wiredTiger.cache.tracked脏字节，请参阅wiredTiger.cache。

To adjust the size of the WiredTiger internal cache, see storage.wiredTiger.engineConfig.cacheSizeGB and --wiredTigerCacheSizeGB. 要调整WiredTiger内部缓存的大小，请参阅storage.wiredTiger.engineConfig.cacheSizeGB和--wiredTigerCacheSizeGB。Avoid increasing the WiredTiger internal cache size above its default value.避免将WiredTiger内部缓存大小增加到其默认值以上。

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既利用了WiredTinger内部缓存，也利用了文件系统缓存。

Starting in MongoDB 3.4, the default WiredTiger internal cache size is the larger of either:从MongoDB 3.4开始，默认的WiredTiger内部缓存大小是以下两者中较大的一个：

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

For example, on a system with a total of 4GB of RAM the WiredTiger cache will use 1.5GB of RAM (0.5 * (4 GB - 1 GB) = 1.5 GB). 例如，在总内存为4GB的系统上，WiredTiger缓存将使用1.5GB的RAM（0.5 * (4 GB - 1 GB) = 1.5 GB）。Conversely, a system with a total of 1.25 GB of RAM will allocate 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).相反，总RAM为1.25 GB的系统将向WiredTiger缓存分配256 MB，因为这超过了总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内部缓存中的采集数据是未压缩的，使用不同于磁盘格式的表示形式。块压缩可以显著节省磁盘上的存储空间，但数据必须经过压缩才能由服务器操作。

Via 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 storage.wiredTiger.engineConfig.cacheSizeGB and --wiredTigerCacheSizeGB. 要调整WiredTiger内部缓存的大小，请参阅storage.wiredTiger.engineConfig.cacheSizeGB和--wiredTigerCacheSizeGB。Avoid increasing the WiredTiger internal cache size above its default value.避免将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, then you should decrease the setting to accommodate the other mongod instances.如果一台机器包含多个MongoDB实例，那么应该减少设置以容纳其他mongod实例。

If you run mongod in a container (e.g. 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。

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. 默认块大小为128兆字节。MongoDB不会开始迁移，直到集群中块的不平衡超过迁移阈值。This behavior helps prevent unnecessary chunk migrations, which can degrade the performance of your cluster as a whole.这种行为有助于防止不必要的块迁移，这可能会降低整个集群的性能。

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. 如果您没有足够的数据来创建超过8个128兆字节的块，那么所有数据都将保留在一个分片上。Either lower the chunk size setting, or add more data to the cluster.降低区块大小设置，或者向集群中添加更多数据。

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.您可能需要考虑使用不同的分片键来重新分片集合，以提供更好的写入伸缩性。