Mongodb性能压测

一、背景

这几天对所有的基础组件做一个摸底的基准压力测试，目前我们所有的开源基础组件都没有做过性能测试，经常有开发人员问，我们的RDS、MongoDB集群能抗多大量呀，这个时候我是没办法回复的，因为我自己也不知道，虽然一个数据库集群能抗多大量，在软件、硬件配置固定的情况下，和业务场景有很大的关系，如果数据量小，查询SQL简单那吞吐量自然很高，如果数据量特别大并且都是复杂SQL，那吞吐量自然上不去；但是既然人家问了，肯定是希望有一个答案，如果你说不知道，那会给人一种不靠谱的感觉，所以做一次基准压力测试，我们知道在特定的场景下我们的集群能有多大的吞吐量，做到自己心里有数，才给别人信心。这周在压测MongoDB，谷歌了一番，MongoDB的压测工具很少，有几篇是介绍通过YCSB压测MongoDB的，找丹姐（逻辑思维首席DBA）推荐一款MongoDB的压测工具，丹姐也推荐YCSB，好吧，那就它吧，开整。

二、环境说明

1、MongoDB集群配置（一个分片的shard集群）

2、MongoDB版本

4.0.4-62-g7e345a7
4、系统及内核版本


CentOS Linux release 7.5.1804 (Core)
3.10.0-862.14.4.el7.x86_64

3、YCSB版本

YCSB-0.16.0-RC1.

4、测试说明

三、安装

1、jdk及maven安装参考官方

https://github.com/brianfrankcooper/YCSB/tree/master/mongodb

2、安装YCSB

wget https://github.com/brianfrankcooper/YCSB/archive/0.16.0-RC1.tar.gz
tar -zxvf YCSB-0.16.0-RC1.tar.gz
cd YCSB-0.16.0-RC1/
mvn clean package -Dmaven.test.skip=true

PS：
安装过程中maven下载依赖需要×××，如果有安装失败的包，需要在能×××的服务器上下载手动安装，比如mongodb-async-driver-2.0.1.jar就需要×××，下面是手动安装方法
A、手动下载jar包
wget http://www.allanbank.com/repo/com/allanbank/mongodb-async-driver/2.0.1/mongodb-async-driver-2.0.1.jar
B、加压包，从pom.xml 文件里面查看groupId、artifactId、version
C、手动安装

mvn install:install-file -Dfile=/tmp/mongodb-async-driver-2.0.1.jar  -DgroupId=com.allanbank -DartifactId=mongodb-async-driver -Dversion=2.0.1 -Dpackaging=jar
mvn -pl com.yahoo.ycsb:mongodb-binding -am clean package

四、压测

1、编写压测文件

在workloads目录下有很多压测文件用到的文件，我们从其中一个copy一份，编辑添加我们自己定义的内容

vim workloads/2000w

ongodb.url=mongodb://root:[email protected]:27000
mongodb.writeConcern=normal
table=chj_2000w
recordcount=20000000
operationcount=50000000
readallfields=true
readproportion=0
updateproportion=0
scanproportion=0
insertproportion=1
requestdistribution=zipfian
workload=com.yahoo.ycsb.workloads.CoreWorkload

关于YCSB的压测文件的每个参数的解释如下：

fieldcount: 每条记录字段个数 (default: 10)
fieldlength: 每个字段长度 (default: 100)
readallfields: 是否读取所有字段true或者读取一个字段false (default: true)
readproportion: 读取作业比例 (default: 0.95)
updateproportion: 更新作业比例 (default: 0.05)
insertproportion: 插入作业比例 (default: 0)
scanproportion: 扫描作业比例 (default: 0)
readmodifywriteproportion: 读取一条记录修改它并写回的比例 (default: 0)
requestdistribution: 请求的分布规则 uniform, zipfian or latest (default: uniform)
maxscanlength: 扫描作业最大记录数 (default: 1000)
scanlengthdistribution: 在1和最大扫描记录数的之间的分布规则 (default: uniform)
insertorder: 记录被插入的规则ordered或者hashed (default: hashed)
operationcount: 执行的操作数.
maxexecutiontime: 执行操作的最长时间，当然如果没有超过这个时间以运行时间为主。
table: 测试表的名称 (default: usertable)
recordcount: 加载到数据库的纪录条数 (default: 0)

2、造数据，也是测写入性能

./bin/ycsb load mongodb -threads 100 -P workloads/2000w
输出结果说明

[OVERALL], RunTime(ms), 37182  #数据加载所用时间(毫秒)
[OVERALL], Throughput(ops/sec), 13447.367005540314  #加载操作的吞吐量(ops/sec)
[TOTAL_GCS_PS_Scavenge], Count, 37
[TOTAL_GC_TIME_PS_Scavenge], Time(ms), 146
[TOTAL_GC_TIME_%_PS_Scavenge], Time(%), 0.3926631165617772
[TOTAL_GCS_PS_MarkSweep], Count, 0
[TOTAL_GC_TIME_PS_MarkSweep], Time(ms), 0
[TOTAL_GC_TIME_%_PS_MarkSweep], Time(%), 0.0
[TOTAL_GCs], Count, 37
[TOTAL_GC_TIME], Time(ms), 146
[TOTAL_GC_TIME_%], Time(%), 0.3926631165617772
[CLEANUP], Operations, 64
[CLEANUP], AverageLatency(us), 422.09375
[CLEANUP], MinLatency(us), 0
[CLEANUP], MaxLatency(us), 26911
[CLEANUP], 95thPercentileLatency(us), 3
[CLEANUP], 99thPercentileLatency(us), 30
[INSERT], Operations, 500000  # 执行insert操作的总数
[INSERT], AverageLatency(us), 4658.931652  # 每次insert操作的平均延时(微秒)
[INSERT], MinLatency(us), 831 # 所有insert操作的最小延时(微秒)
[INSERT], MaxLatency(us), 1784831 # 所有insert操作的最大延时(微秒)
[INSERT], 95thPercentileLatency(us), 9711  # 95%的insert操作延时在9毫秒以内
[INSERT], 99thPercentileLatency(us), 17903 # 99%的insert操作延时在17毫秒以内
[INSERT], Return=OK, 500000

3、压测

通过调整压测文件中read和update的比例，模拟只读和读写混合的操作

./bin/ycsb run mongodb -threads 100 -P workloads/2000w

[OVERALL], RunTime(ms), 1735408
[OVERALL], Throughput(ops/sec), 2881.1668495247227
[TOTAL_GCS_PS_Scavenge], Count, 3975
[TOTAL_GC_TIME_PS_Scavenge], Time(ms), 6180
[TOTAL_GC_TIME_%_PS_Scavenge], Time(%), 0.3561122226012557
[TOTAL_GCS_PS_MarkSweep], Count, 0
[TOTAL_GC_TIME_PS_MarkSweep], Time(ms), 0
[TOTAL_GC_TIME_%_PS_MarkSweep], Time(%), 0.0
[TOTAL_GCs], Count, 3975
[TOTAL_GC_TIME], Time(ms), 6180
[TOTAL_GC_TIME_%], Time(%), 0.3561122226012557
[READ], Operations, 500346
[READ], AverageLatency(us), 2851.9638989819045
[READ], MinLatency(us), 696
[READ], MaxLatency(us), 646655
[READ], 95thPercentileLatency(us), 6991
[READ], 99thPercentileLatency(us), 23103
[READ], Return=OK, 500346
[CLEANUP], Operations, 10
[CLEANUP], AverageLatency(us), 3131.0
[CLEANUP], MinLatency(us), 1
[CLEANUP], MaxLatency(us), 31295
[CLEANUP], 95thPercentileLatency(us), 31295
[CLEANUP], 99thPercentileLatency(us), 31295
[UPDATE], Operations, 4499654
[UPDATE], AverageLatency(us), 3534.2083122391186
[UPDATE], MinLatency(us), 704
[UPDATE], MaxLatency(us), 1078271
[UPDATE], 95thPercentileLatency(us), 11647
[UPDATE], 99thPercentileLatency(us), 27343
[UPDATE], Return=OK, 4499654

五、指标观察

1、服务器指标，主要观察CPU、内存、磁盘IO的利用率和延时，可以通过top、iostat工具查看实时情况
2、MongoDB可以通过mongostat 工具查看实时情况

mongostat的输出说明

inserts：每秒插入次数
query：每秒查询次数
update：每秒更新次数
delete：每秒删除次数
getmore：每秒执行getmore次数
command：每秒的命令数，比以上插入、查找、更新、删除的综合还多，还统计了别的命令
dirty：WiredTiger存储引擎中dirty 数据占缓存百分比
used:WiredTiger存储引擎中引擎使用缓存占百分比
flushs：每秒执行fsync将数据写入硬盘的次数。
vsize：虚拟内存使用量，单位MB
res：物理内存使用量，单位MB
qrw:客户端等待读的长度,队列中的长度
arw:客户端等待写的队列长度
netIn 和 netOut：网络流量，单位是字节 byte
conn：当前连接数
time：时间戳

六、测试结果

原文地址：https://blog.51cto.com/navyaijm/2421973

时间： 2024-07-30 08:23:50

Mongodb性能压测的相关文章

感受真实性能压测的“洪荒之力” 压测宝有奖体验中

作为测试,你有没有遇到这样的问题:1.熬了多少个日夜的系统终于快上线了,不知道上线后系统负载能力怎样?2.促销季到了,应用性能如何?到底能不能支持500w并发用户?3.怎么做压测才能更接近线上真实环境? 系统负载有多强,压测一下就知道.云智慧压测宝3步6分钟 开启真实用户的性能压测 8月16至9月2日申请试用压测宝,感受真实压测的洪荒之力,还有机会获得优酷视频会员卡,速速来领- 参与活动赢优酷会员卡 1.从这里申请试用压测宝:[url=http://yacebao.com/landingPage

swingbench-免费的oracle性能压测工具

SwingBench介绍: SwingBench由负载生成器,协调器和集群概述组成.该软件使得能够生成负载并且将图表的事务/响应时间映射. SwingBench可用于演示和测试诸如实际应用集群,在线表重建,备用数据库,在线备份和恢复等技术 SwingBench附带的代码包括6个基准,OrderEntry,SalesHistory,TPC-DS Like,JSON,CallingCircle和StressTest .. OrderEntry基于Oracle11g / Oracle12c附带的"oe

接口测试及服务器性能压测

目前移动端app大都还是采用的http或者https协议写的restful接口,一般的辅助类http劫持(fiddler,charles)和模拟发送(postman)工具都可以满足单次单个接口的测试需求,但这种依附工具的测试很难满足多接口调用逻辑验证问题,也不太灵活,没办法做到数据化,还有就是对于接口压测和服务器性能压力测试无法满足,又得借助于其他压测工具(Jmeter loadrunner等),设计一套基于http和https灵活定制的接口测试框架还是很有必要的. 一般app接口调用都要都要传

性能压测诡异的Requests/second 响应刺尖问题

最近一段时间都在忙着转java项目最后的冲刺,前期的coding翻代码.debug.fixbug都逐渐收尾,进入上线前的性能压测. 虽然不是大促前的性能压测要求,但是为了安全起见,需要摸个底心里有个数. 毕竟这次转java的服务都是集团核心公共服务(主要是订单域服务).(等我们顺利上线了,我再来好好总结下其中的坎坷和壮举.) 废话不多说了,直接进入主题. 由于这次压测主要重点是关注正向的两个核心订单服务,下单服务.查单服务.查单服务初步压测下来问题不大,主要是db的索引和cache的问题. 下单

后端服务性能压测实践

转自:https://mp.weixin.qq.com/s/XW9geHZ9odHdI7srDiKBIg 目录 背景 环境检测 压力机及压力工具检测 Linux openfiles limit 设置 排查周边依赖 空接口压测检测 聚合报告中 throughput 计算 压测及性能排查方法 关注各纬度 log Linux 常规命令 性能排查两种方式(从上往下.从下往上) 总结 背景 最近大半年内有过两次负责性能压测的一些工作.一件事情做了一次可能还无法总结出一些东西,两次过后还是能发现一些共性问题

(转)后端服务性能压测实践

作者:王清培(Plen wang) 传送门:https://www.cnblogs.com/wangiqngpei557/p/7953453.html ---------------------------------------------------------------------分割线------------------------------------------------------ 入职新公司,没人理我,负责的需求开发一直很忙,要么环境有问题,要么Bug卡住我找开发,回了一句

虚拟网卡性能压测

本文主要介绍多种场景下,虚拟机网卡的压测及性能对比,根据openstack实际的部署方式,虚拟机网卡压测场景包括 SRIOV(passthrough).SRIOV+Macvtap(passthrough).Vlan+Linux bridge.OVS+Linux Bridge,分别从协议类型(TCP/UDP).Message Size方向压测虚拟机网卡的时延.发包率.吞吐量. 压测环境 host1:  服务器型号:IBM x3550m2 CPU型号:Intel(R) Xeon(R) CPU*8,每

SSDB性能压测报告

测试场景 机器: 两台Intel(R) Xeon(R) E5506  2.13GHz  (4核 8线程)*2/内存32GB/SAS 300G 数据: key: 10位顺序数字     value: 50字节      数据量: 2kw 并发: 并发数依次为10.20.40.80.160 压测工具:redis-benchmark ssdb 版本: 1.9.2 ssdb 配置: leveldb: cache_size: 5120 block_size: 32 write_buffer_size: 6

RocketMQ性能压测分析（转）

原创文章,转载请注明出处:http://jameswxx.iteye.com/blog/2093785 一   机器部署 1.1  机器组成 1台nameserver 1台broker  异步刷盘 2台producer 2台consumer 1.2  硬件配置 CPU  两颗x86_64cpu,每颗cpu12核,共24核 内存 48G 网卡 千兆网卡 磁盘 除broker机器的磁盘是RAID10,共1.1T,其他都是普通磁盘约500G 1.3  部署结构 橙色箭头为数据流向,黑色连接线为网络连接