我们正在尝试更好地优化我们使用 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 类型的文件）。每个处理阶段查询一些信息，然后写回信息（有时相当多）。根据我们处理的数据，可能有很多阶段。
这是一个更新繁重的工作负载，因此锁定百分比是一个关键的扩展统计数据。我们还没有分片，很大程度上是因为在我们需要分片之前，我们需要看看单个实例可以扩展多远。
我们还需要调查哪些其他领域来降低锁定百分比，或者我们刚刚碰壁需要分片？