為了復制我在生產中看到的內容，我有一個在本地運行的獨立 MongoDB 實體，其中hello()管理命令（以前isMaster）運行直到maxAwaitTimeMS每次超時：
db.runCommand({
"hello": 1,
"topologyVersion": {
"processId": ObjectId("628c762af984c948c15f8811"),
"counter": NumberLong(0)
},
"maxAwaitTimeMS": 5000,
"$db": "admin"
});;
請注意，當“超時”時，回應仍然是客戶端所期望的 - 不清楚的是為什么 Mongo 服務器不會立即回傳，而不是讓查詢maxAwaitTimeMS在回應之前運行到它：
{
"isWritablePrimary" : true,
"topologyVersion" : {
"processId" : ObjectId("628c762af984c948c15f8811"),
"counter" : 0
},
"maxBsonObjectSize" : 16777216,
"maxMessageSizeBytes" : 48000000,
"maxWriteBatchSize" : 100000,
"localTime" : ISODate("2022-05-29T11:35:36.011 01:00"),
"logicalSessionTimeoutMinutes" : 30,
"connectionId" : 86043,
"minWireVersion" : 0,
"maxWireVersion" : 9,
"readOnly" : false,
"ok" : 1
}
服務器上沒有其他活動 - 所以這不是性能問題或連接被阻止的問題。查詢將運行只要'awaitMaxTimeMS'，即使增加到例如5 分鐘。該問題僅發生在topologyVersion呼叫中包含 的情況下，特別是在使用processID第一次運行查詢時回傳的正確時，如下所示：
// query completes immediately
db.runCommand({
"hello": 1,
"$db": "admin"
});
// and the response includes the following:
// { "processId" : ObjectId("628c762af984c948c15f8811") }
這些呼叫是從 Mongo 驅動程式（PyMongo 和 Ruby Mongo）發出的，我們在生產 Mongo 實體上看到了同樣的問題——其中currentOp顯示了許多這樣的hello()查詢，所有這些查詢都超時了。
我的問題是，為什么這些請求會超時并且沒有按預期立即完成？
除了它在currentOp串列中產生的噪音（每個查詢都會停留 10 秒）以及理解原因的好奇心之外，我還希望解決這個問題，以幫助確保連接不會因為這個問題而被阻止. 減少maxAwaitTimeMS（假設 Mongo 驅動程式給予這樣的控制）感覺就像隱藏問題。在復制的 MongoDB 服務器上執行一些測驗時，該問題似乎沒有發生。
uj5u.com熱心網友回復：
不清楚的是為什么 Mongo 服務器沒有立即回傳，而不是讓查詢在回應之前運行到它的 maxAwaitTimeMS：
這是名為流的 hello 執行緒的“特殊”模式的預期行為。簡而言之，客戶端只是通過發送 hello 命令來啟動流服務器的狀態，然后等待來自服務器的回應（不發送請求）。maxAwaitTimeMS服務器在向客戶端發送回應之前可以等待的最長時間也是如此。
所以，是的，這是意料之中的。Waiting 可以小于maxAwaitTimeMS，例如，如果服務器拓撲在等待期間已更改，但此值設定頂部等待邊界，如果服務器健康，您將等待整個指定時間段
我明白了，所以你說有許多 isMaster/hello 查詢都運行到 maxAwaitTimeMS 是正常的行為
如果它同時發生，那么我會投票認為它們在回應中的欄位中包含不同的端點，因為驅動程式為每個端點me創建了一個單獨的執行緒hello
轉載請註明出處，本文鏈接：https://www.uj5u.com/caozuo/482846.html
下一篇：PHP警告：PHP啟動：無法加載模塊“C:\xampp\php\ext\php_mongodb.dll”，因為它與14.29鏈接，但核心與14.16鏈接