开头还是介绍一下群,如果感兴趣polardb ,mongodb ,mysql ,postgresql ,redis 等有问题,有需求都可以加群群内有各大数据库行业大咖,CTO,可以解决你的问题。加群请联系 liuaustin3.
这个问题来自于我们内部的一个项目,本身MONGODB 并没有特别的大,只是偶发有读写队列瞬时增高的情况。在发生这个情况的时候,会出现global lock 同时会出现写入缓慢的问题。
所以这个问题出现后我发现我对MOGNODB 的锁真的不了解,所以解决问题之前必须弄明白。
首先根据我们的认知,mongodb是一个高速型的数据库产品,也就是说MONGODB 和传统数据库不一样,如果你的查询在 500ms 已经可以算为慢查询了,而在很多传统数据库中,这是正常的。那么一个mongodb中的性能的好坏与mongodb的锁的百分比有很大的关系。
在不少人的头脑中,感觉mongodb是一个无事务的数据库产品,实际上MONGODB 与传统数据库在这部分是一致的,具有mvcc,具有多版本控制,以及并发等功能,同时接受成百上千的.
实际上mongodb的锁也是多粒度的,通过锁来阻止同一个docuemnt在同一个时间被修改。而在读取的过程中,是不会对数据进行锁定的但是会跟踪你的锁定的频率,作为一个指标来对你的数据库进行跟踪。而这个锁定的频率统计是在两个层面,database 和 global . 在锁这个层面上,对于数据库层,只会对不同的用户进行加锁,而不会对在上层进行加锁。
实际上从mongodb的角度来看,mognodb的本身也将一些在写库上的锁进行了分离,如MONGODB本身的多节点,读写分离的方式,让读和写在物理上就进行了分离。所以如果一个利用了MONGODB 的从节点的部分的应用可能在锁方面产生的问题就比较少了。
如果遇到了锁定的部分比较多的情况,一般是系统响应的问题,具体可能有性能较差的 mongodb 的查询或者系统无法满足当前诉求产生的问题。
1 globalLock
4.4
5.0
2 locks
4.4
5.0
通过上面的两个命令,可以查看MONGODB 锁的部分的信息和内容,那么我们怎么解读这些指标和数据来对应我们对于MONGODB 的观测和问题的发现
1 globalLock.currentQueue.total
这个部分主要体现了两个问题 1并发性,如果系统中并发较多,则这个部分的totoal 会有波动,同时如果有需求等待锁的情况下,这个位置的数字会上升。
剩下的readers ,writers 两种是分别表达你的锁的需求来自于 read 还是 write
2 globalLock.totalTime
这个部分的数值需要和你的实际的服务器的运行的时间进行比较,如果你的这部分时间和实际的服务器的运行时间之间差距较大。
4.4
5.0
在4.4的版本中,我们可以通过acquireWaitCount 部分,来获取等待获取资源的等待时间,如果在短期这个数值上升的很高,那么说明系统正在存在大量的系统资源的。
所以撰写一个程序,在发现问题的情况下,快速的收集数据并将这些数据进行比对,可以快速的发现系统中出现的问题。如果后面我们写出这样的程序,也会和大家分享。
同时遇到这个问题,需要综合的去分析和收集数据,global lock 高的原因还需要更详细的分析。