MongoDB读取文档缓慢（使用索引）

Question

MongoDB读取文档缓慢（使用索引）

mongodbperformanceamazon-web-servicesamazon-ec2

10

FETCH阶段是我的查询中的瓶颈。经过研究，似乎MongoDB读取的比它需要的要多得多，并且没有充分利用带宽。

我的MongoDB-mongod实例在单个查询上似乎读取过多。在AWS EC2 m4.xlarge上进行测试，连接了1个EBS io 5000Piops附加（100GB）SSD和16GB RAM。

该机器仅包含用于测试目的的mongodb实例。

数据库总共大约为60GB（在磁盘上），包含几个集合。

主要集合用于以下场景和查询。

db统计信息

db.stats()
{
    "db" : "database",
    "collections" : 4,
    "objects" : 406496932,
    "avgObjSize" : 326.3196544642064,
    "dataSize" : 132647938391,
    "storageSize" : 55475830784,
    "numExtents" : 0,
    "indexes" : 5,
    "indexSize" : 8940408832,
    "ok" : 1
 }

收集概要：

db.collection.stats()  ->  
{    "ns" : "database.[collection###]",
    "count" : 367614513,
    "size" : 121155225858,
    "avgObjSize" : 329,
    "storageSize" : 52052197376,
    "capped" : false,
    "wiredTiger" : {"Left empty"},
    "nindexes" : 2,
    "totalIndexSize" : 8131604480,
    "indexSizes" : {
            "_id_" : 4373012480,
            "id_1_ts_-1" : 3758592000
    },
    "ok" : 1

查询：

db.[#######].find({ id : "######", 
   ts : { 
    "$gte" :
       ISODate("2016-10-01T00:00:00.000Z"), 
     $lt :
       ISODate("2016-10-07T02:00:00.000Z")
}}, {_id : 0,"u1"
     :1,"u2":1,"u3":1,"eq1" :1 ,"eq2" : 1,"eq3": 1,"ts" :1});

并且解释结果为：

{
    "queryPlanner" : {
            "plannerVersion" : 1,
            "namespace" : "database.[collection]",
            "d" : false,
            "parsedQuery" : {
                    "$and" : [
                            {
                                    "id" : {
                                            "$eq" : "#####ID#####"
                                    }
                            },
                            {
                                    "ts" : {
                                            "$lt" : ISODate("2016-09-30T22:00:00Z")
                                    }
                            },
                            {
                                    "ts" : {
                                            "$gte" : ISODate("2016-09-22T22:00:00Z")
                                    }
                            }
                    ]
            },
            "winningPlan" : {
                    "stage" : "PROJECTION",
                    "transformBy" : {
                            "_id" : 0,
                            "u1" : 1,
                            "u2" : 1,
                            "u3" : 1,
                            "eq1" : 1,
                            "eq2" : 1,
                            "eq3" : 1,
                            "ts" : 1
                    },
                    "inputStage" : {
                            "stage" : "FETCH",
                            "inputStage" : {
                                    "stage" : "IXSCAN",
                                    "keyPattern" : {
                                            "id" : 1,
                                            "ts" : -1
                                    },
                                    "indexName" : "id_1_ts_-1",
                                    "isMultiKey" : false,
                                    "isUnique" : false,
                                    "isSparse" : false,
                                    "isPartial" : false,
                                    "indexVersion" : 1,
                                    "direction" : "forward",
                                    "indexBounds" : {
                                            "id" : [
                                                    "[\"#####ID#####\", \"#####ID#####\"]"
                                            ],
                                            "ts" : [
                                                    "(new Date(1475272800000), new Date(1474581600000)]"
                                            ]
                                    }
                            }
                    }
            },
            "rejectedPlans" : [ ]
    },
    "executionStats" : {
            "executionSuccess" : true,
            "nReturned" : 676745,
            "executionTimeMillis" : 170508,
            "totalKeysExamined" : 676745,
            "totalDocsExamined" : 676745,
            "executionStages" : {
                    "stage" : "PROJECTION",
                    "nReturned" : 676745,
                    "executionTimeMillisEstimate" : 167820,
                    "works" : 676746,
                    "advanced" : 676745,
                    "needTime" : 0,
                    "needYield" : 0,
                    "saveState" : 8970,
                    "restoreState" : 8970,
                    "isEOF" : 1,
                    "invalidates" : 0,
                    "transformBy" : {
                            "_id" : 0,
                            "u1" : 1,
                            "u2" : 1,
                            "u3" : 1,
                            "eq1" : 1,
                            "eq2" : 1,
                            "eq3" : 1,
                            "ts" : 1
                    },
                    "inputStage" : {
                            "stage" : "FETCH",
                            "nReturned" : 676745,
                            "executionTimeMillisEstimate" : 166470,
                            "works" : 676746,
                            "advanced" : 676745,
                            "needTime" : 0,
                            "needYield" : 0,
                            "saveState" : 8970,
                            "restoreState" : 8970,
                            "isEOF" : 1,
                            "invalidates" : 0,
                            "docsExamined" : 676745,
                            "alreadyHasObj" : 0,
                            "inputStage" : {
                                    "stage" : "IXSCAN",
                                    "nReturned" : 676745,
                                    "executionTimeMillisEstimate" : 980,
                                    "works" : 676746,
                                    "advanced" : 676745,
                                    "needTime" : 0,
                                    "needYield" : 0,
                                    "saveState" : 8970,
                                    "restoreState" : 8970,
                                    "isEOF" : 1,
                                    "invalidates" : 0,
                                    "keyPattern" : {
                                            "id" : 1,
                                            "ts" : -1
                                    },
                                    "indexName" : "id_1_ts_-                                                                   1",
                                    "isMultiKey" : false,
                                    "isUnique" : false,
                                    "isSparse" : false,
                                    "isPartial" : false,
                                    "indexVersion" : 1,
                                    "direction" : "forward",
                                    "indexBounds" : {
                                            "id" : [
                                                    "[\"#####ID#####\", \"#####ID#####\"]"
                                            ],
                                            "ts" : [
                                                    "(new Date(1475272800000), new Date(1474581600000)]"
                                            ]
                                    },
                                    "keysExamined" : 676745,
                                    "dupsTested" : 0,
                                    "dupsDropped" : 0,
                                    "seenInvalidated" : 0
                            }
                    }
            },
            "allPlansExecution" : [ ]
    },
    "serverInfo" : {
            "host" : "ip #########",
            "port" : 27017,
            "version" : "3.2.10",
            "gitVersion" : "79d9b3ab5ce20f51c272b4411202710a082d0317"
    },
    "ok" : 1

正如我们在上面看到的，MongoDB使用索引。IXSCAN花费了980毫秒，而FETCH花费了约160000毫秒。

如果我没有错的话，整个读取过程应该是676746(nReturned) * 329(avgObjSize)字节=约212 MB的数据。

我注意到在iostats（http://linuxcommand.org/man_pages/iostat1.html）中，以下内容（/data/db位于xvdf上）：

  vg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.27    0.00    0.00   21.35    0.13   78.25
Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
xvda              0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00
xvdf              0.00     0.00 1691.00    0.00    19.83     0.00    24.02     0.95    0.56    0.56    0.00   0.56  94.40

rMB/s显示约为20MB/s，并且在整个操作（获取阶段）期间持续不断。这意味着MongoDB正在读取160秒 * 20MB/s = 3,200 MB的数据，比上面的200 MB要多得多。

内存：

    free -m
             total       used       free     shared    buffers     cached
   Mem:         16048      12629       3418          0         32       4071
   -/+ buffers/cache:       8525       7522
  Swap:            0          0

另外，mongodb没有使用预配的5000 iops EBS，也没有使用承诺的带宽？只使用了约1700个读/秒，导致大约20MB/s的速度。

我已将预读大小更改为16KB。我尝试将日志和日志文件放在另一个硬盘上。

我无法解决这个问题！请帮帮我。拜托了！

- Villeviktor

2个回答

6

主要情况如下：

本机拥有16 GB的RAM
涉及的集合未压缩时占用112 GB空间（压缩后约51 GB）
该集合的索引总大小约为7 GB
集合包含367614513个文档
大部分时间花费在获取投影文档上。这需要166470毫秒（约166秒）。查询的索引扫描仅需980毫秒（小于1秒）。

假设WiredTiger缓存设置为默认值，则WiredTiger缓存所保留的RAM应该约为8.6 GB。在https://docs.mongodb.com/v3.2/faq/storage/#to-what-size-should-i-set-the-wiredtiger-internal-cache:

从MongoDB 3.2开始，默认情况下，WiredTiger内部缓存将使用以下两者中的较大者：

RAM的60%减去1 GB；或

1 GB。

从上面的信息可以看出，您的机器存在内存压力。 MongoDB试图将索引保留在内存中以便快速访问，而整个索引的大小约为7 GB。这将使用WiredTiger缓存的大约80％，仅用于索引，留下很少的空间用于其他任何内容。因此，MongoDB被迫从磁盘中获取结果集中的文档。此时，性能受到影响。

您可以从iostat输出中看到这一点，其中设备xvdf（数据所在位置）的利用率超过94％（在%util列中显示），这意味着你的操作是I / O限制，因为RAM不足以满足理想的工作集。

为了缓解这个问题，您可以尝试：

为部署提供更大的RAM
（如果适用）使用游标返回文档，而不是尝试一次性访问整个结果集

您还可以查看生产笔记和操作清单以获得推荐的设置。

- kevinadi

你好！我尝试使用 r3.xlarge（30.5GB RAM），但是从磁盘读取的数据仍然太多了。从 iostat rKB/s ~ 60000KB/s，20 秒大约读取了 1.2 GB 的数据（应该少得多，约为 0.2 GB）。我尝试将查询分成不同的游标，这样可以稍微快一点。有没有其他方法可以找出这个性能问题的瓶颈？ - Villeviktor

没有深入了解你的用例和部署情况很难说，特别是数据库调优是一个深奥的课题。我认为查看rKB/s不是一个好的指标。util％更能代表您的磁盘饱和程度。还要看一下mongostat，尤其是％used列，它将显示WiredTiger缓存利用率。到目前为止，所有的证据都指向缺乏RAM（即您的工作集太大而无法满足您拥有的RAM数量）是原因。 - kevinadi

嗨，通过增加RAM，我让它的工作变得更好了一些。谢谢你的回复。 - Villeviktor

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Holgrabus · Accepted Answer

当我在获取大约35000个文档时，我遇到了相同的问题。为了解决这个问题，我使用了聚合函数(sakulstra:aggregate)，在我的情况下，它极大地提高了请求速度。结果格式显然不同，但仍然很容易用于计算我所需的所有内容。

之前 (7000ms) :

const historicalAssetAttributes = HistoricalAssetAttributes.find({
        date:{'$gte':startDate,'$lte':endDate},
        assetId: {$in: assetIds}
    }, {
        fields:{
            "date":1,
            "assetId":1,
            "close":1
        }
    }).fetch();

300毫秒后：

const historicalAssetAttributes = HistoricalAssetAttributes.aggregate([
        {
            '$match': {
                date: {'$gte': startDate, '$lte': endDate},
                assetId: {$in: assetIds}
            }
        }, {
            '$group':{
                _id: {assetId: "$assetId"},
                close: {
                    '$push': {
                        date: "$date",
                        value: "$close"
                    }
                }
            }
        }
    ]);