0

我有两个分片，每个分片有 3 台复制机器（规格相同）

这些块分布合理：

Shard events at events/xxx:27018,yyy:27018
 data : 6.82GiB docs : 532402 chunks : 59
 estimated data per chunk : 118.42MiB
 estimated docs per chunk : 9023

Shard events2 at events2/zzz:27018,qqq:27018
 data : 7.3GiB docs : 618783 chunks : 66
 estimated data per chunk : 113.31MiB
 estimated docs per chunk : 9375

Totals
 data : 14.12GiB docs : 1151185 chunks : 125
 Shard events contains 48.29% data, 46.24% docs in cluster, avg obj size on shard : 13KiB
 Shard events2 contains 51.7% data, 53.75% docs in cluster, avg obj size on shard : 12KiB

然而，主节点一侧的 vmsize 几乎是 4 倍，锁定百分比接近 90%（另一侧为 2%）以及更高的 btree 计数。这会导致该机器上大量游标超时。

两个分片都应该获得相似类型的查询，并且 opcounter 值非常接近。

理智的主人

问题主机

我该如何诊断？

更新表现不佳的一方似乎使用了大量的数据存储空间，包括 100 倍的索引空间：

    "ns" : "site_events.listen",
    "count" : 544213,
    "size" : 7500665112,
    "avgObjSize" : 13782.59084586366,
    "storageSize" : 9698657792,
    "numExtents" : 34,
    "nindexes" : 3,
    "lastExtentSize" : 1788297216,
    "paddingFactor" : 1.0009999991378065,
    "systemFlags" : 1,
    "userFlags" : 1,
    "totalIndexSize" : 4630807488,
    "indexSizes" : {
            "_id_" : 26845184,
            "uid_1" : 26664960,
            "list.i_1" : 4577297344
    },

对比

    "ns" : "site_events.listen",
    "count" : 621962,
    "size" : 7891599264,
    "avgObjSize" : 12688.233789202555,
    "storageSize" : 9305386992,
    "numExtents" : 24,
    "nindexes" : 2,
    "lastExtentSize" : 2146426864,
    "paddingFactor" : 1.0000000000917226,
    "systemFlags" : 1,
    "userFlags" : 1,
    "totalIndexSize" : 45368624,
    "indexSizes" : {
            "_id_" : 22173312,
            "uid_1" : 23195312
    },
4

1 回答 1

3

根据更新的统计数据，很明显在一个分片上存在一个索引，用于您的分区集合，而另一个分片上没有。当索引以旋转方式构建在副本集上但有人忘记在两个分片上构建索引时，或者当它不应该存在但没有从所有副本集中删除时，可能会发生这种情况。

在您的情况下，额外的索引“list.i_1”的大小为 4.2GB，并且肯定会对性能差异产生重大影响。

我的其余评论更笼统，有些可能并非针对您的示例。

一般来说，用户从一个分片（或未分片的副本集）开始，然后添加第二个分片来承担一半负载的情况并不少见。

不幸的是，数据迁移到 shard2 的方式使 shard1 具有碎片存储，用于数据和索引。由于 MongoDB 使用内存映射文件，较大的文件最终会使用更多的 RAM，从而对 I/O 子系统造成更大的压力，并且通常比更紧凑的 shard2 性能更低，后者基本上“一次”获取所有数据并且是能够使用更少的空间存储相似数量的文档。

使用程序恢复 shard1 可以做的是压缩受影响的集合，如果有多个分片集合，甚至是 repairDatabase()。后者会将释放的空间返回给操作系统，但即使紧凑不会将空间返回给操作系统，它也会将其保留在空闲列表中以供您插入更多数据时使用，但现有数据将很好地放在一起在尽可能少的空间内。

请注意，在同一个副本集中，即使您的一个主副本比另一个大得多，辅助副本也要小得多。如果辅助节点一次“重新同步”其所有数据的时间远晚于分片之间的平衡发生时，就会发生这种情况。在这种情况下，你可以让你的主节点下台，让更紧凑的辅助节点接管——它应该表现更好，同时你可以压缩或修复以前的主节点（新的辅助节点）。通常，建议使用三个副本节点，这样您在进行此类维护时就不会在没有安全网的情况下运行。

我要做的另一个观察是，即使在两个分片上都有一个或多或少均匀分片的集合，你还有许多额外的集合存在于这个数据库的主分片上，这是更大的分片。索引大小的差异肯定是由于 shard1 而不是 shard2 上存在的额外集合的额外索引。这对于只有一些集合被分片的数据库来说是正常的。

除了：

  1. 分片较大的未分片集合或
  2. 将一半未分片的集合移动到一个不同的数据库中，该数据库将以 shard2 作为其主分片。这将更“均匀”地在两个分片之间拆分未分片的集合。
于 2013-10-18T00:27:09.133 回答