文章目录
- MongoDB性能调优
- MongoDB性能不佳原因
- 影响MongoDB性能的因素
- MongoDB性能监控工具
- mongostat
- mongotop
- Profiler模块
- db.currentOp()
MongoDB性能调优
MongoDB性能不佳原因
- 慢查询
- 阻塞等待
- 硬件资源不足
1,2通常是因为模型/索引设计不佳导致的
排查思路：按1-2-3依次排查
影响MongoDB性能的因素
processon在线图
- 首先需要排除客户端到服务端的网络问题
- 注意客户端与服务端 版本兼容问题
MongoDB性能监控工具
mongostat
下载地址：https://www.mongodb.com/try/download/database-tools
mongostat是MongoDB自带的监控工具，其可以提供数据库节点或者整个集群当前的状态视图。
该功能的设计非常类似于Linux系统中的vmstat命令，可以呈现出实时的状态变化。不同的是，mongostat所监视的对象是数据库进程。mongostat常用于查看当前的QPS/内存使用/连接数，以及多个分片的压力分布。mongostat采用Go语言实现，其内部使用了db.serverStatus()命令，要求执行用户需具备clusterMonitor角色权限。
mongostat -h 192.168.75.100 --port 28017 -u hushang -p 123456 --authenticationDatabase=admin --discover -n 300 2
参数说明:
- -h：指定监听的主机，分片集群模式下指定到一个mongos实例，也可以指定单个mongod，或者复制集的多个节点。
- –port：接入的端口，如果不提供则默认为27017。
- -u：接入用户名，等同于-user。
- -p：接入密码，等同于-password。
- –authenticationDatabase：鉴权数据库。
- –discover：启用自动发现，可展示集群中所有分片节点的状态。
- -n 300 2：表示输出300次，每次间隔2s。也可以不指定“-n 300”，此时会一直保持输出。
| 指标名 | 说明 |
|---|---|
| inserts | 每秒插入数 |
| query | 每秒查询数 |
| update | 每秒更新数 |
| delete | 每秒删除数 |
| getmore | 每秒getmore数 |
| command | 每秒命令数，涵盖了内部的一些操作 |
| %dirty | WiredTiger缓存中脏数据百分比 |
| %used | WiredTiger 正在使用的缓存百分比，也就是分配给WiredTiger存储引擎的内存使用情况 |
| flushes | WiredTiger执行CheckPoint的次数 |
| vsize | 虚拟内存使用量 |
| res | 物理内存使用量 |
| qrw | 客户端读写等待队列数量，高并发时，一般队列值会升高 |
| arw | 客户端读写活跃个数 |
| netIn | 网络接收数据量 |
| netOut | 网络发送数据量 |
| conn | 当前连接数 |
| set | 所属复制集名称 |
| repl | 复制节点状态（主节点/二级节点……) |
| time | 时间戳 |
mongostat需要关注的指标主要有如下几个：
- 插入、删除、修改、查询的速率是否产生较大波动，是否超出预期。
- qrw、arw：队列是否较高，若长时间大于0则说明此时读写速度较慢。
- conn：连接数是否太多。
- dirty：百分比是否较高，若持续高于10%则说明磁盘I/O存在瓶颈。
- netIn、netOut：是否超过网络带宽阈值。
- repl：状态是否异常，如PRI、SEC、RTR为正常，若出现REC等异常值则需要修复。
使用交互模式
mongostat一般采用滚动式输出，即每一个间隔后的状态数据会被追加到控制台中。从MongoDB 3.4开始增加了--interactive选项，用来实现非滚动式的监视，非常方便。
# 该命令我本机运行有问题
mongostat -h 192.168.75.100 --port 28017 -u hushang -p hushang --authenticationDatabase=admin --discover --interactive -n 2
mongotop
mongotop命令可用于查看数据库的热点表，通过观察mongotop的输出，可以判定是哪些集合占用了大部分读写时间。mongotop与mongostat的实现原理类似，同样需要clusterMonitor角色权限。
# 默认情况下，mongotop会持续地每秒输出当前的热点表
mongotop -h 192.168.75.100 --port=28017 -u hushang -p 123456 --authenticationDatabase=admin
# 在mongosh端 执行一些插入语句进行测试
rs0 [direct: primary] admin> for(var i = 0;i<5000;i++){db.emp.insertOne({name: "hushang"+i})}
指标说明：
| 指标名 | 说明 |
|---|---|
| ns | 集合名称空间 |
| total | 花费在该集合上的时长 |
| read | 花费在该集合上的读操作时长 |
| write | 花费在该集合上的写操作时长 |
mongotop通常需要关注的因素主要包括：
- **热点表操作耗费时长是否过高。**这里的时长是在一定的时间间隔内的统计值，它代表某个集合读写操作所耗费的时间总量。在业务高峰期时，核心表的读写操作一般比平时高一些，通过mongotop的输出可以对业务尖峰做出一些判断。
- **是否存在非预期的热点表。**一些慢操作导致的性能问题可以从mongotop的结果中体现出来
mongotop的统计周期、输出总量都是可以设定的
#最多输出100次，每次间隔时间为2s
mongotop -h 192.168.75.100 --port=28017 -u hushang -p 123456 --authenticationDatabase=admin -n 100 2
Profiler模块
Profiler模块可以用来记录、分析MongoDB的详细操作日志。默认情况下该功能是关闭的，对某个业务库开启Profiler模块之后，符合条件的慢操作日志会被写入该库的system.profile集合中。
Profiler的设计很像代码的日志功能，其提供了几种调试级别:
| 级别 | 说明 |
|---|---|
| 0 | 日志关闭，无任何输出 |
| 1 | 部分开启，仅符合条件（时长大于slowms）的操作日志会被记录 |
| 2 | 日志全开，所有的操作日志都被记录 |
对当前的数据库开启Profiler模块:
# 将level设置为2，此时所有的操作会被记录下来。
db.setProfilingLevel(2)
#检查是否生效
db.getProfilingStatus()
was当前级别slowms是慢操作的阈值，单位是毫秒；sampleRate表示日志随机采样的比例，1.0则表示满足条件的全部输出。
如果希望只记录时长超过500ms的操作，则可以将level设置为1
db.setProfilingLevel(1,500)
还可以进一步设置随机采样的比例
db.setProfilingLevel(1,{slowms:500,sampleRate:0.5})
查看操作日志
开启Profiler模块之后，可以通过system.profile集合查看最近发生的操作日志
db.system.profile.find().limit(5).sort({ts:-1}).pretty()
具体操作如下
# 开启profile后手动插入一条记录
rs0 [direct: primary] test> db.emp.insertOne({username: "hushang", age: 24})
{
acknowledged: true,
insertedId: ObjectId("66ab0978c301fc0d4a5343e2")
}
# 在执行一次查询
rs0 [direct: primary] test> db.emp.find()
# 接下来查询profile的数据
rs0 [direct: primary] test> db.system.profile.find().limit(5)
[
{
op: 'insert', # 操作类型，描述增加、删除、修改、查询。
ns: 'test.emp', # 名称空间，格式为{db}.{collection}。
command: { # 原始的命令文档。
insert: 'emp',
documents: [
{
username: 'hushang',
age: 24,
_id: ObjectId("66ab0978c301fc0d4a5343e2")
}
],
ordered: true,
lsid: { id: new UUID("a7724286-4b53-43a0-a827-bec1cc00c81d") },
txnNumber: Long("1"),
'$clusterTime': {
clusterTime: Timestamp({ t: 1722485085, i: 3 }),
signature: {
hash: Binary(Buffer.from("0000000000000000000000000000000000000000", "hex"), 0),
keyId: Long("0")
}
},
'$db': 'test'
},
ninserted: 1,
keysInserted: 1,
numYield: 0, # 操作数，大于0表示等待锁或者是磁盘I/O操作。
locks: { # 锁占用的情况。
ParallelBatchWriterMode: { acquireCount: { r: Long("3") } },
FeatureCompatibilityVersion: { acquireCount: { r: Long("3"), w: Long("2") } },
ReplicationStateTransition: { acquireCount: { w: Long("4") } },
Global: { acquireCount: { r: Long("3"), w: Long("2") } },
Database: { acquireCount: { w: Long("2") } },
Collection: { acquireCount: { w: Long("2") } },
Mutex: { acquireCount: { r: Long("4") } }
},
flowControl: { acquireCount: Long("1"), timeAcquiringMicros: Long("1") },
readConcern: { provenance: 'implicitDefault' },
writeConcern: { w: 2, wtimeout: 0, provenance: 'customDefault' },
responseLength: 230, # 响应数据大小（字节数），一次性查询太多的数据会影响性能
protocol: 'op_msg',
millis: 3, # 命令执行的时长，单位是毫秒。
ts: ISODate("2024-08-01T04:05:12.985Z"),
client: '127.0.0.1',
appName: 'mongosh 1.8.0',
allUsers: [ { user: 'hushang', db: 'admin' } ],
user: 'hushang@admin'
},
{
op: 'query', # 操作类型，描述增加、删除、修改、查询。
ns: 'test.emp', # 名称空间，格式为{db}.{collection}。
command: { # 原始的命令文档。
find: 'emp',
filter: {},
lsid: { id: new UUID("a7724286-4b53-43a0-a827-bec1cc00c81d") },
'$clusterTime': {
clusterTime: Timestamp({ t: 1722485626, i: 1 }),
signature: {
hash: Binary(Buffer.from("0000000000000000000000000000000000000000", "hex"), 0),
keyId: Long("0")
}
},
'$db': 'test'
},
cursorid: Long("5929651518194517166"), # 游标ID。
keysExamined: 0, # 扫描索引条目数，如果比 nreturned 大出很多，则说明查询效率不高。
docsExamined: 101, # 扫描文档条目数，如果比nreturned大出很多，则说明查询效率不高。
numYield: 0, # 操作数，大于0表示等待锁或者是磁盘I/O操作。
nreturned: 101, # 返回条目数。 因为我之前新增过一些数据
queryHash: '17830885',
queryFramework: 'classic',
locks: { # 锁占用的情况。
FeatureCompatibilityVersion: { acquireCount: { r: Long("1") } },
Global: { acquireCount: { r: Long("1") } },
Mutex: { acquireCount: { r: Long("1") } }
},
flowControl: {},
readConcern: { level: 'local', provenance: 'implicitDefault' },
responseLength: 4976, # 响应数据大小（字节数），一次性查询太多的数据会影响性能
protocol: 'op_msg',
millis: 0, # 命令执行的时长，单位是毫秒。
planSummary: 'COLLSCAN', # 查询计划的概要，如IXSCAN表示使用了索引扫描。 COLLSCAN表示全表扫描
execStats: { # 执行过程统计信息。
stage: 'COLLSCAN', # 查询计划的概要，如IXSCAN表示使用了索引扫描。 COLLSCAN表示全表扫描
nReturned: 101, # 返回条目数。
executionTimeMillisEstimate: 0,
works: 102,
advanced: 101,
needTime: 1,
needYield: 0,
saveState: 1,
restoreState: 0,
isEOF: 0,
direction: 'forward',
docsExamined: 101
},
ts: ISODate("2024-08-01T04:14:15.763Z"), # 命令执行的时间点。
client: '127.0.0.1',
appName: 'mongosh 1.8.0',
allUsers: [ { user: 'hushang', db: 'admin' } ],
user: 'hushang@admin'
}
]
这里需要关注的一些字段主要如下所示:
- op：操作类型，描述增加、删除、修改、查询。
- ns：名称空间，格式为{db}.{collection}。
- Command：原始的命令文档。
- Cursorid：游标ID。
- numYield：操作数，大于0表示等待锁或者是磁盘I/O操作。
- nreturned：返回条目数。
- keysExamined：扫描索引条目数，如果比nreturned大出很多，则说明查询效率不高。
- docsExamined：扫描文档条目数，如果比nreturned大出很多，则说明查询效率不高。
- locks：锁占用的情况。
- storage：存储引擎层的执行信息。
- responseLength：响应数据大小（字节数），一次性查询太多的数据会影响性能，可以使用limit、batchSize进行一些限制。
- millis：命令执行的时长，单位是毫秒。
- planSummary：查询计划的概要，如IXSCAN表示使用了索引扫描。
- execStats：执行过程统计信息。
- ts：命令执行的时间点。
# 根据这些字段，可以执行一些不同维度的查询。比如查看执行时长最大的10条操作记录
db.system.profile.find().limit(10).sort({millis:-1}).pretty()
# 查看某个集合中的update操作日志
db.system.profile.find({op:"update",ns:"test.emp"})
注意事项
- system.profile是一个1MB的固定大小的集合，随着记录日志的增多，一些旧的记录会被滚动删除。
- 在线上开启Profiler模块需要非常谨慎，这是因为其对MongoDB的性能影响比较大。建议按需部分开启，同时slowms的值不要设置太低。
- sampleRate的默认值是1.0，该字段可以控制记录日志的命令数比例，但只有在MongoDB 4.0版本之后才支持。
- Profiler模块的设置是内存级的，重启服务器后会自动恢复默认状态。
db.currentOp()
Profiler模块所记录的日志都是已经发生的事情，db.currentOp()命令则与此相反，它可以用来查看数据库当前正在执行的一些操作。
想象一下，当数据库系统的CPU发生骤增时，我们最想做的无非是快速找到问题的根源，这时db.currentOp就派上用场了。
db.currentOp()读取的是当前数据库的命令快照，该命令可以返回许多有用的信息，比如：
- 操作的运行时长，快速发现耗时漫长的低效扫描操作。
- 执行计划信息，用于判断是否命中了索引，或者存在锁冲突的情况。
- 操作ID、时间、客户端等信息，方便定位出产生慢操作的源头。
opid表示当前操作在数据库进程中的唯一编号。如果已经发现该操作正在导致数据库系统响应缓慢，则可以考虑将其“杀”死
db.killOp(4001)
db.currentOp默认输出当前系统中全部活跃的操作，由于返回的结果较多，我们可以指定一些过滤条件:
# 查看等待锁的增加、删除、修改、查询操作
db.currentOp({
waitingForLock:true,
$or:[
{op:{$in:["insert","update","remove"]}},
{"query.findandmodify":{$exists:true}}
]
})
查看执行时间超过1s的操作
db.currentOp({
secs_running:{$gt:1}
})
查看test数据库中的操作
db.currentOp({
ns: /test/
})
对示例操作的解读如下:
（1）从ns、op字段获知，当前进行的操作正在对test.items集合执行update命令。
（2）command字段显示了其原始信息。其中，command.q和command.u分别展示了update的查询条件和更新操作。
（3）“planSummary”：“COLLSCAN” 说明情况并不乐观，update没有利用索引而是正在全表扫描。
（4）microsecs_running：NumberLong（186070）表示操作运行了186ms，注意这里的单位是微秒。
优化方向：
- value字段加上索引
- 如果更新的数据集非常大，要避免大范围update操作，切分成小批量的操作
currentOp命令输出说明
- currentOp.type：操作类型，可以是op、idleSession、idleCursor的一种，一般的操作信息以op表示。其为MongoDB 4.2版本新增功能。
- currentOp.host：主机的名称。currentOp.desc：连接描述，包含connectionId。currentOp.connectionId：客户端连接的标识符。currentOp.client：客户端主机和端口。currentOp.appName：应用名称，一般是描述客户端类型。
- currentOp.clientMetadata：关于客户端的附加信息，可以包含驱动的版本。currentOp.currentOpTime：操作的开始时间。MongoDB 3.6版本新增功能。
- currentOp.lsid：会话标识符。MongoDB 3.6版本新增功能。
- currentOp.opid：操作的标志编号。
- currentOp.active：操作是否活跃。如果是空闲状态则为false。
- currentOp.secs_running：操作持续时间（以秒为单位）。
- currentOp.microsecs_running：操作持续时间（以微秒为单位）。
- currentOp.op：标识操作类型的字符串。可能的值是：“none” “update” “insert”“query”“command” “getmore” “remove” “killcursors”。其中，command操作包括大多数命令，如createIndexes和findAndModify。
- currentOp.ns：操作目标的集合命名空间。
- currentOp.command：操作的完整命令对象的文档。如果文档大小超过1KB，则会使用一种$truncate形式表示。
- currentOp.planSummary：查询计划的概要信息。
- currentOp.locks：当前操作持有锁的类型和模式。
- currentOp.waitingForLock：是否正在等待锁。
- currentOp.numYields：当前操作执行yield（让步）的次数。一些锁互斥或者磁盘I/O读取都会导致该值大于0。
- currentOp.lockStats：当前操作持有锁的统计。
- currentOp.lockStats.acquireCount：操作以指定模式获取锁的次数。
- currentOp.lockStats.acquireWaitCount：操作获取锁等待的次数，等待是因为锁处于冲突模式。acquireWaitCount小于或等于acquireCount。
- currentOp.lockStats.timeAcquiringMicros：操作为了获取锁所花费的累积时间（以微秒为单位）。timeAcquiringMicros除以acquireWaitCount可估算出平均锁等待时间。
- currentOp.lockStats.deadlockCount：在等待锁获取时，操作遇到死锁的次数。
