【发布时间】:2015-04-03 08:29:10
【问题描述】:
我在 mongostat 中看到 idxmiss % 但是当我运行时
db.serverStatus().indexCounters
没有回应。我在哪里可以找到这个?还有一个问题,我应该关注的适当页面错误值是多少?
【问题讨论】:
-
你可以试试
db.stats().indexes?
标签: performance mongodb monitoring
我在 mongostat 中看到 idxmiss % 但是当我运行时
db.serverStatus().indexCounters
没有回应。我在哪里可以找到这个?还有一个问题,我应该关注的适当页面错误值是多少?
【问题讨论】:
db.stats().indexes?
标签: performance mongodb monitoring
indexCounters 信息特定于 MMAP 存储,并不完全准确(有关一些示例,请参阅:SERVER-9296、SERVER-9284 和 SERVER-14583)。在 MongoDB 3.0 之前的开发周期中,indexCounters 部分以及其他一些以前的指标(如 recordStats 和 workingSet)已被删除。请参阅:SERVER-16378 并在 MongoDB Jira 问题跟踪器中讨论相关问题。
如果您已启用 WiredTiger 存储引擎,请注意serverStatus() 输出中将有一个新的wiredTiger 部分,其中包含相关指标。
我应该关注的适当的页面错误值是多少?
页面错误为您的工作集是否适合 MMAP 的内存提供了一个很好的代理,但关注的具体值将取决于您的部署以及是否有任何明显的性能影响。持续高的硬页错误(需要将数据从磁盘加载到 RAM)会增加 I/O 压力,但这可能并不重要,具体取决于您的磁盘配置和整体工作负载。
一般的最佳做法是使用MMS (MongoDB Management Service) 之类的监控系统来捕获部署指标的历史基线,以便在观察到性能问题时查找痛点。
MongoDB 手册的Production Notes 部分也值得一读。例如,如果您使用的是 Linux,有一些关于调整文件系统和预读参数的建议会影响从磁盘读取数据的效率。
有关如何处理指标的想法,请参阅:Five MMS monitoring alerts to keep your MongoDB deployment on track。这篇博文已有几年的历史,但确定正常、令人担忧和严重限制(以及识别误报)的一般方法仍然非常重要。
【讨论】: