Mongodb上的高全球锁定百分比

时间:2014-01-01 16:10:29

标签: python mongodb pymongo

我刚刚开始使用Mongodb v2.4.8,全局锁定%平均为80%,这对我来说似乎相当高。运行Ubuntu 12.04 64bit的2核,2GB RAM,SSD VPS的CPU使用率约为120%。 iotop显示偶尔的磁盘写入速度约为10KB / s。 htop表示在2GB中只使用了358 MB的内存。

2个Python进程在mongo上不断执行查找/插入/更新操作。查找操作中使用的字段已编制索引。

为什么全球锁定%如此之高?我们如何解决这个问题?

MMS

enter image description here

db.serverStatus()

    "myCollection" : {
        "timeLockedMicros" : {
            "r" : NumberLong(161149047),
            "w" : NumberLong(38511071963)
        },
        "timeAcquiringMicros" : {
            "r" : NumberLong(11738433),
            "w" : NumberLong(6056873726)
        }
    },

mongostat

insert  query update delete getmore command flushes mapped  vsize    res faults   locked db idx miss %     qr|qw   ar|aw  netIn netOut  conn       time
    *0     *0     73     *0       0    75|0       0  1.61g  3.42g   283m      0  testCollection:95.7%          0       0|0     0|0    13k    10k    13   15:56:06
    *0     *0     52     *0       0    54|0       0  1.61g  3.42g   283m      0  testCollection:83.6%          0       0|0     0|1     9k     8k    13   15:56:07
    *0     *0     67     *0       0    68|0       0  1.61g  3.42g   283m      0  testCollection:89.4%          0       0|0     0|0    12k     9k    13   15:56:08
     1      1     17      1       1   173|0       0  1.61g  3.42g   283m      0  testCollection:34.3%          0       0|0     0|1    18k    40k    13   15:56:09
    *0     *0     45     *0       0    46|0       0  1.61g  3.42g   283m      0  testCollection:69.2%          0       0|0     0|1     8k     7k    13   15:56:10
    *0     *0     46     *0       0    48|0       0  1.61g  3.42g   283m      0 testCollection:101.2%          0       0|0     0|1     8k     7k    13   15:56:11
    *0     *0     48     *0       0    50|0       0  1.61g  3.42g   283m      0 testCollection:100.5%          0       0|0     0|0     8k     8k    13   15:56:12
    *0     *0     62     *0       0    63|0       0  1.61g  3.42g   283m      0  testCollection:91.5%          0       0|0     0|0    11k     9k    13   15:56:13
    *0     *0     52     *0       0    53|0       0  1.61g  3.42g   283m      0  testCollection:94.4%          0       0|0     0|1     9k     8k    13   15:56:14
    *0     *0     34     *0       0    36|0       0  1.61g  3.42g   283m      0  testCollection:94.8%          0       0|0     0|1     6k     6k    13   15:56:15
insert  query update delete getmore command flushes mapped  vsize    res faults   locked db idx miss %     qr|qw   ar|aw  netIn netOut  conn       time
     4      1      8      2       1   167|0       0  1.61g  3.42g   283m      0  testCollection:15.3%          0       0|0     0|1    17k    39k    13   15:56:16
    *0     *0     41     *0       0    43|0       0  1.61g  3.42g   283m      0  testCollection:97.4%          0       0|0     0|1     7k     7k    13   15:56:17
    *0     *0     45     *0       0    46|0       0  1.61g  3.42g   283m      0  testCollection:95.3%          0       0|0     0|1     8k     7k    13   15:56:18
    *0     *0     50     *0       0    52|0       0  1.61g  3.42g   283m      0  testCollection:90.0%          0       0|0     0|1     9k     8k    13   15:56:19
    *0     *0     57     *0       0    58|0       0  1.61g  3.42g   283m      0  testCollection:93.2%          0       0|0     0|1    10k     8k    13   15:56:20
    *0     *0     46     *0       0    48|0       0  1.61g  3.42g   283m      0 testCollection:105.6%          0       0|0     0|1     8k     7k    13   15:56:21
    *0     *0     58     *0       0    60|0       0  1.61g  3.42g   283m      0  testCollection:95.9%          0       0|0     0|0    10k     9k    12   15:56:22
     1      1     12      1       1   167|0       0  1.61g  3.42g   283m      0  testCollection:14.5%          0       0|0     0|1    16k    39k    13   15:56:23
    *0      1     49     *0       0    52|0       0  1.61g  3.42g   283m      0  testCollection:98.8%          0       0|0     0|1     9k    11k    13   15:56:24
    *0     *0     49     *0       0    51|0       0  1.61g  3.42g   283m      0 testCollection:101.9%          0       0|0     0|0     9k     8k    13   15:56:25
insert  query update delete getmore command flushes mapped  vsize    res faults   locked db idx miss %     qr|qw   ar|aw  netIn netOut  conn       time
    *0     *0     49     *0       0    50|0       0  1.61g  3.42g   283m      0  testCollection:95.0%          0       0|0     0|1     8k     8k    13   15:56:26
    *0     *0     60     *0       0    62|0       0  1.61g  3.42g   283m      0  testCollection:94.2%          0       0|0     0|1    10k     9k    13   15:56:27
    *0     *0     46     *0       0    47|0       0  1.61g  3.42g   283m      0  testCollection:94.2%          0       0|0     0|1     8k     7k    13   15:56:28
    *0     *0     35     *0       0    38|0       0  1.61g  3.42g   283m      0  testCollection:90.6%          0       0|0     0|0     6k     6k    12   15:56:29
     1      1      1     *0       1   155|0       0  1.61g  3.42g   283m      0   testCollection:0.9%          0       0|0     0|0    15k    38k    13   15:56:30
     1     *0     42      1       0    45|0       0  1.61g  3.42g   283m      0  testCollection:93.3%          0       0|0     0|1     7k     7k    13   15:56:31
    *0     *0     57     *0       0    68|0       0  1.61g  3.42g   283m      0  testCollection:89.6%          0       0|0     0|1    10k    14k    13   15:56:32
    *0     *0     46     *0       0    48|0       0  1.61g  3.42g   283m      0  testCollection:91.9%          0       0|0     0|1     8k     7k    13   15:56:33
    *0     *0     53     *0       0    54|0       0  1.61g  3.42g   283m      0  testCollection:92.2%          0       0|0     0|1     9k     8k    13   15:56:34
    *0     *0     61     *0       0    63|0       0  1.61g  3.42g   283m      0  testCollection:89.3%          0       0|0     0|1    11k     9k    13   15:56:35
insert  query update delete getmore command flushes mapped  vsize    res faults   locked db idx miss %     qr|qw   ar|aw  netIn netOut  conn       time
    *0     *0     40     *0       0    61|0       0  1.61g  3.42g   283m      0  testCollection:53.7%          0       0|0     0|0     9k     8k    13  

mongotop

                    ns       total        read       write              2014-01-01T15:59:33
             testCollection.oooc       868ms         0ms       868ms
                 testCollection.         5ms         5ms         0ms
            testCollection.depth         0ms         0ms         0ms
   testCollection.system.indexes         0ms         0ms         0ms
testCollection.system.namespaces         0ms         0ms         0ms
     testCollection.system.users         0ms         0ms         0ms
            testCollection.oook         0ms         0ms         0ms
            testCollection.users         0ms         0ms         0ms

                    ns       total        read       write              2014-01-01T15:59:34
             testCollection.oooc       891ms         0ms       891ms
                 testCollection.         0ms         0ms         0ms
            testCollection.depth         0ms         0ms         0ms
   testCollection.system.indexes         0ms         0ms         0ms
testCollection.system.namespaces         0ms         0ms         0ms
     testCollection.system.users         0ms         0ms         0ms
            testCollection.oook         0ms         0ms         0ms
            testCollection.users         0ms         0ms         0ms

                    ns       total        read       write              2014-01-01T15:59:35
             testCollection.oooc       838ms         0ms       838ms
                 testCollection.         0ms         0ms         0ms
            testCollection.depth         0ms         0ms         0ms
   testCollection.system.indexes         0ms         0ms         0ms
testCollection.system.namespaces         0ms         0ms         0ms
     testCollection.system.users         0ms         0ms         0ms
            testCollection.oook         0ms         0ms         0ms
            testCollection.users         0ms         0ms         0ms

                    ns       total        read       write              2014-01-01T15:59:36
             testCollection.oooc       889ms         0ms       889ms
                 testCollection.         0ms         0ms         0ms
            testCollection.depth         0ms         0ms         0ms
   testCollection.system.indexes         0ms         0ms         0ms
testCollection.system.namespaces         0ms         0ms         0ms
     testCollection.system.users         0ms         0ms         0ms
            testCollection.oook         0ms         0ms         0ms
            testCollection.users         0ms         0ms         0ms

                    ns       total        read       write              2014-01-01T15:59:37
             testCollection.oooc       831ms         0ms       831ms
                 testCollection.         0ms         0ms         0ms
            testCollection.depth         0ms         0ms         0ms
   testCollection.system.indexes         0ms         0ms         0ms
testCollection.system.namespaces         0ms         0ms         0ms
     testCollection.system.users         0ms         0ms         0ms
            testCollection.oook         0ms         0ms         0ms
            testCollection.users         0ms         0ms         0ms

                    ns       total        read       write              2014-01-01T15:59:38
             testCollection.oooc       249ms         0ms       249ms
            testCollection.oook        62ms        62ms         0ms
                 testCollection.         0ms         0ms         0ms
            testCollection.depth         0ms         0ms         0ms
   testCollection.system.indexes         0ms         0ms         0ms
testCollection.system.namespaces         0ms         0ms         0ms
     testCollection.system.users         0ms         0ms         0ms
            testCollection.users         0ms         0ms         0ms

Python代码

这是导致Adam C指出的减速的代码。

for date, row in oooc.T.iterkv():

    docExist = db.oooc.find({'timestamp': row['timestamp']})
    if docExist.count() == 0:
        data = json.loads(pd.concat([row, id]).to_json())
        db.oooc.insert(data)
    else:
        data = json.loads(row.to_json())
        db.oooc.update({'timestamp': data['timestamp']}, {'$set': data})

1 个答案:

答案 0 :(得分:2)

mongotop的输出是您需要的线索。在1000毫秒内超过800毫秒,它每秒运行一次,用于在testCollection.oooc命名空间中写入,因此这基本上是你的罪魁祸首(800/1000 = ~80%)。

根据您的mongostat输出来看,它们看起来像是更新,而对于相对较低的更新级别来看,锁定百分比很高,我会假设您在该集合上有很多索引,或者您是增长文件并使其移动(或两者兼而有之)。可能它们可能是批量更新,因此真实率可能远高于mongostat建议。无论哪种方式,找出你正在对该集合做什么,然后修复它。

根据提供的代码进行更新:

如果没有看到代码段中data中的内容,就很难确切地说出发生了什么,但请注意docExist.count的任何大于1的值都可以增加我的效果描述。

当您最初写入MongoDB中的文档时,会为该文档保留特定数量的空间。如果您随后添加字段,展开数组或以原始空间分配之外的其他方式增长文档,那么MongoDB必须将文档移动到新位置(并分配更多空间,使用padding factor )。

因此,与无需移动即可完成的就地更新相比,增加文档的操作非常昂贵。每个这样的操作实际上变成了删除和插入。每次此类移动的索引更新也会受到处罚。

我怀疑你的更新的else子句会触发文档增长,从而导致你看到锁定。我建议更改此项,以便通过手动填充初始插入(以便可以在适当位置进行更新)或使用其他allocation strategies之一来触发移动。