知己知彼–對Aurora進行壓力測試
一、前言
Amazon Aurora 是一種為雲打造並與 MySQL 和 PostgreSQL 相容的關係資料庫,既具有高階商用資料庫的效能和可用性,又具有開源資料庫的簡單性和成本效益。相比起MYSQL, Aurora在只讀副本延遲,可擴充套件性,備份恢復速度以及儲存空間擴充套件等方面都有很大優勢,更有回溯,aurora serverless等實用的新功能,除了以上功能和管理方面的優點外,Aurora 的速度最高可以達到標準 MySQL 資料庫的五倍、標準 PostgreSQL 資料庫的三倍。
隨著寧夏區推出Aurora,中國區客戶終於可以體驗Aurora的獨特魅力了,在遷移資料庫之前,有些客戶也想進行效能比對測試,做到知己知彼。針對這種需求,這裡我將給大家介紹如何用sysbench對MYSQL RDS和Aurora進行測試,講解不同測試引數的含義,分析不同測試案例的結果,希望對大家今後測試資料庫的工作有所幫助。
二、環境準備
2.1 環境資訊
測試端
機型 | vCPU | 記憶體(GiB) | 磁碟 | 網路 |
4臺db.r4.8xlarge EC2 | 32 | 244 | 通用SSD 40G | 高 |
資料庫
資料庫 | DB instance class | vCPU | 記憶體(GiB) | 磁碟 | 網路 |
Aurora mysql5.6 RDS | db.r4.8xlarge | 32 | 244 | SSD | 高 |
mysql5.6 RDS | db.r4.8xlarge | 32 | 244 | IOPS 10000 SSD 40G | 高 |
2.2 安裝和配置sysbench
在四臺測試客戶端安裝sysbench
安裝Sysbench Version 0.5,執行以下步驟:
- 以root使用者安裝Bazaar/ automake/ Libtool:
yum -y install bzr
yum -y install automake
yum -y install libtool
2.以root使用者安裝 MySQL 客戶端程式 (Red Hat 用mysql‐devel, Debian/Ubuntu 用libmysqlclient‐dev ):
yum -y install mysql-devel
yum –y install mysql
下載Sysbench:
bzr branch lp:sysbench
- 編譯和安裝Sysbench:
cd sysbench
./autogen.sh
./configure
make
cd sysbench
2.3 開啟限制
在Sysbench客戶端執行 以下網路配置,告訴Linux kernel可以用所有的CPU cores 去處理 packets, 預設只可以用兩個, 並且減少cores 之間的context switching. 這兩個設定是為了用更少的Sysbench 客戶端達成吞吐目標.
sudo sh -c 'for x in /sys/class/net/eth0/queues/rx-*; do echo ffffffff > $x/rps_cpus; done'
sudo sh -c "echo 32768 > /proc/sys/net/core/rps_sock_flow_entries"
sudo sh -c "echo 4096 > /sys/class/net/eth0/queues/rx-0/rps_flow_cnt"
sudo sh -c "echo 4096 > /sys/class/net/eth0/queues/rx-1/rps_flow_cnt"
vim /etc/security/limits.conf
* soft nofile 65536
* hard nofile 65536
* soft nproc 65536
* hard nproc 65536
2.4 模擬資料注入
Aurora
首先通過sysbench客戶端在測試資料庫上生成測試表,這裡生成250個表,每個表有行數25000條,您也可以根據您的目標,調整表的數目和大小,請替換<>之中的各種連線資訊,再執行命令,同時拷貝的時候請注意格式,後面的命令注意事項相同,不再贅述
./sysbench --test=/home/ec2-user/sysbench/sysbench/tests/db/oltp.lua --mysql-host=<aurora server> --oltp-tables-count=250 --mysql-user=<aurora user> --mysql-password="<aurora password>" --mysql-port=3306 --oltp-table-size=25000 --mysql-db=<aurora db> --db-driver=mysql prepare
其輸出類似:
Mysql
同樣的,在mysql上生成相同的測試集
./sysbench --test=/home/ec2-user/sysbench/sysbench/tests/db/oltp.lua --mysql-host=<mysql server> --oltp-tables-count=250 --mysql-user=<mysql user> --mysql-password="<mysql password>" --mysql-port=3306 --oltp-table-size=25000 --mysql-db=<mysql db> --db-driver=mysql prepare
其輸出類似:
引數含義
–test=tests/db/oltp.lua 表示呼叫 tests/db/oltp.lua 指令碼進行 oltp 模式測試
–oltp_tables_count=250 表示會生成250 個測試表
–oltp-table-size=25000 表示每個測試表填充資料量為25000
–rand-init=on 表示每個測試表都是用隨機資料來填充的
載入測試資料時長視資料量而定,若過程比較久需要稍加耐心等待。
2.5 監控指令碼
Aurora
我們生成如下指令碼來監控資料庫,每秒一次輸出QPS/Commit/Rollback/TPS/Threads_con/ Threads_run的資訊,協助我們掌握資料庫每秒的負載變化
vi aurora_monitor.sh
#!/bin/bash
mysqladmin -h -u -p"" extended-status –i1 |awk 'BEGIN{local_switch=0;print "QPS Commit Rollback TPS Threads_con Threads_run \n------------------------------------------------------- "}
$2 ~ /Queries$/ {q=$4-lq;lq=$4;}
$2 ~ /Com_commit$/ {c=$4-lc;lc=$4;}
$2 ~ /Com_rollback$/ {r=$4-lr;lr=$4;}
$2 ~ /Threads_connected$/ {tc=$4;}
$2 ~ /Threads_running$/ {tr=$4;
if(local_switch==0)
{local_switch=1; count=0}
else {
if(count>10)
{count=0;print "------------------------------------------------------- \nQPS Commit Rollback TPS Threads_con Threads_run \n------------------------------------------------------- ";}
else{
count+=1;
printf "%-6d %-8d %-7d %-8d %-10d %d \n", q,c,r,c+r,tc,tr;
}
}
}'
Mysql
同樣地,為MYSQL生成類似的指令碼
vi mysql_monitor.sh
#!/bin/bash
mysqladmin -h <mysql server> -u <mysql user> -p"<mysql password>" extended-status –i1 |awk 'BEGIN{local_switch=0;print "QPS Commit Rollback TPS Threads_con Threads_run \n------------------------------------------------------- "}
$2 ~ /Queries$/ {q=$4-lq;lq=$4;}
$2 ~ /Com_commit$/ {c=$4-lc;lc=$4;}
$2 ~ /Com_rollback$/ {r=$4-lr;lr=$4;}
$2 ~ /Threads_connected$/ {tc=$4;}
$2 ~ /Threads_running$/ {tr=$4;
if(local_switch==0)
{local_switch=1; count=0}
else {
if(count>10)
{count=0;print "------------------------------------------------------- \nQPS Commit Rollback TPS Threads_con Threads_run \n------------------------------------------------------- ";}
else{
count+=1;
printf "%-6d %-8d %-7d %-8d %-10d %d \n", q,c,r,c+r,tc,tr;
}
}
}'
三、測試
3.1 只讀壓力測試
Aurora
在所有sysbench client同時執行命令模擬負載,每次持續5分鐘,同時使用監控指令碼監視資料庫的效能,從console檢視CPU,IO,網路等metrics。在這裡我們將通過修改num_threads引數連續測試4*100,4*250,4*500,4*750,4*1000,4*1250和4*1500多種併發連線的場景。
./sysbench --test=/home/ec2-user/sysbench/sysbench/tests/db/oltp.lua --mysql-host=<aurora server> --mysql-user=<aurora user> --mysql-password="<aurora password>" --mysql-port=3306 --mysql-db=<aurora db> --max-requests=0 --oltp-simple-ranges=0 --oltp-distxinct-ranges=0 --oltp-sum-ranges=0 --oltp-order-ranges=0 --max-time=300 --oltp-read-only=on --num-threads=1000 --report-interval=10 run>>aurora_r.log
引數說明
–num-threads=100 表示sysbench client發起 100個併發連線
–oltp-read-only=on表示是隻讀測試,off 表示不要進行只讀測試,也就是會採用讀寫混合模式測試,
–report-interval=10 表示每10秒輸出一次測試進度報告
–rand-type=uniform 表示隨機型別為固定模式,其他幾個可選隨機模式:uniform(固定),gaussian(高斯),special(特定的),pareto(帕累託),special表示存在熱點資料,uniform表示非熱點資料模式, 預設是special
–mysql-table-engine=xxx:表的儲存引擎型別,innodb、myisam這些都可以
–max-time=3600 表示最大執行時長為 3600秒
–max-requests=0 表示總請求數為 0,因為上面已經定義了總執行時長,所以總請求數可以設定為 0;也可以只設定總請求數,不設定最大執行時長
–percentile=99 表示設定取樣比例,預設是 95%,即丟棄1%的長請求,在剩餘的99%裡取最大值
即:模擬 對10個表併發OLTP測試,每個表1000萬行記錄,持續壓測時間為 1小時。
注意,針對不同的選項取值就會有不同的子選項。比如oltp-dist-type=special,就有比如oltp-dist-pct=1、oltp-dist-res=50兩個子選項,代表有50%的查詢落在1%的行(即熱點資料)上,另外50%均勻的(sample uniformly)落在另外99%的記錄行上。
再比如oltp-test-mode=nontrx時, 就可以有oltp-nontrx-mode,可選值有select(預設), update_key, update_nokey, insert, delete,代表非事務式模式下使用的測試sql型別。
從監控指令碼看
通過監控指令碼可以看到類似結果
從console看資料庫效能
我們可以關注資料庫例項的CPU利用率,連線數,IO和網路效能指標
Sysbench結果
在每個sysbench客戶端可以看到類似輸出:
- response time avg: 平均響應時間。(後面的95%的大小可以通過–percentile=98的方式去更改)
- transactions: 精確的說是這一項後面的TPS 。但如果使用了-oltp-skip-trx=on,這項事務數恆為0,需要用total number of events 去除以總時間,得到tps(其實還可以分為讀tps和寫tps)
- read/write requests: 用它除以總時間,得到吞吐量QPS
Mysql
同樣地,在所有sysbench client同時執行命令模擬負載,每次持續5分鐘,同時使用監控指令碼監視資料庫的效能,從console檢視CPU,IO,網路等metrics。在這裡我們將通過修改num_threads引數連續測試4*100,4*250,4*500,4*750,4*1000,4*1250和4*1500多種併發連線的場景。
./sysbench --test=/home/ec2-user/sysbench/sysbench/tests/db/oltp.lua --mysql-host=<mysql server> --oltp-tables-count=250 --mysql-user=<mysql user> --mysql-password="<mysql password>" --mysql-port=3306 --oltp-tablesize=25000 --mysql-db=<mysql db> --max-requests=0 --oltp-simple-ranges=0 --oltp-distxinct-ranges=0 --oltp-sum-ranges=0 --oltp-order-ranges=0 --max-time=300 --oltp-read-only=on --num-threads=1000 --report-interval=10 run >> mysql_r.log
從監控指令碼看
通過監控指令碼可以看到類似結果
從console看資料庫效能
我們可以關注資料庫例項的CPU利用率,連線數,IO和網路效能指標
Sysbench結果
在每個sysbench客戶端可以看到類似輸出:
3.2 讀/寫混合壓力測試
Aurora
在所有sysbench client同時執行命令模擬負載,每次持續5分鐘,同時使用監控指令碼監視資料庫的效能,從console檢視CPU,IO,網路等metrics。在這裡我們將通過修改num_threads引數連續測試4*100,4*250,4*500,4*750,4*1000,4*1250和4*1500多種併發連線的場景。
./sysbench --test=/home/ec2-user/sysbench/sysbench/tests/db/oltp.lua --mysql-host=<aurora server> --mysql-user=<aurora user> --mysql-password="<aurora password>" --mysql-port=3306 --mysql-db=<aurora db> --max-requests=0 --oltp-simple-ranges=0 --oltp-distxinct-ranges=0 --oltp-sum-ranges=0 --oltp-order-ranges=0 --max-time=300 --oltp-read-only=off --num-threads=1000 --oltp-tablesize=25000 --oltp-tables-count=250 --report-interval=10 run>>aurora_w.log
Mysql
在所有sysbench client同時執行命令模擬負載,每次持續5分鐘,同時使用監控指令碼監視資料庫的效能,從console檢視CPU,IO,網路等metrics。在這裡我們將通過修改num_threads引數連續測試4*100,4*250,4*500,4*750,4*1000,4*1250和4*1500多種併發連線的場景。
./sysbench --test=/home/ec2-user/sysbench/sysbench/tests/db/oltp.lua --mysql-host=<mysql server> --oltp-tables-count=250 --mysql-user=<mysql user> --mysql-password="<mysql password>" --mysql-port=3306 --oltp-tablesize=25000 --mysql-db=<mysql db> --max-requests=0 --oltp-simple-ranges=0 --oltp-distxinct-ranges=0 --oltp-sum-ranges=0 --oltp-order-ranges=0 --max-time=300 --oltp-read-only=off --num-threads=1000 --report-interval=10 run >> mysql_w.log
3.3 結果分析
只讀負載
在不同併發連線數下,Aurora和MYSQL只讀混合負載測試資料如下:
400併發 | 1000併發 | 2000併發 | 3000併發 | 4000併發 | 5000併發 | 6000併發 | |
QPS mysql | 112K | 108K | 95K | 88K | 44K | 17K | 8.9K |
QPS aurora | 440K | 680K | 776K | 748K | 726K | 683K | 659K |
CPU mysql | 98 | 99 | 99 | 99 | 90 | 57 | 39 |
CPU aurora | 90 | 96 | 97 | 98 | 98 | 98 | 98 |
Response time mysql | 39.27ms | 103.08ms | 230.70ms | 365.23ms | 974.83ms | 4106.50ms | 8076.35ms |
Response time aurora | 11.71ms | 19.12ms | 33.10ms | 51.32ms | 72.03ms | 93.36ms | 114.96ms |
讀/寫混合負載
在不同併發連線數下,Aurora和MYSQL讀/寫混合負載測試資料如下:
400併發 | 1000併發 | 2000併發 | 3000併發 | 4000併發 | 5000併發 | 6000併發 | |
QPS/TPS mysql | 84K | 88K | 76K | 56K | 29K | 28K | 16K |
QPS/TPS aurora | 160K | 188K | 184K | 172K | 152K | 140K | 128K |
CPU mysql | 75 | 81 | 90 | 69 | 73 | 81 | 87 |
CPU aurora | 77 | 92 | 97 | 97 | 98 | 98 | 98 |
Response time mysql | 68.94ms | 168.17ms | 384.80ms | 778.60ms | 2073.83ms | 2569.24ms | 5815.39ms |
Response time aurora | 38.89ms | 81.51ms | 163.37ms | 259.77ms | 391.70ms | 534.18ms | 638.33ms |
分析
通過以上測試資料,我們可以得出以下結論
- 對於所有效能比對測試來說,只有測試環境的資源、引數配置,測試流程完全相同,才有比較意義
- Aurora對比MYSQL,在同樣負載壓力,同樣資源配置下,無論只讀負載還是讀寫混合負載,其QPS/TPS以及平均響應時間都有明顯的優勢,而且這個優勢隨著併發連線的增大而增大,很多時候會超過5倍
- 一般來說,sysbench測試中,隨著併發數增大,目標資料庫系統資源被充分利用,QPS/TPS會提高,達到峰值後,資源開始爭用,隨著併發數繼續增大,QPS/TPS反而會下降,從測試來看,當併發數較大時,MYSQL的QPS/TPS會下降得很快,而Aurora的QPS/TPS下降得平穩得多
- 一般來說,sysbench測試中,隨著併發數增大平均響應時間會下降,同樣地,Aurora的相應時間增大比MYSQL平緩得多,這樣就意味著高併發時,Aurora可以為客戶提供更佳的服務
四、清除環境
Aurora
./sysbench --test=/home/ec2-user/sysbench/sysbench/tests/db/oltp.lua --mysql-host=<aurora server> --oltp-tables-count=250 --mysql-user=<aurora user> --mysql-password="<aurora password>" --mysql-port=3306 --oltp-table-size=25000 --mysql-db=<aurora db> --db-driver=mysql cleanup
Mysql
./sysbench --test=/home/ec2-user/sysbench/sysbench/tests/db/oltp.lua --mysql-host=<mysql server> --oltp-tables-count=250 --mysql-user=<mysql user> --mysql-password="<mysql password>" --mysql-port=3306 --oltp-table-size=25000 --mysql-db=<mysql db> --db-driver=mysql cleanup
參考資料
《Amazon Aurora: Design Considerations for High Throughput Cloud-Native Relational Databases》
《Amazon Aurora Performance Assessment》
總結
本文主要是為大家梳理用sysbench對Aurora和MYSQL進行效能測試的流程,啟發大家做資料庫效能測試的思路,當您按本文步驟進行測試的時候,隨著環境,測試步驟的不同,需要對命令引數進行微調,測試結果也會相應變化,但測試的思路以及測試結果變化的客觀規律卻是共通的。除了sysbench,我們還有其他的效能測試工具,譬如mysqlslap或tpcc-mysql,本篇限於篇幅,沒有介紹,在以後的blog中,我們再做介紹。
本篇作者
相關推薦
知己知彼–對Aurora進行壓力測試
一、前言 Amazon Aurora 是一種為雲打造並與 MySQL 和 PostgreSQL 相容的關係資料庫,既具有高階商用資料庫的效能和可用性,又具有開源資料庫的簡單性和成本效益。相比起MYSQL, Aurora在只讀副本延遲,可擴充套件性,備份恢復速度以及儲存空間擴充
【MySQL】【壓測】使用sysbench對MySQL進行壓力測試
usr with sleep library val repos then plot 停止 1.背景 ? 出自percona公司,是一款多線程系統壓測工具,可以根據影響數據庫服務器性能的各種因素來評估系統的性能。例如,可以用來測試文件IO,操作系統調度器,內存分配和傳輸
使用ab對網站進行壓力測試
進行 壓力 測試 oca tools ray local too install 1、安裝yum install httpd-tools 2、ab -kc 1000 -n 1000 http://localhost/ab.html 這個指令會使用1000個並發,進行連接
.net core 使用ConcurrentTest元件對方法進行壓力測試
工欲善其事,必先利其器!在編寫服務中首先要有一個好的測試工具,在dontecore下效能測試有BenchmarkDotNet,只需要簡單的配置一下就可以對方法的效能進行詳細的測試。但有時候需要對不同併發下看其處理效率和延時統計檢視,如HTTP服務對應著大量的測試工具如ab,bombardier等等。由於找不到
使用Jmeter工具對tomcat進行壓力測試(7)
本文主要使用jmeter工具對tomcat8進行壓力測試,並使用java visualVM進行壓測效能監控,通過監控資料調整tomcat引數 步入正題: 首先作業系統已優化完成,java版本為1.8以上,tomcat版本8.0.48,根據自己實際情況而定 使用tomcat預設引數進行壓測 #vi
linux下使用ab工具對伺服器進行壓力測試
ab 安裝 yum -y install httpd-tools (centos) 安裝完成後使用ab -v 檢視ab版本確認是否安裝成功 選項 選項 含義 -A auth-username:password 對伺服器提供BASIC認證信任。 使
使用Monkey對APP進行壓力測試
最近在對新開發的APP進行壓力測試,學習了Monkey。在這裡進行一下總結和記錄。 monkey是手機系統自帶的一個軟體,它存在於adb shell中,對使用者是不可見的,但是可以通過ADB(Android Debug Bridge)進入手機系統裡面,它主要是生成使用者
使用JMeter對Tomcat進行壓力測試與Tomcat效能調優
一、準備工作。 1、安裝JDK1.6或1.6版本以後的,並配置環境變數。 2、在Apache的官網下載最新的Jmeter, http://jmeter.apache.org/download_jmeter.cgi,截止目前為止,最新的Jmeter是
用mysqlslap對MySQL進行壓力測試
MySQL5.1地的確提供了好多有力的工具來幫助我們DBA進行資料庫管理。現在看一下這個壓力測試工具mysqlslap.關於他的選項手冊上以及--help介紹的很詳細。我解釋一下一些常用的選項。這裡要注意的幾個選項:--concurrency代表併發數量,多個可以用逗號隔開
YCSB 對MongoDB 進行壓力測試
執行環境:CentOS7.5 +YCSB 0.16版本+MongoDB 3.6.6 注意: 參考YCSB 0.15.0的版本釋出說明資訊, Tested in previous releases, unchanged in this release中MongoDB支援的版
基於TSUNG對MQTT進行壓力測試-測試結果
yum install -y ncurses-devel openssl-devel unixODBC-devel wxWidgets-devel wxGTK3-docs mesa-libGL-devel
使用ApacheBench(ab)對URL進行壓力測試(HTTP直壓)
ApacheBench(ab)安裝 ubuntu 安裝 apt-get install apache2-utils // 可單獨安裝,與apache2無捆綁關係。若無法安裝,請更新源後重試。 其它系統安裝,自行搜尋。 ApacheBench
基於TSUNG對MQTT進行壓力測試-基礎概念溫習
一、TCP報頭部中的SYN、FIN、ACK:ACK : TCP協議規定,只有ACK=1時有效,也規定連線建立後所有傳送的報文的ACK必須為1。SYN(SYNchronization) : 在連線建立時用來同步序號。當SYN=1而ACK=0時,表明這是一個連線請求報文。對方若同意建立連線,則應在響應報文中使SY
使用ab對web服務進行壓力測試
服務器 時間限制 pac 0.10 字節 -s 重復 最小 傳輸速率 ab 需要先安裝httpd -A auth-username:密碼 向服務器提供BASIC認證憑證。用戶名和密碼由一個單獨分隔 -c並發 一次執行的多個請求數。默認是一次一個請求。 -C cookie-
利用ab壓力工具對服務器進行壓力測試
因此 win request 過大 .exe http cond don bin 假如我們需要對http://letv.com進行壓力測試,指定請求總數為100,並發用戶數為10,我們可以以下面的方式進行測試 $ ab -n 100 -c 10 http://letv
使用ab對Tomcat8.5進行壓力測試
背景 一直不是很清楚tomcat能力大約是個什麼水平,到底算不算web伺服器中的高手,今天決定試試這傢伙的深淺。 恰好了解到apache自帶的ab(apache benchmark)工具可以進行簡單的壓力測試,所以就用它來試試。 流程 先配置tomcat8.5,
使用 WRK 壓力測試工具對 ASP.NET Core 的介面進行壓力測試
0. 簡要介紹 WRK 是一款輕量且易用的 HTTP 壓力測試工具,通過該工具我們可以方便地對我們所開發的 WebAPI 專案進行壓力測試,並且針對測試的情況返回結果。 PS:Wrk 並不能針對測試的結果生成動態的圖表,如果有這種需要,可以嘗試使用另一款工具 Vegeta。該專案使用的 Golang 進行編
linux實訓第三天--linux使用ab命令來對web網站進行壓力測試/DDOS攻擊
ab -n 100 -c 10 http://127.0.0.1/index.html -n requests Number of requests to perform 要執行的請求數量 -c concurrenc
使用COSBench工具對ceph s3介面進行壓力測試
標籤:des class style log com http it si 使用 一、COSBench安裝COSBench是Intel團隊基於java開發,對雲端儲存的測試工具,全稱是Cloud object Storage Benc
sysbench對mysql資料庫進行壓力測試
轉載請註明出處:https://blog.csdn.net/qq_30186661/article/details/80224301一、安裝sysbench平臺:ubuntucurl -s https://packagecloud.io/install/repositorie