1 测试目的
模拟生产环境,测试当前mongoDB的各项性能。
2 测试环境
2.1 软件配置
2.2 硬件配置
3 测试工具
YCSB是雅虎开源的NoSQL测试工具,通常用来对noSQL数据库进行性能,这里我们使用的是ycsb-mongodb-binding-0.15.0.tar.gz包。
需要新建配置文件,并调整参数,并利用load/run命令,加载数据进行性能测试。
3.1使用简介
#ycsb包解压后的目录结构
#使用前,我们要先了解命令结构
命令示例:
#/opt/ycsb/ycsb-mongodb-binding-0.15.0/bin/ycsb load mongodb -threads 1 -P workloads/workloada -p fieldcount=1 -p fieldlength=1024 -p table=ycsb1 -p clientbuffering=true -p mongodb.url=mongodb://用户:密码@ip:port/test?authSource=admin
表1-4 命名参数说明
参数 |
含义 |
bin/ycsb |
命令本身。 |
load/run/shell |
指定这个命令的作用,分别代表加载数据/运行测试/交互界面。 |
mongodb/hbase10/basic.. |
指定这次测试使用的驱动,也就是这次究竟测的是什么数据库,有很多选项,可以ycsb --help看到所有。 |
threads |
线程数,模拟客户端数 |
-P |
选择加载的配置文件 |
workloads/workloada |
指定测试的参数文件,默认有6种测试模板,加一个大模板; workloada:读写均衡型,50%/50%,Reads/Writes workloadb:读多写少型,95%/5%,Reads/Writes workloadc:只读型,100%,Reads workloadd:读最近写入记录型,95%/5%,Reads/insert workloade:扫描小区间型,95%/5%,scan/insert workloadf:读写入记录均衡型,50%/50%,Reads/insert workload_template:参数列表模板 |
-p fieldcount=1 |
单条记录字段个数:1 |
-p fieldlength=1024 |
每个字段的大小: 1024Bytes |
-p table= |
自定义表名 |
-p clientbuffering=true |
客户端写缓存 |
-p mongodb.url= |
指定测试的数据库的认证信息,账号密码,地址端口和库名 |
3.2 YCSB测试参数解析
workloads目录里面下包含自带了6种压力测试场景。 如下图:
文件和相应场景的对应关系如下:
workloada:读写均衡型,50%/50%,Reads/Writes
workloadb:读多写少型,95%/5%,Reads/Writes
workloadc:只读型,100%,Reads
workloadd:读最近写入记录型,95%/5%,Reads/insert
workloade:扫描小区间型,95%/5%,scan/insert
workloadf:读写入记录均衡型,50%/50%,Reads/insert
示例文件:
#vim workloads/workloada
表1-5 workload参数含义
参数 |
含义 |
recordcount=1000
|
YCSB load(加载元数据)命令的参数,默认值1000表示默认加载的记录条数,可以在命令行显示修改该值。 |
operationcount=1000
|
YCSB run(运行压力测试)命令的参数,默认值1000表示默认选取数据库中的1000条数据进行压力测试。对于workloada这种测试场景,就意味着读数据在500左右,写数据也在500左右。 |
workload=com.yahoo.ycsb.workloads.CoreWorkload
|
指定了workload的实现类为 com.yahoo.ycsb.workloads.CoreWorkload |
readallfields=true |
表示查询时是否读取记录的所有字段 |
readproportion=0.5 |
表示读操作的比例,该场景为0.5 |
updateproportion=0.5 |
表示更新操作的比例,该场景为0.5 |
scanproportion=0 |
表示扫描操作的比例 |
insertproportion=0 |
表示插入操作的比例 |
requestdistribution=zipfian
|
表示请求的分布模式,YCSB提供uniform, zipfian, latest三种分布模式, Uniform(等概率随机选择记录)、Zipfian(随机选择记录,存在热纪录)和Latest(近期写入的记录是热记录) |
3.3 YCSB测试工具命令
1.先为指定的库和表指定hash分片
mongo ip:端口
>sh.enableSharding("test")
>sh.shardCollection("test.usertable", {_id:"hashed"})
2.修改业务模型
#cd /opt/ycsb-mongodb-binding-0.15.0/workloads
#只插入100万条数据
#vi workload-s1
3.数据写入
#cd /opt/ycsb/ycsb-mongodb-binding-0.15.0
#/opt/ycsb/ycsb-mongodb-binding-0.15.0/bin/ycsb load mongodb -threads 50 -P workloads/workload-s1-p fieldcount=1 -p fieldlength=1024
-p clientbuffering=true -p table=ycsb1 -p mongodb.url=mongodb://账号:密码@ip:端口,ip:端口,ip:端口/test?authSource=admin
4.查看插入的数据
#mongo ip:端口
>use test
>db.stats();
插入100万条数据后,可以看到每个share上都有33万多的objects,
5.结果参数说明
表1-6 ycsb运行结果说明
参数 |
说明 |
RunTime(ms): |
运行总时间(毫秒) |
Throughput(ops/sec): |
吞吐量,每秒操作数 |
[TOTAL_GCS_PS_Scavenge], Count: |
Parallel Scavenge 回收次数 |
[TOTAL_GC_TIME_PS_Scavenge], Time(ms): |
Parallel Scavenge 回收时间 |
[TOTAL_GC_TIME_%_PS_Scavenge], Time(%): |
Parallel Scavenge 回收时间百分比 |
[TOTAL_GCS_PS_MarkSweep], Count: |
PS MarkSweep 回收次数 |
[TOTAL_GC_TIME_PS_MarkSweep], Time(ms): |
PS MarkSweep 回收时间 |
[TOTAL_GC_TIME_%_PS_MarkSweep], Time(%): |
PS MarkSweep 回收时间百分比 |
[TOTAL_GCs], Count: |
全局 GC 次数 |
[TOTAL_GC_TIME], Time(ms): |
全局 GC 时间 |
[TOTAL_GC_TIME_%], Time(%): |
全局 GC 时间百分比 |
不同操作类型:READUPDATEINSERTSCAN等; |
|
Operations |
总操作数 |
AverageLatency(us) |
平均延迟(微秒) |
MinLatency(us) |
最小延迟(微秒) |
MaxLatency(us) |
最大延迟(微秒) |
95thPercentileLatency(us) : |
95%的样本延迟低于该值 |
99thPercentileLatency(us) |
99%的样本延迟低于该值 |
Return=OK |
结果(正确),总操作数 |
4 测试方法
- 使用YCSB-mongoDB对测试环境下test库进行各项测试。
4.1 测试环境
4.2测试模型
4.3测试指标
(1)OPS:Operator per Second,数据库每秒执行的操作数。
(2)AverageLatency,平均响应时间。
(3)评判指标:直到发现ops不再增加而平均响应时间继续增加;
4.4测试步骤
1.先为指定的库和表指定hash分片
#mongo ip:端口
>sh.enableSharding("test")
>sh.shardCollection("test.ycsb1", {_id:"hashed"})
2.文档模型:
修改YCSB配置,每个文档大小约为1KB,默认“_id”索引。
3.配置workload文件。
按照表1-8业务模型所示的业务模型,配置workload中的“readproportion”、“insertproportion”、“updateproportion”等值。
4.以业务模型workload_s1为例,执行以下命令,准备数据。
#cd /opt/ycsb/ycsb-mongodb-binding-0.15.0
#/opt/ycsb/ycsb-mongodb-binding-0.15.0/bin/ycsb load mongodb -threads 50 -P workloads/workload-s1 -p fieldcount=1 -p fieldlength=1024
-p clientbuffering=true -p table=ycsb1 -p mongodb.url=mongodb://账号:密码@ip:端口,ip:端口,ip:端口/test?authSource=admin
1>workload_s1_load.result 2> workload_s1_load.log
5.以业务模型workload_s1为例,执行以下命令,测试性能
#cd /opt/ycsb/ycsb-mongodb-binding-0.15.0
#/opt/ycsb/ycsb-mongodb-binding-0.15.0/bin/ycsb run mongodb -threads 50 -P workloads/workload-s1 -p fieldcount=1 -p fieldlength=1024
-p clientbuffering=true -p table=ycsb1 -p mongodb.url=mongodb://账号:密码@ip:端口,ip:端口,ip:端口/test?authSource=admin
1>workload_s1_run.result 2> workload_s1_run.log
5 测试用例
5.1 用例1 insert mongoDB测试库
测试用例1:插入mongoDB测试库 |
|
测试目的 |
在测试库100% 导入1亿条数据,观察请求状态 |
前置条件 |
1、mongoDB正常运行 |
步骤 |
1、根据需求测试项,指定mongodb分片,调整测试模型 2、准备数据 /opt/ycsb/ycsb-mongodb-binding-0.15.0/bin/ycsb load mongodb -threads 50 -P workloads/workload-s1 -p fieldcount=1 -p fieldlength=1024 -p clientbuffering=true -p table=ycsb1 -p mongodb.url=mongodb://账号:密码@ip:端口,ip:端口,ip:端口/test?authSource=admin 1>workload_s1_load.result 2> workload_s1_load.log 3、测试数据 /opt/ycsb/ycsb-mongodb-binding-0.15.0/bin/ycsb run mongodb -threads 50 -P workloads/workload-s1 -p fieldcount=1 -p fieldlength=1024 -p clientbuffering=true -p table=ycsb1 -p mongodb.url=mongodb://账号:密码@ip:端口,ip:端口,ip:端口/test?authSource=admin 1>workload_s1_run.result 2> workload_s1_run.log 4、记录测试结果 5、调整线程数,继续测试,并记录结果 6、通过调整线程数,直到发现ops不再增加而响应时间继续增加。 |
获取指标 |
1、读写耗时、吞吐量、平均响应时间 |
参数化变量 |
|
数据准备要求 |
|
备注 |
在测试前,确保网络畅通 |
5.2 用例2 update&read mongoDB测试库
测试用例2:update&read mongoDB测试库 |
|
测试目的 |
在测试库90%更新和10%读取测试1亿条数据,观察请求状态 |
前置条件 |
1、mongoDB正常运行 |
步骤 |
1、根据需求测试项,指定mongodb分片,调整测试模型 2、预备数据 参照如上命令 3.测试数据 参照如上命令 4、记录测试结果; 5、调整线程数,继续测试,并记录结果; 6、通过调整线程数,直到发现ops不再增加而响应时间继续增加。 |
获取指标 |
1、读写耗时、吞吐量、平均响应时间 |
参数化变量 |
|
数据准备要求 |
|
备注 |
在测试前,确保网络畅通 |
5.3 用例3 read&insert&update mongoDB测试库
测试用例3:update&read mongoDB测试库 |
|
测试目的 |
在测试库65%读取,10%插入和25%更新测试1亿条数据,观察请求状态 |
前置条件 |
1、mongoDB正常运行 |
步骤 |
1、根据需求测试项,指定mongodb分片,调整测试模型 2、预备数据 参照如上命令 3.测试数据 参照如上命令 4、记录测试结果; 5、调整线程数,继续测试,并记录结果; 6、通过调整线程数,直到发现ops不再增加而响应时间继续增加。 |
获取指标 |
1、读写耗时、吞吐量、平均响应时间 |
参数化变量 |
|
数据准备要求 |
|
备注 |
在测试前,确保网络畅通 |
5.4 用例4 read&update mongoDB测试库
测试用例4:read&update mongoDB测试库 |
|
测试目的 |
在测试库50%读取,50%更新测试1亿条数据,观察请求状态 |
前置条件 |
1、mongoDB正常运行 |
步骤 |
1、根据需求测试项,指定mongodb分片,调整测试模型 2、预备数据 参照如上命令 3.测试数据 参照如上命令 4、记录测试结果; 5、调整线程数,继续测试,并记录结果; 6、通过调整线程数,直到发现ops不再增加而响应时间继续增加。 |
获取指标 |
1、读写耗时、吞吐量、平均响应时间 |
参数化变量 |
|
数据准备要求 |
|
备注 |
在测试前,确保网络畅通 |
5.5 用例5 read mongoDB测试库
测试用例5:read mongoDB测试库 |
|
测试目的 |
在测试库100%读取1亿条数据,观察请求状态 |
前置条件 |
1、mongoDB正常运行 |
步骤 |
1、根据需求测试项,指定mongodb分片,调整测试模型 2、预备数据 参照如上命令 3.测试数据 参照如上命令 4、记录测试结果; 5、调整线程数,继续测试,并记录结果; 6、通过调整线程数,直到发现ops不再增加而响应时间继续增加。 |
获取指标 |
1、读写耗时、吞吐量、平均响应时间 |
参数化变量 |
|
数据准备要求 |
|
备注 |
在测试前,确保网络畅通 |
6 测试场景
测试类别 |
场景 |
场景的组织 |
场景的控制 |
用例 |
|||
mongoDB性能测试 |
场景1 |
6.1插入性能测试 100% insert |
云服务自带监控 |
mongoDB性能测试 |
场景2 |
6.2更新,读取性能测试 90% update ,10% read |
云服务自带监控 |
mongoDB性能测试 |
场景3 |
6.3读取,插入,更新性能测试 65% read ,25% insert, 10% update |
云服务自带监控 |
mongoDB性能测试 |
场景4 |
6.4 读取,更新性能测试 50% read , 50% update |
云服务自带监控 |
mongoDB性能测试 |
场景5 |
6.5 读取性能测试 100% read |
云服务自带监控 |
7 测试结果分析
7.1 Intert性能测试
7.1.1 测试参数记录
分片集群100% insert写入测试记录结果如下:
线程 |
类型 |
数据条数 |
runtime(ms) |
Ops/sec |
AverageLatency(us) |
操作执行数 |
50 |
分片-insert |
|
|
|
||
100 |
分片-insert |
|
|
|
|
|
200 |
分片-insert |
|
|
|
|
|
400 |
分片-insert |
|
|
|
7.1.2测试结果
绘制图表
7.1.3 资源情况分析
Mongos是数据库集群请求的入口,所有的请求都通过mongos进行协调,不需要在应用程序添加一个路由选择器,
mongos自己就是一个请求分发中心,它负责把对应的数据请求请求转发到对应的shard服务器上。
1.下图100线程时,使用mongostat监测到mongos的情况;
参数解释:
inserts 每秒插入次数
command 每秒的命令数
vsize 虚拟内存使用量
res 物理内存使用量
net_in/net_out 网络进出流量
2.下图为200线程时,mongos的cpu和带宽使用情况;
Mongos的cpu使用率稳定在50%左右,输入流量稳定在13MB/s;mongos进行协调请求,
再将数据进行转发到后端;通过监控到mongos的cpu,内存,网络带宽一直处在稳定的状态;
3.Config server,为配置服务器,存储所有数据库元信息(路由、分片)的配置。在生
产环境通常有多个 config server 配置服务器,因为它存储了分片路由的元数据,防止数据丢失。
下图为400线程下config的cpu和内存使用率;cpu稳定在20%以下,内存稳定在30%以下;
4.每个分片都是一个独立的数据库,所有的分片组合起来构成一个逻辑上的完整的数据库。
分片机制降低了每个分片的数据操作量及需要存储的数据量,达到多台服务器来应对不断增加的负载和数据的效果。
下图为400线程,share的cpu,内存和带宽使用情况,看到cpu大部分时间已处于100%的状态;内存使用率在60%以下,带宽为16MB/s;
在云环境上,后端为分布式存储池,无法监控具体的磁盘写入情况;
但每当内存中的数据累计到一定量(或者一定时间),MongoDB会将内存数据flush到磁盘,
并清理脏页数据,此时该shard的cpu使用率也会飙升,达到规格上限;
后续省略
。
。
。
8 测试结果总结
1.当前测试结果绘制图表
2.当前瓶颈分析
Sharding cluster是一种可以水平扩展的模式,在数据量很大时特给力,实际大规模应用一般会采用这种架构去构建。
sharding分片很好的解决了单台服务器磁盘空间、内存、cpu等硬件资源的限制问题,把数据水平拆分出去,降低单节点的访问压力。
从以上测试记录,当share的cpu达到100%时,插入,更新和读取等操作性能有所下降,综上,目前性能受限于分片的cpu。
特别说明:测试结论只适用于本次测试;