社區投稿 | 如何正確理解 RT 並監控 MySQL 的響應時間

作者:楊奇龍
網名“北在南方”,7年DBA老兵,目前任職於杭州有贊科技DBA,主要負責數據庫架構設計和運維平臺開發工作,擅長數據庫性能調優、故障診斷。

一、前言

響應時間(response time 簡稱 RT)是從系統接收請求開始到返回響應之間的時間跨度,是一項極其重要的性能指標。它可以從側面反映系統的整體吞吐量,也是業務請求(比如 sql 請求)的性能好壞的判斷依據。

舉個例子 A 要從杭州坐飛機到北京機場,經歷如下:

從公司到蕭山機場 40min
機場安檢,候機,登機 40min
飛機飛行  耗時 100min
飛機落地,打的到望京  耗時40min
RT= 40 + 40 + 100 + 40 =220min

其中真正的'執行'時間就飛機飛行的時間(100min+40+40),其他安檢、候機、堵車的都是等待時間。

RT = 等待時間 + 執行時間

假如到機場的過程中發生堵車,或者空中管制導致候機時間延長,整體的 RT 也會變長,但是飛機飛行時間是相對一定的。從技術的角度來看 SQL 的請求路徑

app <---->(網絡建立連接,data 傳輸)<----> proxy <---->(網絡建立連接,data 傳輸)<----> mysql(執行)

因爲網絡問題丟包,重傳等導致數據傳輸時間增加,進而導致總體的 RT 時間增加 ,還有常見的案例 app 服務器 cpu 飆高導致程序執行的速度變慢,JAVA 程序 GC 等因素也會導致 RT 升高。所以說 SQL 慢,其實 RT 就會高。但是反過來 RT 高,不一定是 SQL 慢的原因。如果是開發同學遇到監控尤其是 trace 系統發現某個接口慢了,並不一定是 SQL 慢。

重點:不要把 trace 系統中的監控 rt 直接當做 db 的執行時間

參考案例 strace 案例

二、如何監控

前面說了 RT 的定義以及它所代表意義。接下來我們看看如何監控數據庫的 RT ,現有的方式主要有兩種。

2.1 tcprstat

tcprstat 是 Percona 基於 libpcap 研發的工具,是通過測量 TCP 的 request 和 response 所需的時間間隔,適用於一問一答式協議類型的處理。通常用來監測 MySQL 響應時間,或者說是請求在服務器端的處理時間,其輸出結果包括了響應時間相關的統計值,用來診斷服務器端性能狀況。
舉個例子:
999
其輸出結果包括了時間戳,以及響應時間的最大值、均值、方差等信息,輸出信息可以通過 -f 參數進行定製,其中響應時間的單位爲微妙。其中對我們比較重要的是:

count:此間隔內處理完成的請求數量。
avg:此間隔內所有完成的請求,響應的平均時間。
95_avg:此間隔內,95% 的請求量的平均響應時間,單位微妙,該值較能體現 MySQL Server 的查詢平均響應時間。
如果我們只需要輸出 count, 平均時間,95_avg,99_avg 則可以用如下命令。
tcprstat -p 3312 -t 1 -n 0 -l ip_address -f '%Tt%nt%at%95at%99an'

1000
關於 -f 的參數解釋如下,讀者朋友可以根據需要來調整輸出
format

如果執行tcprstat遇到如下問題

# tcprstat -p 3312 -t 1 -n 5
pcap: SIOCGIFFLAGS: bonding_masters: No such device

可以通過指定本地 ip -l local_ip 來解決。

2.2 MySQL 插件

Percona Server 提供一個叫做響應時間區間的功能,將 sql 耗時在指定區間的請求次數和總共的執行時間記錄到表裏面。其中時間區間跨度由 query_response_time_range_base 控制。

常用的區間範圍爲:(0, 0.000001], (0.000001, 0.000010],(0.000010,0.000100],(0.000100,0.001000],(0.001000, 0.010000], (0.010000,0.100000],(0.100000,1.000000],(1,10] 。

從 MySQL 5.6 開始以插件形式安裝:

INSTALL PLUGIN QUERY_RESPONSE_TIME_AUDIT SONAME 'query_response_time.so';
INSTALL PLUGIN QUERY_RESPONSE_TIME SONAME 'query_response_time.so';
INSTALL PLUGIN QUERY_RESPONSE_TIME_READ SONAME 'query_response_time.so';
INSTALL PLUGIN QUERY_RESPONSE_TIME_WRITE SONAME 'query_response_time.so';

然後通過 show plugins 命令檢查插件是否安裝成功。

> SHOW PLUGINS;
......
| QUERY_RESPONSE_TIME         | ACTIVE   | INFORMATION SCHEMA | query_response_time.so | GPL     |
| QUERY_RESPONSE_TIME_AUDIT   | ACTIVE   | AUDIT              | query_response_time.so | GPL     |
| QUERY_RESPONSE_TIME_READ    | ACTIVE   | INFORMATION SCHEMA | query_response_time.so | GPL     |
| QUERY_RESPONSE_TIME_WRITE   | ACTIVE   | INFORMATION SCHEMA | query_response_time.so | GPL     |
+-----------------------------+----------+--------------------+------------------------+---------

安裝完成之後 在 INFORMATION_SCHEMA 生成三張表

QUERY_RESPONSE_TIME_WRITE 記錄所有寫請求的響應時間分佈
QUERY_RESPONSE_TIME_READ  記錄所有讀請求的響應時間分佈
QUERY_RESPONSE_TIME 可以認爲是所有請求的響應時間分佈。

查看 QUERY_RESPONSE_TIME 的內容
rt_table.png
查詢結果中 717 個 sql 請求耗時在 (0, 0.000001] 之間。47898 個 sql 請求的耗時在 (0.000001, 0.000010],總耗時 0.29 秒,其他以此類推。需要注意的是 count 和total是累計值,監控的時候需要取後值減前值除以採樣的時間間隔
如何開啓響應時間統計
在命令行中執行

SET GLOBAL query_response_time_stats = 1 ;

在 my.cnf 中

query_response_time_stats = 1

重置(將數據清零)三張表的統計值

SET GLOBAL query_response_time_flush='ON';

常用的 sql

INFORMATION_SCHEMA [RW][TEST:qa_single_0:3312] 11:50:44 
>SELECT c.count, c.time, (SELECT SUM(a.count) FROM INFORMATION_SCHEMA.QUERY_RESPONSE_TIME as a WHERE a.count != 0) as query_count, (SELECT COUNT(*)     FROM INFORMATION_SCHEMA.QUERY_RESPONSE_TIME as b WHERE b.count != 0) as not_zero_region_count, (SELECT COUNT(*)     FROM INFORMATION_SCHEMA.QUERY_RESPONSE_TIME) as region_count FROM INFORMATION_SCHEMA.QUERY_RESPONSE_TIME as c WHERE c.count > 0;
+-------+----------------+-------------+-----------------------+--------------+
| count | time           | query_count | not_zero_region_count | region_count |
+-------+----------------+-------------+-----------------------+--------------+
|     1 |       0.000001 |       71370 |                     7 |           14 |
|    86 |       0.000010 |       71370 |                     7 |           14 |
| 47375 |       0.000100 |       71370 |                     7 |           14 |
| 23404 |       0.001000 |       71370 |                     7 |           14 |
|   423 |       0.010000 |       71370 |                     7 |           14 |
|    79 |       0.100000 |       71370 |                     7 |           14 |
|     2 |       1.000000 |       71370 |                     7 |           14 |
+-------+----------------+-------------+-----------------------+--------------+
7 rows in set (0.00 sec)

通過監控腳本獲取響應時間的數據在 grafna 展示的結果如下:
rt_grafna.png
rt_avg.png
其他更詳細的介紹可以去查閱 Percona 的官方文檔。

三、小結

本文總結介紹 RT 的在技術體系中的含義,以及介紹兩種監控 MySQL 響應時間的方法。如果有其他更好的方式方法,歡迎讀者朋友一起討論。

參考文章

  1. https://www.percona.com/doc/p...
  2. https://jin-yang.github.io/po...
  3. https://www.percona.com/doc/p...
  4. https://www.aikaiyuan.com/546...
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章