Question

我正在尝试调试MongoDB实例上的高CPU问题。我们有两个shard r3.large AWS实例。与操作计数相比，页面错误不多。

系统配置文件显示了大量的getmore条目，如下所示。请帮我找出导致getmore非常缓慢的原因。

    {
        "op" : "getmore",
        "ns" : "mydb.mycollection",
        "cursorid" : 74493486271,
        "ntoreturn" : 0,
        "keyUpdates" : 0,
        "numYield" : 7,
        "lockStats" : {
            "timeLockedMicros" : {
                "r" : NumberLong(16140),
                "w" : NumberLong(0)
            },
            "timeAcquiringMicros" : {
                "r" : NumberLong(6458801),
                "w" : NumberLong(294321)
            }
        },
        "nreturned" : 120,
        "responseLength" : 13100,
        "millis" : 6304,
        "execStats" : {

        },
        "ts" : ISODate("2015-06-16T14:20:39.886Z"),
        "client" : "1.5.1.3",
        "allUsers" : [ ],
        "user" : ""
    }

Answer 1

回答我自己的问题，这可能有助于其他人。

在CPU高db.adminCommand( { setParameter: 1, logLevel: 1 } )后，在重置为logLevel：0（默认值）后启用更多日志记录。
然后log显示一个0ms的聚合查询，但在此之后，getmore条目有5到6秒。
汇总查询的cursor: { batchSize: 0 }初始批量大小为零。因此，查询返回很快。但是当应用程序开始迭代游标时，会记录getmore并且该条目没有任何查询详细信息。

修复聚合查询$ match以使用索引解决问题

对集合的MongoDB getmore非常慢

1 个答案: