我们有一个在amazon ec2 large（7.5GB）ubuntu实例上运行的mongodb实例（与我们的node.js服务器运行的机器相同）。 最近stream量增加了很多，我们开始看到MongoDB的一些不稳定的行为。 目前状态：
我们注意到一些使用探查器的慢速查询：
query mydb.user 1327ms Wed Aug 01 2012 14:01:39 query:{ "_id" : ObjectId("500f45486562e7053d070363") } idhack responseLength:178 client:127.0.0.1 user: 用户表中的条目很小，但表中约有5000万个条目。 这种情况每隔一两分钟就会发生一次，接下来是一系列缓慢的查询。 当我们使用explain()从命令行执行缓慢的查询时，没有什么不好的报告。
mongostat告诉我：
insert query update delete getmore command flushes mapped vsize res faults locked % idx miss % qr|qw ar|aw netIn netOut conn set repl time 138 804 9 0 96 36 0 60.2g 121g 3.42g 2 1.8 0 0|0 1|0 93k 479k 19 fgset M 14:15:59 94 755 4 0 71 35 0 60.2g 121g 3.41g 0 1.5 0 0|0 1|0 78k 344k 19 fgset M 14:16:00 93 17 4 0 75 27 0 60.2g 121g 3.41g 0 1.2 0 0|0 1|0 24k 31k 19 fgset M 14:16:01 87 86 6 0 73 33 0 60.2g 121g 3.41g 0 0.9 0 0|0 1|0 31k 260k 19 fgset M 14:16:02 101 531 3 0 62 19 0 60.2g 121g 3.41g 0 1 0 0|0 1|0 60k 1m 19 fgset M 14:16:03 92 713 2 0 66 24 0 60.2g 121g 3.41g 1 0.9 0 0|0 0|0 72k 1m 17 fgset M 14:16:04 163 91 6 0 93 46 0 60.2g 121g 3.41g 2 9.5 0 0|0 1|0 44k 256k 17 fgset M 14:16:05 108 62 6 0 79 38 0 60.2g 121g 3.41g 4 1.2 0 0|0 1|0 32k 122k 17 fgset M 14:16:06 137 23 6 0 81 32 0 60.2g 121g 3.41g 0 2.3 0 0|0 0|0 32k 67k 17 fgset M 14:16:07
pidstat -r -p <pid> 5告诉我：
02:18:01 PM 1700 647.00 0.80 126778144 3578036 46.80 mongod 02:18:06 PM 1700 1092.00 1.20 126778144 3586364 46.91 mongod 02:18:11 PM 1700 689.60 0.20 126778144 3578912 46.81 mongod 02:18:16 PM 1700 740.80 1.20 126778144 3577652 46.79 mongod 02:18:21 PM 1700 618.60 0.20 126778144 3578100 46.80 mongod 02:18:26 PM 1700 246.00 1.00 126778144 3577392 46.79 mongod
请注意，我们的数据库卷是一个单一的ext4卷，而不是推荐的搜查集。
我不知道下一步是什么来了解足够的问题来实施修复。 任何input赞赏。
我不得不更好地看一下这个趋势（ MMS可以帮助你），但是你可能会遇到一个问题，那就是在这个实例中你已经达到了MongoDB的最大驻留内存 – 页面错误没有那么高，但是我看到居民的记忆有一点点的下降。 如果其他地方存在内存压力（来自另一个进程），那么您可能会从MongoDB中删除页面和/或不得不经常更换页面（EBS上的磁盘页面非常慢）。
有几件事情可以使你的RAM使用效率更高：
要查看一个卷的预读设置，请运行此命令（需要root / sudo权限）：
sudo blockdev --report
输出将列出如下所示：
RO RA SSZ BSZ StartSec Size Device rw 256 512 4096 0 10737418240 /dev/xvda1
RA列（我认为这是256位的亚马逊默认）是我们想要调整的地方。 你通过运行这样的东西来做到这一点：
blockdev --setra <value> <device name>
对于上面的例子，我将开始减半值：
blockdev --setra 128 /dev/xvda1
如果您想了解更多信息，我会详细介绍如何设置此值以及此答案背后的原因。 请注意，更改需要mongod进程重新启动才能生效。
在完成这两件事情之后，您可以在该xlarge实例上的RAM中挤出更多性能。 如果不是，或者如果内存压力来自其他地方，并且效率不高，那么现在是时候再增加一些内存。
如上所述，将EBS存储升级到RAID卷或使用新的预置IOPS和EBS优化实例（或者如果您有资金需要刻录的话，则使用SSD集群计算节点）将有助于操作的“慢”部分（从磁盘进行分页）但没有什么能够胜过内存操作的好处 – 即使在磁盘子系统得到改进的情况下，它们的速度仍然快了一个数量级。