mongodb 删除副本集后upsert的性能下降

n3schb8v  于 2023-01-30  发布在  Go
关注(0)|答案(1)|浏览(174)

我需要您帮助我了解一个性能问题。
我们有一个系统,在这个系统中,我们成批地存储一组文档(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

drkbr07n

drkbr07n1#

在该日志条目中,timeAcquiringMicros指示此操作在尝试获取锁时等待。
flowControl是一种节流机制,它在辅助节点滞后时延迟主节点上的写操作,目的是让辅助节点在get滞后太多以致丢失一致性之前赶上。
等待flowControl锁意味着仍有积压的操作要复制到辅助节点,并且这些操作有点落后,因此新的写入速度变慢了。
有关详细信息,请参阅复制延迟和流控制

相关问题