3

我有一个集合,它具有并发读取以及应用程序的某些部分更新同一个集合,但是在加载过程中,每个读取和更新操作都花费了很多时间,并且随着时间的推移变得非常慢


这是一些查询的日志

nscanned:4 nupdated:2 keyUpdates:3 numYields: 1 locks(micros) w:2475463 10247ms
nscanned:4 nupdated:2 keyUpdates:2 numYields: 1 locks(micros) w:2077481 1054ms

Collection 仅有 70K 条记录。并发读写几乎是10。

这是我已经做过的

  1. 具有 3 个成员副本集的分片

  2. 分片键是散列的,数据库和集合级别的分片都是启用的

  3. 每个复制盒都有足够的功率和内存。

  4. 查询以索引为界并db.collection.find().explain()具有此输出

    {
        "cursor" : "BtreeCursor fp.ulc_1_c_1_p_1",
        "isMultiKey" : true,
        "n" : 0,
        "nscannedObjects" : 2,
        "nscanned" : 2,
        "nscannedObjectsAllPlans" : 2,
        "nscannedAllPlans" : 2,
        "scanAndOrder" : false,
        "indexOnly" : false,
        "nYields" : 0,
        "nChunkSkips" : 0,
        "millis" : 0,
        "indexBounds" : {
            "fp.ulc" : [
                [
                    "0ca01c47c984b5583d455e42aafded2c",
                    "0ca01c47c984b5583d455e42aafded2c"
                ]
            ],
            "c" : [
                [
                    false,
                    false
                ]
            ],
            "p" : [
                [
                    1372062247612,
                    1.7976931348623157e+308
                ]
            ]
        }
    }
    

我也尝试使用辅助设置读取首选项,但一段时间后它也会变慢我还注意到这里的 mongostat 锁定是 mongostat 的输出

insert  query update delete getmore command flushes mapped  vsize    res faults       locked db idx miss %     qr|qw   ar|aw  netIn netOut  conn  set repl       time
    *0     *0      6     *0       4     2|0       0  54.4g   109g  1.74g      0 collectDb:199.7%          0       6|0     0|1     3k   130k    21 set1  PRI   08:27:55
    *0     *0     15     *0      11     8|0       1  54.4g   109g  1.74g      0 collectDb:200.1%          0       6|0     0|1    11k   357k    21 set1  PRI   08:27:58
     7     *0     34     *0      18    26|0       0  54.4g   109g  1.75g      0 collectDb:202.9%          0       6|0     0|1    36k   362k    21 set1  PRI   08:28:00
     1     *0     13     *0       8     7|0       0  54.4g   109g  1.75g      0 collectDb:192.3%          0       6|0     0|1    12k   287k    21 set1  PRI   08:28:03
     1     *0      9     *0       7     8|0       0  54.4g   109g  1.75g      0 collectDb:196.1%          0       6|0     0|1     5k   258k    21 set1  PRI   08:28:04
     5     *0     20     *0      10    13|0       0  54.4g   109g  1.75g      0 collectDb:207.7%          0       6|0     0|1    23k   214k    21 set1  PRI   08:28:08
     8     *0     38     *0      21    29|0       0  54.4g   109g  1.74g      0 collectDb:215.9%          0       5|0     0|1    40k   548k    21 set1  PRI   08:28:12
     6     *0     44     *0      24    22|0       0  54.4g   109g  1.75g      0 collectDb:199.5%          0       3|0     0|1    45k   509k    21 set1  PRI   08:28:15
     2      4     27     *0      11    28|0       0  54.4g   109g  1.75g      0 collectDb:169.2%          0       6|0     0|1    21k   318k    21 set1  PRI   08:28:18
     2     *0     29     *0      18    20|0       0  54.4g   109g  1.74g      0 collectDb:255.5%          0       5|0     0|1    28k   588k    21 set1  PRI   08:28:24
4

1 回答 1

3

所以我终于想出了一些避免锁定mongodb的最佳方法。

我做了什么

  • 从这里将我的 mongodb 更新到最新的稳定生产版本 2.4.8 。

  • 使用Raid 10 ebs将我的 ebs 更新为优化的 iops 2000 。

  • 监控来自 mongod.log 文件的慢速查询以及每个驱动器的 iowait。

  • 从 Mongodb索引文档中添加了一些多键索引和复合索引。

  • 我还观察了每个 ec2 实例上 ram 的消耗,包括副本集的主要和次要成员。

  • 将实例类型更改为使用千兆以太网接口优化的 Ebs,每台服务器上超过 16 GB 的 ram,以便大部分时间 ram 可用于索引和当前数据集。

  • 亚马逊实例及其最佳用例的好读文档,以便您更好地了解您的需求。


尽管锁定是 MongoDB 中的一个主要问题,但我认为他们正在研究集合级别的锁定,因此可能在即将推出的版本中,它将解决几乎所有与由于锁定导致的性能下降有关的问题。这是您可以检查状态的jira链接。

于 2014-01-09T22:19:11.140 回答