Mongodb uses YCSB performance pressure test

Background In recent days, we have done a ben...
1. MongoDB cluster configuration (a shard cluster)
2. MongoDB version
3. YCSB version
4. Test instructions
1. jdk and maven installation reference official
2. Install YCSB
1. Preparation of pressure test documents
2. Build data, also test write performance
3. Pressure measurement
Background

In recent days, we have done a benchmark stress test for all the basic components. At present, none of our open-source basic components has done a performance test. Developers often ask how much our RDS and MongoDB clusters can resist. At this time, I can't reply because I don't know. Although a database cluster can resist how much, in software and hardware When the configuration is fixed, it has a lot to do with the business scenario. If the data volume is small, the query SQL is simple, and the throughput is naturally high. If the data volume is especially large and all of them are complex SQL, the throughput will not go up naturally. But since people ask, they certainly hope to have an answer. If you don't know, it will give people a sense of unreliability, so make a benchmark In stress testing, we know how much throughput our cluster can have in a specific scenario. Only when we have a clear idea can we give others confidence. This week, I Google MongoDB. There are few MongoDB pressure measuring tools. There are several articles that introduce MongoDB pressure testing through YCSB. I asked Danjie (chief DBA of logical thinking) to recommend a MongoDB pressure measuring tool, and Danjie also recommended YCSB. OK, let's just open it.

2, Environmental description

1. MongoDB cluster configuration (a shard cluster)

2. MongoDB version

4.0.4-62-g7e345a7
4. System and kernel version

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

3. YCSB version

YCSB-0.16.0-RC1.

4. Test instructions

Three, installation

1. jdk and maven installation reference official

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

2. Install 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:
During the installation process, the maven download depends on XXX. If there is a package that fails to be installed, you need to download the manual installation on a server that can XXX. For example, mongodb-async-driver-2.0.1.jar requires XXX. The following is the manual installation method
A. Download jar package manually
wget http://www.allanbank.com/repo/com/allanbank/mongodb-async-driver/2.0.1/mongodb-async-driver-2.0.1.jar
B. Pressurize the package. View groupId, artifactId and version in pom.xml file
C. Manual installation

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
Four. Pressure measurement

1. Preparation of pressure test documents

There are many files used for the pressure test files in the workloads directory. We can edit and add our own defined content from one 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

The interpretation of each parameter of YCSB's pressure test file is as follows:

fieldcount: number of fields per record (default: 10) fieldlength: length of each field (default: 100) readallfields: whether to read all fields true or read a field false (default: true) Readproportioning: read job proportion (default: 0.95) updateproportion: update job proportion (default: 0.05) insertproportion: insert job proportion (default: 0) scanproportion: scan job proportion (default: 0) Readmodifywriteprovision: the ratio of reading a record to modify it and writing it back (default: 0) requestdistribution: uniform, zipfian or latest (default: uniform) maxscanlength: scan job maximum records (default: 1000) scanlengthdistribution: the distribution rule between 1 and the maximum number of scan records (default: uniform) insertorder: record the inserted rule ordered or hashed (default: hashed) operationcount: the number of operations performed maxexecutiontime: the maximum time to execute an operation. Of course, if it does not exceed this time, the running time is the main time. Table: name of test table (default: usertable) recordcount: number of records loaded into the database (default: 0)

2. Build data, also test write performance

./bin/ycsb load mongodb -threads 100 -P workloads/2000w
Output result description

[OVERALL], RunTime(ms), 37182 #Time taken to load data (MS) [OVERALL], Throughput(ops/sec), 13447.367005540314 #Throughput of load operations (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 # Total number of insert operations performed [INSERT], AverageLatency(us), 4658.931652 # Average delay per insert operation (microseconds) [INSERT], MinLatency(us), 831 # Minimum delay (microseconds) for all insert operations [INSERT], MaxLatency(us), 1784831 # Maximum delay (microseconds) for all insert operations [INSERT], 95thPercentileLatency(us), 9711 # 95% of insert operations are delayed within 9 ms [INSERT], 99thPercentileLatency(us), 17903 # 99% of insert operation delay is within 17 ms [INSERT], Return=OK, 500000

3. Pressure measurement

By adjusting the ratio of read and update in the pressure test file, the mixed operation of read-only and read-write is simulated

./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
5, Index observation

1. Server indicators, mainly observe the utilization and delay of CPU, memory and disk IO. You can view the real-time situation through top and iostat tools
2. MongoDB can view the real-time situation through mongostat tool

Output description of mongostat

Inserts: inserts per second query: queries per second update: number of updates per second delete: number of deletes per second Getmore: number of getmore executions per second command: the number of commands per second, more than the above integrated insert, find, update, delete, and other commands are also counted Dirty:WiredTiger storage engine dirty data as a percentage of cache Used: percentage of engines using cache in wiredtiger storage engine flushs: the number of times per second fsync is executed to write data to the hard disk. vsize: virtual memory usage in MB res: physical memory usage in MB qrw: length of client waiting to read, length in queue arw: the length of the queue waiting to be written by the client netIn and netOut: network traffic, in byte s conn: number of current connections Time: time stamp 6, Test results

Read more:

Performance test of mongodb with ycsb

5 February 2020, 06:55 | Views: 4875

Add new comment

For adding a comment, please log in
or create account

0 comments