本文针对实时监控 MongoDB 数据库,总结了一些使用的工具以及需要重点注意的性能方面。
MongoDB 用自己的工具来统计现在运行的MongoDB 服务器的数据,并进行实时报告分析:
内存可能是你可以给 MongoDB 的最重要的资源,因为 Mongodb 是相当吃内存的,如果控制不好的话,mongodb会挂掉。。。所以你要确保你给的内存总是有足够的!经验之谈是提供符合索引数量的足够的 RAM,如果可能的话,为所有数据提供足够的内存。
常驻内存是这里的关键指标, MongoDB 内存 mem 记录了 Mongod 的系统架构和内存使用。
页面错误和内存相关因为页面错误发生时是 MongoDB 去磁盘里面查找数据而不是内存中,如果内存的数量不能满足性能需求,那么你将会看到页面错误,随着页面错误率的上升,opcounters 最终会低于期望值,所以这时你应该增加可用的 RAM。
连接到 MongoDB 的每个连接都有助于追踪系统所需的内存的开销。这最初由 Unix 通过 ulimit 来设置限制,但随后成为由服务器资源,特别是存储器限制。
过高数量的连接数还可以指明问题,例如你的应用程序代码打开太多的连接,造成某地方产生很高的 lock% 。
有时客户端和数据库之间的连接数超出服务器处理请求的能力,这可能会导致在 MongoDB 环境的应用程序性能的下降。
不多说,实时掌握数据库操作的统计数据以及复制和分片操作的详细信息,确保每秒数据库操作(inserts,query,update,delete,getmore 等 command 命令)的总数有助于分析和跟踪数据库的负载。
MongoDB 使用一个全局锁来确保一致性。但是,如果某些操作是长时间运行的或形成一个队列,操作等待锁就会大大降低应用程序性能。
在 MongoDB 2.6版本中,锁是数据库级别的,一直持续 MongoDB 2.8,写操作都是一个全局性数据库锁,MongoDB 使用的这种「readers-writer」锁,虽然支持并发但有很大的局限性,当一个读锁存在,许多读操作可以使用这把锁,然而当一个写锁存在时,其它读写操作不能使用共享这个锁,写入优先于读取,当两个操作一个读取和一个写入正在等待锁,MongoDB 会授予写锁,所以如果写锁发生的过于频繁,那么你应用的性能出现文件也就不奇怪了。当然如果你的应用中真的有大量的写操作,可以考虑 Cassandra 数据库。
MongoDB 复制集通过将数据部署在多个不同的服务器上,防止因单机故障而造成数据的丢失,借助数据冗余来提高数据的可靠性和安全性。而且还可以通过复制技术构建分布式数据库,提高系统的访问性能和安全性。
复制集同步数据过程是:Primary 节点写入数据,Secondary 通过读取 Primary 的 oplog 得到复制信息,开始复制数据并且将复制信息写入到自己的 oplog,复制延迟是 Primary 节点上写入到 Secondary 节点读取 oplog 再写入操作的延迟,复制延迟可能是一个显著的问题,严重影响 MongoDB 副本集部署,过度复制延迟使「滞后」的节点将很快成为 Primary ,增加了分布式读操作不一致的可能性。
分片是在多台计算机存储数据记录的过程中 MongoDB 来满足数据增长需求的特有方式。随着数据量的增加,一台服务器可能不足以存储数据或提供大量的读写操作。分片解决了水平扩展的问题,通过分片,可以添加更多的机器来支持数据增长以及满足读写操作的需求。
MongoDB 在集合的水平上分割数据和分片,通过一个片键( shard key )来分割分片。
为了将一个集合分片,需要选择一个片关键字。一个片键是一个索引字段,或是存在于每个集合文档中的一个复合索引字段。选择正确的分片键可以对应用性能,功能以及数据库和集群的运作有很大的影响,合适的分片键选择取决于你的数据的架构和应用程序的查询和写入数据的方式。而且 Mongodb 数据库是否能高效运转也取决于你指定了文档的哪个字段作为分片字段。由于分片字段都是预先选择且选定后无法更改的,而且考虑到 MongoDB 纵向扩展能力的限制,选择时就需要深思熟虑了。分片键应该满足以下条件:
想要看以上数据指标,需要一定的监控手段,MongoDB 本身有一堆自己的工具,此外还有开源工具以及第三方厂家提供的监控软件,总结为一点,监控很重要,Cloud Insight 全面监控 MongoDB,一工具在手,默认60个数据指标,MongoDB 发生什么都了然于心。
顺道推荐这些文章:
大规模运行 MongoDB 应该知道的10件事