哪些因素会影响 MongoDB 的锁定百分比

Question

我们正在尝试更好地优化我们使用 MongoDB 实例的方式。我们似乎经常获得高锁定百分比，并希望帮助将其最小化。这是一些 mongostat 输出：

insert  query update delete getmore command flushes mapped  vsize    res faults locked % idx miss %     qr|qw   ar|aw  netIn netOut  conn       time 
     1    107    186      0       0     196       0  3.06g   7.3g   333m      0     11.2          0       0|0     2|0    66k   224k    85   15:55:22 
     2    102    285      0       0     296       0  3.06g   7.3g   333m      0     15.7          0       0|0     2|0    89k   216k    84   15:55:23 
     2     79    325      0       0     335       0  3.06g   7.3g   333m      0     20.2          0       0|0     3|0    96k   149k    85   15:55:24 
     2     92    193      0       0     203       0  3.06g   7.3g   333m      0     10.9          0       1|1     6|1    63k   149k    86   15:55:25 
     3    102    235      0       0     245       0  3.06g   7.3g   331m      0     14.5          0       0|0     2|0    75k   177k    84   15:55:26 
     3     79    267      0       0     275       0  3.06g   7.3g   331m      0     16.5          0       1|0     2|0    80k   133k    86   15:55:27 
     2     66    219      0       0     226       0  3.06g   7.3g   264m      0     14.3          0       0|0     2|0    66k   112k    88   15:55:28 
     2    100    201      0       0     211       0  3.06g   7.3g   334m      0     10.2          0       0|0     3|0    67k   142k    87   15:55:29 
     3    118    227      0       0     244       0  3.06g   7.3g   322m      0     13.8          0       3|1     6|1    78k   150k    87   15:55:30 
     2    112    189      0       0     198       0  3.06g   7.3g   334m      0     10.8          0       0|1     2|2    64k   213k    87   15:55:31 
     2     80    266      0       0     278       0  3.06g   7.3g   246m      0     15.8          0       0|1     3|1    82k   179k    86   15:55:32 
     1     82    307      0       0     314       0  3.06g   7.3g   334m      0     18.1          0       0|0     2|0    89k   158k    86   15:55:33 
     2     94    278      0       0     285       0  3.06g   7.3g   334m      0     17.1          0       0|0     0|0    83k   184k    86   15:55:34 
     3    101    246      0       0     256       0  3.06g   7.3g   332m      0     14.2          0       0|0     1|0    82k   179k    86   15:55:35 
     3     99    203      0       0     213       0  3.06g   7.3g   334m      0     12.5          0       0|0     2|0    67k   154k    88   15:55:36 
     2    115    174      0       0     189       0  3.06g   7.3g   335m      0       11          0       1|0     3|0    63k   172k    88   15:55:37 
     2     97    199      0       0     209       0  3.06g   7.3g   335m      0     10.3          0       0|0     2|0    65k   192k    87   15:55:38 
     2    103    366      0       0     373       0  3.06g   7.3g   334m      0     23.5          0       1|4     3|4   107k   256k    85   15:55:39 
     2    105    338      0       0     349       0  3.06g   7.3g   334m      0     22.9          0       0|0     1|0   101k   207k    83   15:55:40 

由于更好的索引，这比以前好多了。然而，我们显然还有更多工作要做。关于这个数据集的事情：

• 硬件是一个 4-proc 的盒子，平均负载一般在 1.3 到 1.9 之间
• 4GB 内存
• SAN 支持的存储报告延迟峰值为 35 毫秒，但大多数时间通常在 5 到 20 毫秒之间。
• I/O 操作非常少
• 'qr' 和 'qw' 数字确实表明我们没有遭受大排队。

当文档通过我们的处理平台时，我们使用 Mongo 来跟踪元数据。为我们拥有的每个实际文档创建一个 Mongo 文档（实际文档是旧的 Office 类型文件）。每个处理阶段查询一些信息，然后写回信息（有时相当多）。根据我们正在处理的数据，可以有许多阶段。

这是一个更新密集型的工作负载，因此锁定百分比是一个关键的扩展统计数据。我们还没有进行分片，很大程度上是因为我们需要在需要分片之前查看单个实例可以扩展多远。

我们还需要调查哪些其他领域以减少锁定百分比，或者我们刚刚碰壁并需要分片？

Answer 1

这些都是有趣的统计数据。我认为您可能会在更新中遇到文档大小增长的问题，需要将文档复制到磁盘上的新位置。如果确实如此，您也许可以通过手动填充文档来恢复部分锁定百分比。它在第一次插入时增加了一点复杂性，但还不错。请参阅官方文档中的此文档：http://www.mongodb.org/display/DOCS/Padding+Factor#PaddingFactor-ManualPadding

只是一个想法...