DAY22 MongoDB Profiler 几个指令抓出拖垮系统的元凶

Profiler 查询推荐指令

db.system.profile.find()

一般我们不会这样做，因为资讯又多又难阅读，可以加上一些查询条件。
例如 limit(x) 或者指定某些操作 op 等等。
以下直接推荐我常在使用的指令:

直接找出最慢的

利用执行时间、倒序来找出最慢的几个。
为了方便阅读也加入.limit()、.pretty()语法，後面就不赘述。

db.system.profile.find().sort({ millis: -1 }).limit(5).pretty();

利用操作类别查询

如果你确定慢的 op 是什麽，也可以针对 op 直接排序。

db.system.profile.find({"op":"query"}).sort({ millis: -1 });

查询是否有 COLLSCAN

db.system.profile.find({"planSummary": "COLLSCAN"});

利用发生时间来查询

有设定好最低可接受的执行时间门槛的话，可以用这个方法定期检查是否有新增慢的查询。

db.system.profile.find().sort({ ts: -1 });

查询特定时间区

db.system.profile.find({
"ts": {
         $gt: new ISODate("2021-06-13T00:00:00Z"),
         $lt: new ISODate("2021-06-13T03:00:00Z")
    }}).sort({ millis: -1 });

查询特定Collection

db.system.profile.find({ ns: 'target.collection' });

查找过多文件的查询

db.system.profile.find({ docsExamined: { $gt : 10000 }}).sort({ ts: -1 });

profile size

profile 在系统是有预设 1 Mb 的大小，如果要改变，必须先关闭、删除现有 profile、重建最後重新开起。因此强烈建议在服务开启之前就先决定好。

指令如下:

// 1 停用
db.setProfilingLevel(0)

// 2.删除 (回传为 true/false)
db.system.profile.drop()

// 3.重建 (回传为 {"ok": 1})
db.createCollection("system.profile", {capped: true, size: 3000000})

// 4.重开
db.setProfilingLevel(1)

心得

其实在查找效能低落的操作，会用到的指令大概就是这些了，蛮考验的是对各个参数的熟悉度。
第一阶段是了解各个参数，第二阶段是定期自动化取得 profile 内容，第三阶段是配合自定义的规则来告警，要做到自动化还是需要时间与资源的投入。

问题爆发通常是在线上环境，但你敢在线上环境开profiler吗？

如果在开发阶段就开着 profiler，执行测试後都有回报其结果，就能减少不该存在的操作一路上到正式环境。(举个最简单例子，定期察看是否有 Collection scan 就帮助很大了)

有的人反对开 profiler 会慢，但会慢多少？开着 level 1 也有过滤杂讯的功能，我再测试了一下影响并不显着，况且开发环境从来就不是效能测试的地方，另外就是它是存在 capped collection，实在不用太担心效能影响剧烈的状况。

以上我说的是正式营运环境之前，建议可以开。

本系列文章会同步发表於我个人的部落格 Pie Note