1
有一个非常简单的查询：MogoDB更新以超过1秒
db.users.update({"_id" : ObjectId("50710913a6427bfa2600000c") },{$inc: {"points" : 5}})
有一个指数的“点”字段：
db.users.getIndices()
[
{
"v" : 1,
"key" : {
"_id" : 1
},
"ns" : "od.users",
"name" : "_id_"
},
{
"v" : 1,
"key" : {
"points" : 1
},
"ns" : "od.users",
"name" : "points"
},
{
"v" : 1,
"key" : {
"lastActivity" : -1
},
"ns" : "od.users",
"name" : "lastActivity"
}
]
一些指标省略清晰。
我正在上的MongoDB 2.2.3查询，空闲数据库和快速的机器（Amazon EC2的嗨I/O实例）上，它需要超过170秒才能完成......
> db.system.profile.find({ns:"od.users"}).sort({$natural:-1}).limit(1).pretty()
{
"ts" : ISODate("2013-02-13T20:44:52.858Z"),
"op" : "update",
"ns" : "od.users",
"query" : {
"_id" : ObjectId("50710913a6427bfa2600000c")
},
"updateobj" : {
"$inc" : {
"points" : 5
}
},
"nscanned" : 1,
"nupdated" : 1,
"keyUpdates" : 1,
"numYield" : 0,
"lockStats" : {
"timeLockedMicros" : {
"r" : NumberLong(0),
"w" : NumberLong(1747665)
},
"timeAcquiringMicros" : {
"r" : NumberLong(0),
"w" : NumberLong(5964)
}
},
"millis" : 1747,
"client" : "127.0.0.1",
"user" : ""
}
一旦我删除索引，查询完成在任何时间：
> db.system.profile.find({ns:"od.users"}).sort({$natural:-1}).limit(1).pretty()
{
"ts" : ISODate("2013-02-13T20:47:03.032Z"),
"op" : "update",
"ns" : "od.users",
"query" : {
"_id" : ObjectId("50710913a6427bfa2600000c")
},
"updateobj" : {
"$inc" : {
"points" : 5
}
},
"idhack" : true,
"nupdated" : 1,
"keyUpdates" : 0,
"numYield" : 0,
"lockStats" : {
"timeLockedMicros" : {
"r" : NumberLong(0),
"w" : NumberLong(153)
},
"timeAcquiringMicros" : {
"r" : NumberLong(0),
"w" : NumberLong(5)
}
},
"millis" : 0,
"client" : "127.0.0.1",
"user" : ""
}
收藏有大约71K的文件：
> db.users.stats()
{
"ns" : "od.users",
"count" : 71236,
"size" : 2389260264,
"avgObjSize" : 33540.06771856926,
"storageSize" : 3987849216,
"numExtents" : 20,
"nindexes" : 23,
"lastExtentSize" : 1039589376,
"paddingFactor" : 1.0000000002382583,
"systemFlags" : 1,
"userFlags" : 0,
"totalIndexSize" : 1120676144,
"indexSizes" : {
"_id_" : 3343984,
"email" : 4578560,
"country_1" : 2649024,
"wPopularity" : 3278576,
"wRandom" : 2869776,
"wPhoto" : 2959712,
"username_1" : 2657200,
"tsRegistered" : 2976064,
"likes.id" : 483610400,
"dmForCnt_1" : 2861600,
"wPopularity3" : 573660864,
"tags" : 4611264,
"status" : 3311280,
"birthday" : 2959712,
"gender" : 3008768,
"points" : 2869776,
"employee" : 2174816,
"manualSubscription" : 2338336,
"facebookID_1" : 3916304,
"facebookID" : 4161584,
"lastActivity" : 2796192,
"isFraud" : 1537088,
"settingsDailyMatch" : 1545264
},
"ok" : 1
}
是否认为更新索引字段需要这么长时间？我错过了什么吗？
更新：
我注意到只有大于100K的文档才有这个问题。其他文件正在迅速更新。
这台机器使用多少内存？我知道你说这是一个71k的用户数据库（小），但内存不足？如果指数不适合记忆，你可能会遇到这样的问题。我可以通过您的users.stats（）查询查看您的索引大小总计超过1 Gb。 – 2013-02-13 21:04:43
总存储器大小是60G，设备处于闲置状态： ＃自由-m 总使用的无共享缓冲器缓存 号负责：62020 61727 292 0 20 58743 -/+缓冲器/高速缓存：2964 59055 交换：511 0 511 – 2013-02-13 21:15:17
你可以每次在不同的用户上运行更新吗？您可能会看到第二次缓存益处 – 2013-02-13 21:17:30