MongoDB数据库性能监控看这一篇就够了

发布时间：2025-11-05 03:16:07 来源：码上建站 作者：数据库

最近项目在使用MongoDB作为图片和文档的据库监控存储数据库，为啥不直接存MySQL里，看篇还要搭个MongoDB集群，据库监控麻不麻烦？看篇

让我们一起，一探究竟，据库监控继续学习MongoDB数据库性能监控，看篇实现快速入门，据库监控丰富个人简历，看篇提高面试level，据库监控给自己增加一点谈资，看篇秒变面试小达人，据库监控BAT不是看篇梦。

一、据库监控MongoDB启动慢​

根本不用为了截屏而快速操作，据库监控MongoDB启动真的超级慢。

二、原因分析

在MongoDB关闭之前，有较大的索引建立的操作没有完成，MongoDB就直接shutdown了，等MongoDB再次启动的香港云服务器时候，MongoDB默认会将这个index重建好，重建期间处于startup状态。

由于不清楚重建索引需要多久，因此可以通过重启mongod时加上–noIndexBuildRetry参数来跳过索引重建。等启动完成后，再创建这个索引。

下面从几方面，监控一下MongoDB的性能问题。

三、MongoDB内存使用

四、MongoDB磁盘空间​

当磁盘空间不足时，可以进行如下操作：

五、常用命令

以上是MongoDB的重要指标，通过这些指标我们可以了解到MongoDB的运行状态，评估数据库的健康程度，企商汇并快速确定实际项目中遇到的性能瓶颈。

比如项目中遇到的Timeout异常：

com.mongodb.MongoSocketReadTimeoutException: Timeout while receiving message

at com.mongodb.connection.InternalStreamConnection.translateReadException(InternalStreamConnection.java:475)

at com.mongodb.connection.InternalStreamConnection.receiveMessage(InternalStreamConnection.java:226)

at com.mongodb.connection.UsageTrackingInternalConnection.receiveMessage(UsageTrackingInternalConnection.java:105)

at com.mongodb.connection.DefaultConnectionPool$PooledConnection.receiveMessage(DefaultConnectionPool.java:438)

at com.mongodb.connection.CommandProtocol.execute(CommandProtocol.java:112)

at com.mongodb.connection.DefaultServer$DefaultServerProtocolExecutor.execute(DefaultServer.java:168)

at com.mongodb.connection.DefaultServerConnection.executeProtocol(DefaultServerConnection.java:289)

at com.mongodb.connection.DefaultServerConnection.command(DefaultServerConnection.java:176)

at com.mongodb.operation.CommandOperationHelper.executeWrappedCommandProtocol(CommandOperationHelper.java:216)

at com.mongodb.operation.CommandOperationHelper.executeWrappedCommandProtocol(CommandOperationHelper.java:207)

at com.mongodb.operation.CommandOperationHelper.executeWrappedCommandProtocol(CommandOperationHelper.java:113)

at com.mongodb.operation.FindOperation$1.call(FindOperation.java:488)

at com.mongodb.operation.FindOperation$1.call(FindOperation.java:1)

at com.mongodb.operation.OperationHelper.withConnectionSource(OperationHelper.java:241)

at com.mongodb.operation.OperationHelper.withConnection(OperationHelper.java:214)

at com.mongodb.operation.FindOperation.execute(FindOperation.java:483)

at com.mongodb.operation.FindOperation.execute(FindOperation.java:1)

六、MongoDB持久性​

复制延迟是指从节点无法跟上主节点的速度。

从节点一个操作的时间减去主节点此操作的时间，就是复制延迟。延迟应该尽可能的接近0，并且通常是毫秒级的。

备份操作通常会将所有数据读入内存，因此，备份操作通常应该在副本集从节点而不是主节点进行，如果是单机MongoDB，则应该在空间时间进行备份，比如深夜凌晨。

持久性是数据库必备的一种特性，想象一下，如果数据库不具备持久性，如果数据库重启，数据全部丢失，太可怕了，不敢想。

为了在服务器发生故障时提供持久性，MongoDB使用预写式日志机制，英文简称 WAL。WAL是数据库系统中一种常见的持久性技术。在数据存入数据库之前，将这些更改操作写到磁盘上。

从MongoDB4.0开始，执行写操作时，MongoDB会使用与oplog相同的格式创建日志。oplog语句具有幂等性，不管执行多少次，结果都是一样的。

MongoDB还维护了日志和数据库数据文件的内存视图。默认情况，每50毫秒会将日志条目刷新到磁盘上，每60秒会将数据库文件刷新到磁盘上。刷新数据的时间60秒间隔被称为检查点。日志用于将上一个检查点之后的数据提供持久性。MongoDB的持久性就是在发生故障时，重启之后，将日志中的语句重新执行一遍，以保证在关闭前丢失的数据重新刷新到MongoDB中。

MongoDB会在data目录下创建一个journal的子目录，WiredTiger日志文件的名称为WiredTigerLog.<sequence>。sequence是一个从0 000 000 001开始的数字。

MongoDB会对写入的日志进行压缩，日志文件限制的最大大小为100MB。如果大于100MB，MongoDB就会自动创建一个新的日志文件，由于日志文件只需在上次检查点之后恢复数据，因此在新的检查点写入完成时，旧的日志文件就会被删除。

本文转载自微信公众号「哪吒编程」，可以通过以下二维码关注。转载本文请联系哪吒编程公众号。

相关文章