尽管日志配置设置为 0，但 Mongodb 非常冗长

Question

即使我将全局详细级别设置为 0 并将所有组件设置为 -1（详细程度继承），我的 MongoDB 实例也会生成千兆字节的日志（通过 QUERY 组件）。

这对实例的性能造成了非常糟糕的影响。

以下是记录的示例，db.stats() 和 db.getLogComponents() 的输出。

PS / 编辑 - 因为我已经看到了投票...：我已经尝试了我可以在网上找到的所有内容（使用安静 = true 的 yaml 配置文件，我检查了分析级别是否为 0 ，我什至尝试将 Log Component 显式设置为 0，但没有任何效果，mongo 仍在大量记录这些查询...）

知道为什么 mongo 一直在生成这些日志条目吗？有什么建议可以关闭它吗？谢谢。

2016-02-23T09:14:27.089+0100 I QUERY [conn526] query jdigger.stacktraces query: { hashcode: 730309037 } planSummary: COLLSCAN ntoreturn:0 ntoskip:0 keysExamined:0 docsExamined:51110 cursorExhausted:1 keyUpdates: 0 writeConflicts：0 numYields：399 nreturned：2 reslen：1114 锁：{全局：{acquireCount：{r：800}}，数据库：{acquireCount：{r：400}}，集合：{acquireCount：{r：400} } } 268 毫秒 2016-02-23T09:14:27.089+0100 I QUERY [conn546] query jdigger.stacktraces query: { hashcode: 1 } planSummary: COLLSCAN ntoreturn:0 ntoskip:0 keysExamined:0 docsExamined:51110 cursorExhausted:1 keyUpdates:0 writeConflicts: 0 numYields:399 nreturned:4 reslen:232 locks:{ Global: { acquireCount: { r: 800 } }, Database: { acquireCount: { r: 400 } }, Collection: { acquireCount: { r: 400 } } } 269ms 2016-02-23T09:14:27.089+0100 I QUERY [conn532] query jdigger.stacktraces query: { hashcode: -1176121626 } planSummary: COLLSCAN ntoreturn:0 ntoskip:0 keysExamined:0 docsExamined:51110 cursorExhausted:1 keyUpdates:0 writeConflicts :0 numYields:399 nreturned:3 reslen:2162 locks:{ Global: { acquireCount: { r: 800 } }, Database: { acquireCount: { r: 400 } }, Collection: { acquireCount: { r: 400 } } } 268毫秒 2016-02-23T09:14:27.089+0100 I QUERY [conn533] query jdigger.stacktraces query: { hashcode: -1452854181} planSummary: COLLSCAN ntoreturn:0 ntoskip:0 keysExamined:0 docsExamined:51110 cursorExhausted:1 keyUpdates:0 writeConflicts :0 numYields:399 nreturned:1 reslen:888 locks:{ Global: { acquireCount: { r: 800 } }, Database: { acquireCount: { r: 400 } }, Collection: { acquireCount: { r: 400 } } } 269 毫秒 2016-02-23T09:14:27.089+0100 I QUERY [conn529] query jdigger.stacktraces query: { hashcode: 401721954 } planSummary: COLLSCAN ntoreturn:0 ntoskip:0 keysExamined:0 docsExamined:51110 cursorExhausted:1 keyUpdates:0 writeConflicts: 0 numYields:399 nreturned:2 reslen:776 locks:{ Global: { acquireCount: { r: 800 } }, Database: { acquireCount: { r: 400 } }, Collection: { acquireCount: { r: 400 } } } 269ms 2016-02-23T09:14:27.091+0100 I QUERY [conn524] query jdigger.stacktraces query: { hashcode: -73774731 } planSummary: COLLSCAN ntoreturn:0 ntoskip:0 keysExamined:0 docsExamined:51110 cursorExhausted:1 keyUpdates:0 writeConflicts :0 numYields:399 nreturned:1 reslen:311 locks:{ Global: { acquireCount: { r: 800 } }, Database: { acquireCount: { r: 400 } }, Collection: { acquireCount: { r: 400 } } } 269 毫秒 2016-02-23T09:14:27.195+0100 I QUERY [conn534] query jdigger.stacktraces query: { hashcode: 1 } planSummary: COLLSCAN ntoreturn:0 ntoskip:0 keysExamined:0 docsExamined:51110 cursorExhausted:1 keyUpdates:0 writeConflicts: 0 numYields:399 nreturned:4 reslen:232 locks:{ Global: { acquireCount: { r: 800 } }, Database: { acquireCount: { r: 400 } }, Collection: { acquireCount: { r: 400 } } } 278ms 2016-02-23T09:14:27.203+0100 I QUERY [conn525] query jdigger.stacktraces query: { hashcode: 1 } planSummary: COLLSCAN ntoreturn:0 ntoskip:0 keysExamined:0 docsExamined:51110 cursorExhausted:1 keyUpdates:0 writeConflicts: 0 numYields:399 nreturned:4 reslen:232 locks:{ Global: { acquireCount: { r: 800 } }, Database: { acquireCount: { r: 400 } }, Collection: { acquireCount: { r: 400 } } } 268ms 2016-02-23T09:14:27.204+0100 I QUERY [conn528] query jdigger.stacktraces query: { hashcode: 401721954 } planSummary: COLLSCAN ntoreturn:0 ntoskip:0 keysExamined:0 docsExamined:51110 cursorExhausted:1 keyUpdates:0 writeConflicts: 0 numYields:399 nreturned:2 reslen:776 locks:{ Global: { acquireCount: { r: 800 } }, Database: { acquireCount: { r: 400 } }, Collection: { acquireCount: { r: 400 } } } 269ms 2016-02-23T09:14:27.204+0100 I QUERY [conn547] query jdigger.stacktraces query: { hashcode: 196127445 } planSummary: COLLSCAN ntoreturn:0 ntoskip:0 keysExamined:0 docsExamined:51110 cursorExhausted:1 keyUpdates:0 writeConflicts: 0 numYields:399 nreturned:2 reslen:1004 locks:{ Global: { acquireCount: { r: 800 } }, Database: { acquireCount: { r: 400 } }, Collection: { acquireCount: { r: 400 } } } 269ms 2016-02-23T09:14:27.204+0100 I QUERY [conn535] query jdigger.stacktraces query: { hashcode: -1176121626 } planSummary: COLLSCAN ntoreturn:0 ntoskip:0 keysExamined:0 docsExamined:51110 cursorExhausted:1 keyUpdates:0 writeConflicts :0 numYields:399 nreturned:3 reslen:2162 locks:{ Global: { acquireCount: { r: 800 } }, Database: { acquireCount: { r: 400 } }, Collection: { acquireCount: { r: 400 } } } 269 毫秒 2016-02-23T09:14:27.205+0100 I QUERY [conn544] query jdigger.stacktraces query: { hashcode: 401721954 } planSummary: COLLSCAN ntoreturn:0 ntoskip:0 keysExamined:0 docsExamined:51110 cursorExhausted:1 keyUpdates:0 writeConflicts: 0 numYields:399 nreturned:2 reslen:776 locks:{ Global: { acquireCount: { r: 800 } }, Database: { acquireCount: { r: 400 } }, Collection: { acquireCount: { r: 400 } } } 269ms 2016-02-23T09:14:27.207+0100 I QUERY [conn543] query jdigger.stacktraces query: { hashcode: 1 } planSummary: COLLSCAN ntoreturn:0 ntoskip:0 keysExamined:0 docsExamined:51110 cursorExhausted:1 keyUpdates:0 writeConflicts: 0 numYields:399 nreturned:4 reslen:232 locks:{ Global: { acquireCount: { r: 800 } }, Database: { acquireCount: { r: 400 } }, Collection: { acquireCount: { r: 400 } } } 269ms

db.stats() { “db”：“jdigger”， “收藏”：2， “对象”：4821385， “avgObjSize”：284.73536857147894， “数据大小”：1372818835， “存储大小”：395268096， “numExtents”：0， “索引”：4， “索引大小”：81928192， “好”：1 }

db.getLogComponents() { “冗长”：0， “访问控制” ： { “冗长”：-1 }, “命令” ： { “冗长”：-1 }, “控制” ： { “冗长”：-1 }, “执行者”：{ “冗长”：-1 }, “地理”：{ “冗长”：-1 }, “指数” ： { “冗长”：-1 }, “网络” ： { “冗长”：-1， “阿西奥”：{ “冗长”：-1 }, “桥” ： { “冗长”：-1 } }, “询问” ： { “冗长”：-1 }, “复制”：{ “冗长”：-1 }, “分片”：{ “冗长”：-1 }, “贮存” ： { “冗长”：-1， “杂志” ： { “冗长”：-1 } }, “写” ： { “冗长”：-1 }, “ftdc”：{ “冗长”：-1 }

Answer 1

我不确定这是否应该被视为一种解决方法或实际解决方案，但我能够达到我的目标，即通过使用 db.setProfilingLevel(0, 1000) 减少一般的日志记录开销。

正如有人指出的那样，Mongo 似乎在默认情况下会分析“持久”查询，而不管分析级别设置或任何其他参数如何。

由于我的大多数查询都是 200 毫秒的查询，因此将阈值设置为 1 秒对我来说很有效。鉴于我的用例的实现细节，200 毫秒并不一定令人震惊，所以这就是我真正不符合“规范”的地方。

Answer 2

MongoDB 的分析器会自动记录任何耗时超过 100 毫秒的查询，因此可能是这样。您可以使用db.setProfilingLevel(0) 将其关闭 - 请参阅https://docs.mongodb.org/manual/tutorial/manage-the-database-profiler/ 上的文档

但是，我还考虑为您的集合添加一个索引，该索引针对您的查询进行了优化，因为现在，查询正在读取集合中的每条记录 (COLLSCAN)。