事情的经过是运维，开发均告诉我业务出现卡单，并且均怀疑是传统数据库的问题，后面又觉得是MQ的问题，最后在中午的时候发现MONGODB 由于上线不严格（主要是MONGODB DDL 的操作和普通数据库不一样，开发的同学的自由度很大），所以造成数据都写了不短的时间了，但相关的维护工作都没有被告知相关部门。

一般来说对于传统数据库的问题发现其实从操作手段和方法上大致相同，而MONGO DB 作为NO SQL 数据库，如何发现问题，又怎么处理有的时候倒不是很清楚。

问题1， 怎么查看慢查询

一般来说在MONGODB 的维护中有这样一个问题，就是尽量避免性能的影响将system.profile关闭，出了问题然后在去打开，然后在处理。起先我也是这样去做的，但后期我发现这样处理问题不OK。先说说为什么要这样做，在说说为什么后面有要打开。

不打开system.profile的原因

1 在系统遇到大量慢语句后会大量的插入慢查询的记录到这个系统表

2 这样操作会造成可能的系统性能二次伤害

思路到底正确不正确，我是这样想的，如果有针对MONGODB 慢查询的监控或者统计数字，并且可以进行一个报警，那其实system.profile是应该打开的，哪怕会在出现大量慢查询的时候出现一些性能的损失，但第一时间发现问题是重要的，与其事后发现，不如一直准备事前发现，出了问题解决问题就好，哪怕到时候在关掉呢。

这里有2个方法

1  实时监控，可以写一个脚本定时去运行，1秒一次查询 

db.currentOp({“secs_running”: {$gte: 3}})

这样查询的好处是，所有系统中不同的数据库的慢语句都会被揪出来，然后直接写到一个日志，或者在写入到mongodb的表里面，然后可以去查询或者进行二次展示。

2 mongodb  profiler

 这个好处是简单，但如果你MONGODB 上的数据库多，那每个数据库都要设置打开，并且可能相比较第一种方法，灵活度差。好处是收集的信息更丰富，针对性更强。

具体看那个就看你要什么了，当然也可以两个都用。

例如你要是想找到 system.profile 中 查询慢的，并且超过1秒的查询，以最近的出现问题的语句从头到尾的显示。可以用下面的语句

db.system.profile.find( { op: { $eq : 'query' } } , 

{"millis": 1000}).sort( { ts : -1 } ).pretty()

当然这样做是否就OK 了，其实还差点，如果developer 问你，HI 有慢查询这段时间，MONGODB 的机器表现如何，是性能引起的问题吗，诸如此类的问题，估计又得费点心理，关键的是，谁知道那阵子的机器的性能如何。

其实对比其他的数据库，例如AWR 报告，或者 DWV 视图系统，或者 sys 库和 preformance_schema中的一些历史表，或者从丰富的日志中，获得所有想要的历史和性能记录在通过pgBadger 输出成漂亮的分析报告。

那MONGODB 可以通过简单的mongostat 来将你要的东西来进行一个记录，写一个脚本，定期的进行日志的切换和废弃，例如记录一个礼拜的性能记录，当然间隔可以调整的大一些，然后对比慢查询，你可以轻松的告诉开发或者其他人员，那时那刻的MONGODB 到底在经历了什么，脏页，当时数据插入，以及CPU的使用率等等。当然如果你安装了 ops manager 则管理和性能监控会更加的方便和可视化。

当然这还没有完，你也可以使用一些MYSQL 中已经熟知的工具集合中包含的MONGODB的工具来处理例如慢查询，或者做一个简单的MONGODB 的 AWR。