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

Posted 2023-02-26

【中文标题】尽管日志配置设置为 0，但 Mongodb 非常冗长

【英文标题】：Mongodb very verbose despite log configuration set to 0

【发布时间】：2016-06-04 23:35:57

【问题描述】：

即使我将全局详细级别设置为 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

【参考方案1】：

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

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

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

【讨论】：

仅供参考，mongod 配置文件的等效参数是slowOpThreshholdMs。您有许多慢速收集扫描（COLLSCAN），其中索引可能是有益的......但听起来这对于您的用例来说是可以接受的。您也可以在运行时调整slowms的值，这是您的解决方案中第二个参数对db.setProfilingLevel()的影响。

非常感谢您的帖子，我会试试这个。

【参考方案2】：

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

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