MySQL性能指標TPS+QPS+IOPS壓測
前言
今天主要介紹MySQL數據庫,或者說所有數據庫的三個關鍵性能指標TPS\QPS\IOPS
1. 性能指標概覽
QPS(Queries Per Second)就是每秒的查詢數,對數據庫而言就是數據庫每秒執(zhí)行的 SQL 數(含 insert、select、update、delete 等)。
TPS(Transactions Per Second)就是每秒的事務數。TPS 對于數據庫而言就是數據庫每秒執(zhí)行的事務數,以 commit 成功次數為準。
IOPS 每秒磁盤進行的I/O操作次數
2. 指標計算方式
2.1 TPS
適用innodb Transactions Per Second(每秒傳輸的事物處理個數),即服務器每秒處理的事務數
一般的,評價系統性能均以每秒鐘完成的技術交易的數量來衡量。系統整體處理能力取決于處理能力最低模塊的TPS值
mysql> SHOW GLOBAL STATUS LIKE 'Com_commit'; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | Com_commit | 22402 | +---------------+-------+ 1 row in set (0.00 sec) mysql> SHOW GLOBAL STATUS LIKE 'Com_rollback'; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | Com_rollback | 0 | +---------------+-------+ 1 row in set (0.00 sec) mysql> SHOW GLOBAL STATUS LIKE 'Uptime' -> ; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | Uptime | 3319 | +---------------+-------+ 1 row in set (0.01 sec) TPS=(Com_commit + Com_rollback)/Uptime
2.2 QPS
同時適用與InnoDB和MyISAM 引擎 每秒查詢率QPS是對一個特定的查詢服務器在規(guī)定時間內所處理流量多少的衡量標準 對應fetches/sec,即每秒的響應請求數,也即是最大吞吐能力
2.3 IOPS
IOPS (Input/Output Per Second)即每秒的輸入輸出量(或讀寫次數),是衡量磁盤性能的主要指標之一。IOPS是指單位時間內系統能處理的I/O請求數量,一般以每秒處理的I/O請求數量為單位,I/O請求通常為讀或寫數據操作請求。隨機讀寫頻繁的應用,如OLTP(Online Transaction Processing),IOPS是關鍵衡量指標。另一個重要指標是數據吞吐量(Throughput),指單位時間內可以成功傳輸的數據數量。對于大量順序讀寫的應用,如VOD(Video On Demand),則更關注吞吐量指標。 IOPS可細分為如下幾個指標: Toatal IOPS,混合讀寫和順序隨機I/O負載情況下的磁盤IOPS,
這個與實際I/O情況最為相符,大多數應用關注此指標。
Random Read IOPS,100%隨機讀負載情況下的IOPS。
Random Write IOPS,100%隨機寫負載情況下的IOPS。
Sequential Read IOPS,100%順序負載讀情況下的IOPS。
Sequential Write IOPS,100%順序寫負載情況下的IOPS。
IOPS的測試benchmark工具主要有Iometer, IoZone, FIO等,可以綜合用于測試磁盤在不同情形下的IOPS。對于應用系統,需要首先確定數據的負載特征,然后選擇合理的IOPS指標進行測量和對比分析,據此選擇合適的存儲介質和軟件系統。
理論上可以計算出磁盤的最大IOPS,即IOPS = 1000 ms/ (Tseek + Troatation),忽略數據傳輸時間。假設磁盤平均物理尋道時間為3ms, 磁盤轉速為7200,10K,15K rpm,則磁盤IOPS理論最大值分別為, IOPS = 1000 / (3 + 60000/7200/2) = 140 IOPS = 1000 / (3 + 60000/10000/2) = 167 IOPS = 1000 / (3 + 60000/15000/2) = 200
3. mysqlslap
3.1 壓測
mysqlslap 是 MySQL 自帶的一個用于實現負載性能測試和壓力測試的工具。它可以模擬多個客戶端對數據庫進行施壓,并生成報告來了解數據庫的性能狀況。
mysqlslap 的運行過程主要分三步:
① 創(chuàng)建庫、表,導入數據用于測試。此過程由單線程完成。
② 開始進行壓力測試。該步驟可以使用多線程完成。
③ 清理測試數據。此過程由單線程完成。
[root@jeames ~]# mysqlslap --help
3.2 案例
mysqlslap -uroot -proot -h192.168.1.54 -P3306 \ --create-schema=mysqlslap --auto-generate-sql \ --auto-generate-sql-load-type=mixed \ --concurrency=100,200 --number-of-queries=1000 \ --iterations=10 --number-int-cols=7 \ --number-char-cols=13 --auto-generate-sql-add-autoincrement Benchmark #運行所有語句的平均時間,單位秒 Average number of seconds to run all queries: 0.018 seconds #運行所有語句的最小秒數 Minimum number of seconds to run all queries: 0.018 seconds #運行所有語句的最大秒數 Maximum number of seconds to run all queries: 0.018 seconds #客戶端數量 Number of clients running queries: 1 #每個客戶端運行查詢的平均數 Average number of queries per client: 0 該語句表示測試并發(fā)為 100 和 200 的情況,進行 1000 次訪問(該值一般這樣預估出來:并發(fā)客戶數×每客戶查詢次數)。這樣的測試方法迭代 10 次,最終顯示最大、 最小、平均值 其中:--debug-info,代表要額外輸出 CPU 以及內存的相關信息。如果報錯 Option 'debug-info' used, but is disabled 請取消 debug-info 參數 -number-int-cols=7 表示生成的表中必須有 7 個 int 類型的列 -number-char-cols=13 表示生成的表中必須有 13 個 char 類型的列 -concurrency 代表并發(fā)數量,多個可以用逗號隔開,concurrency=10,50,100, 并發(fā)連接線程數分別是 10、50、100 個并發(fā)。 --engines 代表要測試的引擎,可以有多個,用分隔符隔開。 --iterations 代表要運行這些測試多少次。 --auto-generate-sql 代表用系統自己生成的 SQL 腳本來測試。 --auto-generate-sql-load-type 代表要測試的是讀還是寫還是兩者混合的(read,write,update,mixed) --number-of-queries 代表總共要運行多少次查詢。每個客戶運行的查詢數量可以用查詢總數/并發(fā)數來計算。 --debug-info 代表要額外輸出 CPU 以及內存的相關信息。 --number-int-cols :創(chuàng)建測試表的 int 型字段數量 --auto-generate-sql-add-autoincrement : 代表對生成的表自動添加 auto_increment 列,從 5.1.18 版本開始 --number-char-cols 創(chuàng)建測試表的 char 型字段數量。 --create-schema 測試的 schema,MySQL 中 schema 也就是 database。 --query 使用自定義腳本執(zhí)行測試,例如可以調用自定義的一個存儲過程或者 sql 語句來執(zhí)行測試。 --only-print 查看語句做了什么。
到此這篇關于MySQL性能指標TPS+QPS+IOPS壓測的文章就介紹到這了,更多相關MySQL性能指標壓測內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家!
相關文章
mysql8.0.14.zip安裝時自動創(chuàng)建data文件夾失敗服務無法啟動
這篇文章主要介紹了mysql8.0.14.zip安裝時自動創(chuàng)建data文件夾失敗,導致服務無法啟動的解決方法,具有一定的參考價值,感興趣的小伙伴們可以參考一下2019-02-02