MongoDB数据库问题诊断指南

1、MongoDB数据库问题诊断指南议程性能相关诊断工具问题诊断WireTiger存储引擎Snapshot & Checkpointwrite snapshot data to disk at intervals 60s or 2g journal dataDuring the write of a new checkpoint, the previous checkpoint is still validMongoDB can recover from the last valid checkpointTo recover changes made after the last checkpoi

2、nt, run with journalingJournalwrite-ahead transaction logpersists all data modifications between checkpointsDefault snappy compressionBuffer size 128kBJournal sync50msj : truecheckpointjournal file switch (100MB)Memory Use50% of (RAM - 1 GB), or 256 MBB-treefilesystem cache索引索引已经排序sort查询，尽量使用索引，多字段索

3、引统一升序或降序Index prefixes可以被过滤（filter）和排序（sort）使用多查询条件，按照等值、排序、范围的顺序创建索引分片集合，只有_id和片键可以创建唯一索引索引创建foreground，快，锁库Background，慢，无阻塞从节点手工创建4.2开始该参数被废弃查询相关选择性好的field$and操作要对同一个filed，否则不走索引covered query，”totalDocsExamined : 0”indexFilterSet设置后则hint()失效性能影响影响写入操作，平均每个索引下降6%尽量将索引cache在内存中定期检查未使用索引db.runCommand

4、(planCacheSetFilter: , query: ,sort: ,projection: ,indexes: , , .)db.collection.aggregate( $indexStats : , $project : key: 1, accesses.ops: 1 ).pretty()CURD查询优化思路使用索引加速查询减少批次返回数据量projection只返回需要的字段hint()$incr写操作性能索引的影响bulkwritewrite concernjournal commitIntervalMs磁盘 io-wait%聚合操作Pipline开始阶段，优先$match,

5、 $projection在$match后使用$sort, 索引排序分片的sort、limits、skips议程性能相关诊断工具问题诊断mongostatdirty 脏数据/WT cache百分比used WT使用的cache百分比vsize虚拟内存使用大小res真是使用内存大小qrw qr读等待队列长度qw写等待队列长度arw ar活跃的读操作的客户端数量aw活跃的写操作客户端数量-discover，可以显示集群下所有mongod和mongos的指标，节点密码要保持一致mongotop快速定位到压力最大的数据库、集合db.currentOp()microsecs_running 操作的耗时op

6、planSummaryLockwaitingForLock操作类型集合扫描还是索引扫描 等待锁的类型是否正在等待锁db.serverStatus()opcounters只记录操作数，不包含受影响的document统计metrics.document包含操作影响到的documentglobalLock.totalTime如果和uptime接近，表示数据库一直有锁的性 能问题globalLock.currentQueue.total 表示实时的锁统计信息profiler数据库级别，非整个mongod serverfile 是capped集合，默认大小1m4.0开始，可以在mongos上开启，但只能

7、记录进log； db.setProfilingLevel(0, slowms: 20 )会对数据库产生额外的压力LevelDescription0关闭，默认值1采集设定阈值的慢操作信息2采集所有的慢操作信息db.setProfilingLevel(1, 100)file.find().pretty()file.find().sort($natural: -1).limit(1).pretty()db.getProfilingStatus()file.aggregate( $group : _id : $op, count : $sum : 1) db.setProfilingLevel(0)e

8、xplainLevelDescriptionqueryPlanner默认值，并不真实执行executionStats执行查询并返回执行计划的信息allPlansExecution执行查询并返回所有执行计划的信息stage : COLLSCAN IXSCAN FETCH SHARD_MERGE SHARDING_FILTERnReturned ： 查询返回的数量executionTimeMillis : 查询执行时间totalKeysExamined : 扫描的索引数量totalDocsExamined : 扫描的文档数量log messages LevelDescriptionFFatalEE

9、rrorWWarningIInformational, for Verbosity Level of 0D1-5DebugseveritycomponentACCESSCOMMANDELECTIONINDEXNETWORKQUERYREPLJOURNALWRITE.mtools/rueckstiess/mtoolsToolsDescriptionmlogfilter合并、分割日志文件，过滤慢查询，集合扫描，格式转换等mloginfo统计日志内的数据库信息（启停、连接、集群状态等）mplotqueries日志转化为图表形式mlogvis日志转化为HTML页面，与mplotqueries类似mla

10、unch快速搭建本地测试环境（单机、集群、分片）议程性能相关诊断工具问题诊断诊断思路问题数据库系统errorrs.status( )rs.printSlaveReplicationInfo( )rs.printReplicationInfo( )sh.status( )mongod.logmongos.log系统日志 应用日志局部慢db.currentOp( )db.setProfilingLevel( )explainmongod.logtop iostat sar系统日志 应用日志performance整体慢mongostatdb.currentOp( )db.serverStatus(

11、)mplotqueries mongod.logsh.status( )indexStats案例#1使用 mongodump迁移数据库, 数据导出84.5%后退出，无任何报错#mongodump -archive | mongorestore -archive是否按计划切换应用？应用放心上线！案例#1原因分析：不加条件的count()基于metadata，分片环境和意外关闭数据库会导致数据不准确/manual/reference/command/count/index.html案例#2创建索引 eventTime: -1.0 故障现象：API接口响应大量超时案例#2创建索引 eventTime

12、: -1.0 案例#2 $project: contactID: 1, eventTime: 1 In a blocking SORT, all input must be consumed by the sort step before it can produce output. In a non- blocking, or indexed sort, the sort step scans the index to produce results in the requested order.解决办法：在$match和$sort两阶段之间加入$project案例#3 实验db.testcol.drop()for (i=1; i=10000; i+) arr = ;for (j=1; j=1000; j+) doc = _id: (1000 * (i-1) + j), a: i, b: j, c: (1000 * (i-1)+ j) ; arr.push(doc);db.testcol.insertMany(arr);var x = db.testcol.find( b : 255 ); x.next();v