Mongodb上的高全球锁定百分比
我刚刚开始使用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
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之一来触发移动。
相关问题
最新问题
- 我写了这段代码，但我无法理解我的错误
- 我无法从一个代码实例的列表中删除 None 值，但我可以在另一个实例中。为什么它适用于一个细分市场而不适用于另一个细分市场？
- 是否有可能使 loadstring 不可能等于打印？卢阿
- java中的random.expovariate()
- Appscript 通过会议在 Google 日历中发送电子邮件和创建活动
- 为什么我的 Onclick 箭头功能在 React 中不起作用？
- 在此代码中是否有使用“this”的替代方法？
- 在 SQL Server 和 PostgreSQL 上查询，我如何从第一个表获得第二个表的可视化
- 每千个数字得到
- 更新了城市边界 KML 文件的来源？