Python Mongodb上的高全局锁%

我刚刚开始使用Mongodb v2.4.8，全局锁平均为80%，这在我看来相当高。在运行Ubuntu 12.04 64位的2核2GB RAM SSD VPS上，CPU使用率约为120%<代码>iotop显示偶尔以约10KB/s的速度写入磁盘<代码>htop显示2GB内存中仅使用了358 MB

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

为什么全局锁定率这么高？我们如何解决这个问题

彩信

db.serverStatus（）

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})

---

mongotop

的输出是您需要的线索。它每秒运行一次，1000毫秒中有800多毫秒是在

testCollection.oooc

名称空间中编写的，所以这基本上就是你的罪魁祸首（800/1000=~80%）

从您的

mongostat

输出判断，这些似乎是更新，对于相对较低级别的更新，锁定率很高，我假设您在该集合上有很多索引，或者您正在增加文档并导致它们移动（或者两者都移动）。它们可能是批量更新，因此真实更新率可能远高于mongostat的建议。不管是哪种方式，找出您对该集合所做的操作，然后修复它

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

如果不查看代码片段中的

数据

中的内容，就很难准确判断发生了什么，但是请注意，

docExist.count

的任何值如果大于1，可能会使我将要描述的效果成倍增加

最初在MongoDB中写入文档时，会为该文档保留一定的空间。如果随后添加字段、扩展数组或以其他方式将文档扩展到原始空间分配之外的位置，则MongoDB必须将文档移动到新位置（并分配更多空间，这是使用的）

因此，与无需移动即可完成的就地更新相比，增长文档的操作成本非常高。每一个这样的操作实际上都变成了删除和插入。对于每一次这样的移动，索引更新也会受到惩罚

---

我怀疑更新中的else子句会触发文档增长，从而导致锁定。我建议对其进行修改，使其不会通过手动填充初始插入内容（以便更新到位）或使用其中一个来触发移动。

这不是与编程直接相关的问题。这里没有处理代码的地方。因此，我想说这个问题更适合。这个问题似乎离题了，因为它是关于数据库管理的。高锁%会导致问题吗，还是仅仅是“奇怪”？@shx2在将服务器从1核升级到2核之前，CPU使用率始终为100%。有2个核心，它的60%。我认为最好现在就处理高锁%，因为当我增加写入mongoI的python进程数量时，我需要增加op/秒的数量。除非你经历了缓慢，否则我不会担心锁%。谢谢你的分析，统计数据现在更有意义了！我在原始帖子中包含了写入

testCollection.oooc

的代码。

update

操作在我看来非常简单。集合

oooc

只有

时间戳上的索引。增加文档并导致文档移动是什么意思？我修改了答案以更详细地解释问题，并将其与发布的代码联系起来。刚刚检查了集合的填充因子是否为
1.0
。这是否意味着在更新该集合中的文档时，即使增加其中一个字段中的字符/位数，也会导致文档移动？与将值
99
更新为
100
No类似，所列的增量通常会到位，不会导致移动。当文档的很大一部分发生更改或变大（数组添加、新字段等）时，将发生移动。填充因子为1.0表示没有移动，顺便说一句，这表示您的更新导致了没有移动的锁定级别（这似乎很奇怪）。我会查看日志（或启用一段时间的分析），尝试确定最慢的操作是什么，以进一步缩小范围
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})