Question

我正在使用带有2个分片的群集的Mongo 2.6.9，每个分片有3个副本，其中一个是隐藏的。这是在RedHat上运行的5台机器部署，其中4台机器包含1个分片的单个副本，第5台机器包含两个分片的隐藏副本。每秒运行大约250次插入，每秒50次更新。这些是非常小的文档的简单插入和更新。此外，还有一小部分小文件插入到GridFS（大约1个文件/秒）。平均文件大小小于1 MB。

为相关集合定义了14个索引。当我要添加将从DB读取的应用程序时，将需要这些。

从主要副本的日志中我看到在整个运行过程中大量简单的插入和更新，甚至是GetLastError请求，这些请求需要几百毫秒甚至有时几秒（默认日志记录级别仅显示超过100毫秒的查询）。例如，此简单更新使用查询索引，不更新任何索引：

2015-10-12T06：12：17.258 + 0000 [conn166086]更新chatlogging.SESSIONS查询：{_ id：“743_12101506113018605820fe43610c0a81eb9_IM”}更新：{$ set：{EndTime：new Date（1444630335126）}} nscanned：1 nscannedObjects ：1 nMatched：1 nModified：1 keyUpdates：0 numYields：0 locks（micros）w：430 2131ms

2015-10-12T06：12：17.259 + 0000 [conn166086]命令chatlogging。$ cmd命令：update {update：“SESSIONS”，更新：[{q：{_ id：“743_12101506113018605820fe43610c0a81eb9_IM”}，u：{$ set：{EndTime：new Date（1444630335126）}}，multi：false，upsert：false}]，writeConcern：{w：1}，ordered：true，metadata：{shardName：“S1R”，shardVersion：[Timestamp 17000 | 3，ObjectId（'56017697ca848545f5f47bf5'）]，session：0}} ntoreturn：1 keyUpdates：0 numYields：0 reslen：155 2132ms

所有插入和更新都使用w：1，j：1。

机器有足够的CPU和内存。磁盘I / O很重要，但在发生这种情况时不会接近100％。

我真的需要弄清楚是什么导致数据库的这种意外缓慢的响应速度。我很可能需要以DB的设置方式改变一些东西。 Mongo使用默认配置运行，包括日志记录级别。

更新 -
我一直在研究这个问题，这里有其他细节，我希望能够找出问题的根本原因，或者至少指出我正确的方向：

目前，单个分片的总DB大小超过200GB。索引差不多50GB。以下是db.stats（）的相关部分和来自其中一个分片的主副本的db.ServerStatus（）的mem部分：

    "collections" : 7,
    "objects" : 73497326,
    "avgObjSize" : 1859.9700916465995,
    "dataSize" : 136702828176,
    "storageSize" : 151309253648,
    "numExtents" : 150,
    "indexes" : 14,
    "indexSize" : 46951096976,
    "fileSize" : 223163187200,
    "nsSizeMB" : 16,

“mem”：{ “位”：64， “常驻”：5155， “虚拟”：526027， “支持”：是的， “已映射”：262129， “mappedWithJournal”：524258 }，

服务器有8GB的RAM，其中mongod进程使用大约5GB。因此，大多数数据以及可能更重要的索引都不会保留在内存中。这可能是我们的根本原因吗？当我之前写过系统有足够的可用内存时，我指的是mongod进程没有尽可能多地使用这一事实，而且大部分RAM都用于缓存内存，如果需要可以释放：

free -m output

以下是来自同一个mongod的mongostat的输出：

mongostat output

我确实看到这些中的一些错误，但这些数字对我来说太低了，无法表明存在真正的问题。我错了吗？

此外，我不知道“锁定数据库”中的数字是否合理，或者是否表明我们有锁争用？

在采用这些统计数据的同一时间范围内，许多基于索引查找文档并且不更新索引的简单更新操作（如下所示）需要数百毫秒：

2015-10-19T09：44：09.220 + 0000 [conn210844]更新chatlogging.SESSIONS查询：{_ id：“838_19101509420840010420fe43620c0a81eb9_IM”}更新：{$ set：{EndTime：new Date（1445247849092）}} nscanned：1 nscannedObjects ：1 nMatched：1 nModified：1 keyUpdates：0 numYields：0 locks（micros）w：214 126ms

许多其他类型的插入或更新操作也需要数百毫秒。因此，该问题看起来是系统范围的，与特定类型的查询无关。使用mtools我无法找到扫描大量文档的操作。

我希望在这里我能够找到问题的根本原因。我可以从系统中提供任何其他信息或统计数据。

提前谢谢你，
列昂尼德

Answer 1

1）首先，您需要提高日志记录级别 2）使用mtools来确定哪些查询很慢 3）调整查询以找出瓶颈

MongoDB的简单插入和更新在加载

1 个答案: