我需要您帮助我了解一个性能问题。
我们有一个系统,在这个系统中,我们成批地存储一组文档(1k-4k文档)。文档具有以下结构:{_id: ObjectId(), RepositoryId: UUID(), data...}
,其中存储库ID对于集合中的所有示例都相同。我们还为以下内容设置了唯一索引:{_id: 1, RepositoryId: 1}, {RepositoryId: 1, ...}
.
在使用情况下:删除具有相同存储库ID的所有文档:
db.collection.deleteMany(
{ RepositoryId: UUID("SomeGUID") },
{ writeConcern: {w: "majority", j: true} }
)
然后使用与之前删除的相同RepositoryId重新插入批次(每批300个项目):
db.collection.insertMany(
[ { RepositoryId: UUID(), data... }, ... ],
{
writeConcern: {w: 1, j: false},
ordered: false
}
)
问题是前几个(3 - 5)批的upsert比重置(第一批:10s,第8批0.1s)。日志文件中也有条目:
{
"t": {
"$date": "2023-01-19T15:49:02.258+01:00"
},
"s": "I",
"c": "COMMAND",
"id": 51803,
"ctx": "conn64",
"msg": "Slow query",
"attr": {
"type": "command",
"ns": "####.$cmd",
"command": {
"update": "########",
"ordered": false,
"writeConcern": {
"w": 1,
"fsync": false,
"j": false
},
"txnNumber": 16,
"$db": "#####",
"lsid": {
"id": {
"$uuid": "6ffb319a-6003-4221-9925-710e9e2aa315"
}
},
"$clusterTime": {
"clusterTime": {
"$timestamp": {
"t": 1674139729,
"i": 5
}
},
"numYields": 0,
"reslen": 11550,
"locks": {
"ParallelBatchWriterMode": {
"acquireCount": {
"r": 600
}
},
"ReplicationStateTransition": {
"acquireCount": {
"w": 601
}
},
"Global": {
"acquireCount": {
"w": 600
}
},
"Database": {
"acquireCount": {
"w": 600
}
},
"Collection": {
"acquireCount": {
"w": 600
}
},
"Mutex": {
"acquireCount": {
"r": 600
}
}
},
"flowControl": {
"acquireCount": 300,
"timeAcquiringMicros": 379
},
"readConcern": {
"level": "local",
"provenance": "implicitDefault"
},
"writeConcern": {
"w": 1,
"j": false,
"wtimeout": 0,
"provenance": "clientSupplied"
},
"storage": {
},
"remote": "127.0.0.1:52800",
"protocol": "op_msg",
"durationMillis": 13043
}
}
}
}
删除后是否有一些后台进程正在运行,影响了第一批的upsert性能?由于应用程序的另一部分支持事务,在我们从独立副本集切换到单示例副本集之前,这不是问题。这种情况不需要事务,但我们不能使用不同的设置托管mongo的两个示例。数据库对该操作是独占的,没有其他操作在DB上运行(运行在隔离的测试环境中)。2我们如何修复它?
这个问题是可重复的,似乎当有时间间隔在测试运行(几分钟),问题是不存在的第一次运行,但随后的运行是有问题的。运行机器与锐龙7 PRO 4750U,32 GB内存和三星970 EVO M2 SSD。MongoDB版本5.0.5
1条答案
按热度按时间drkbr07n1#
在该日志条目中,
timeAcquiringMicros
指示此操作在尝试获取锁时等待。flowControl
是一种节流机制,它在辅助节点滞后时延迟主节点上的写操作,目的是让辅助节点在get滞后太多以致丢失一致性之前赶上。等待flowControl锁意味着仍有积压的操作要复制到辅助节点,并且这些操作有点落后,因此新的写入速度变慢了。
有关详细信息,请参阅复制延迟和流控制