rds for mysql的监控指标_mysql(RDS)常用性能指标监控
Mysql
1.1.1監控指標說明
主要針對SQL耗時、吞吐量(QPS TPS)命中率 鎖等待等指標進行監控。
本來運維工具產品有以下參數：(global status里面的狀態量)
TPS/QPS
連接數
每秒SQL執行次數
全表掃描數
InnoDB緩沖池命中率
InnoDB緩沖池使用率/臟塊率
InnoDB邏輯讀
排序記錄數
InnoDB鎖等待次數
InnoDB臟頁數量
InnoDB讀寫量
InnoDB buffer pool讀寫次數
InnoDB日志文件寫次數
打開文件/表數量
慢SQL
MyISAM讀寫次數
MyISAM key Buffer 讀/寫/利用率(%)
MySQL執行語句時在硬盤上自動創建的臨時表的數量
指標
解釋
TPS
是Transactions Per Second的縮寫，也就是事務數/秒。它是軟件測試結果的測量單位。一個事務是指一個客戶機向服務器發送請求然后服務器做出反應的過程。客戶機在發送請求時開始計時，收到服務器響應后結束計時，以此來計算使用的時間和完成的事務個數。
QPS
是Queries Per Second的縮寫，意思是每秒查詢率，是一臺服務器每秒能夠相應的查詢次數，是對一個特定的查詢服務器在規定時間內所處理流量多少的衡量標準。
連接數
當前總連接數The number of connection attempts (successful or not) to the MySQL server. Connections
每秒SQL執行次數
insert delete update select語句 ROWDML：InnoDB每秒鐘操作數據行數的統計，根據操作的不同，分為平均每秒向日志文件的物理寫次數、平均每秒從InnoDB表“刪除/更新/讀取/插入”的行數。
全表掃描數
平均每秒全表掃描次數 show global status like “handler_read%”
InnoDB緩沖池命中率
InnoDB buffer pool hit 不低于95%
InnoDB緩沖池使用率/臟塊率
InnoDB緩沖池的讀命中率、利用率以及緩沖池臟塊的百分率(InnoDB緩沖池)
InnoDB物理讀
innodb_buffer_pool_reads: 平均每秒從物理磁盤讀取頁的次數
InnoDB邏輯讀
innodb_buffer_pool_read_requests: 平均每秒從innodb緩沖池的讀次數
排序記錄數
Sort_rows
InnoDB鎖等待次數
Innodb_row_lock_current_waits
InnoDB臟頁數量
innodb_buffer_pool_pages_dirty
InnoDB讀寫量
InnoDB每秒鐘的讀取和寫入次數。/innodb_data_read innodb_data_written
InnoDB buffer pool讀寫次數
innodb_buffer_pool_read_requests/ innodb_buffer_pool_write_requests
InnoDB日志文件寫次數
InnoDB日志：InnoDB的日志寫入情況/ Innodb_log_writes
打開文件/表數量
Innodb_num_open_files/Com_show_open_tables
慢SQL
Slow_queries
MyISAM讀寫次數
MyISAM平均每秒的讀寫次數。 key_read_requests/ key_write_requests
MyISAM key Buffer 讀/寫/利用率(%)
MyISAM平均每秒的Key Buffer使用狀況。Key_usage_ratio =Key_blocks_used/(Key_blocks_used+Key_blocks_unused)*100 —- Key_read_hit_ratio=(1-Key_reads/Key_read_requests)*100 — Key_write_hit_ratio =(1-Key_writes/Key_write_requests)*100
MySQL執行語句時在硬盤上自動創建的臨時表的數量
執行語句時在硬盤上自動創建的臨時表的數量(臨時表)Created_tmp_disk_tables
IOPS
RDS實例的IOPS(每秒IO請求次數)
系統吞吐量要素：
一個系統的吞吐量(承壓能力)與request對CPU的消耗、外部接口、IO等等緊密關聯。單個request 對CPU消耗越高，外部系統接口、IO速度越慢，系統吞吐能力越低，反之越高。
系統吞吐量幾個重要參數：QPS(TPS)、并發數、響應時間
QPS(TPS)：(Query Per Second)每秒鐘request/事務 數量
并發數： 系統同時處理的request/事務數
響應時間： 一般取平均響應時間
(很多人經常會把并發數和TPS理解混淆)
理解了上面三個要素的意義之后，就能推算出它們之間的關系：
QPS(TPS)= 并發數/平均響應時間 或者 并發數 = QPS*平均響應時間
TPS/QPS區別及理解：
1、TPS即每秒處理事務數，包括：”用戶請求服務器”、”服務器自己的內部處理”、”服務器返回給用戶”，這三個過程，每秒能夠完成N個這三個過程，TPS也就是3；
2、QPS基本類似于TPS，但是不同的是，對于一個頁面的一次訪問，形成一個TPS；但一次頁面請求，可能產生多次對服務器的請求，服務器對這些請求，就可計入QPS之中。
3、一般的，評價系統性能均以每秒鐘完成的技術交易的數量來衡量。系統整體處理能力取決于處理能力最低模塊的TPS值。
4、QPS對應fetches/sec，即每秒的響應請求數，也即是最大吞吐能力。
MySQL RDS磁盤占用包括日志文件(binlog文件、錯誤日志等)，數據文件(數據、索引文件)，和一些其他文件(ibdata，logfile_0,臨時文件等)
造成 MySQL 實例空間使用率過高，主要有如下四種原因：
Binlog 文件占用高。
數據文件占用高。
臨時文件占用高。
系統文件占用高。
對應解決方法：
1、定期刪除binlog，假如當前dml造成大量的binlog，可以通過RDS控制臺即使清理binlog
2、通過truncate或者drop及時清除不需要的表
3、終止對應的回話
4、ibdata中undo占用高可以進行undo分離，或者進行數據轉移；增加redo log file的大小和組數
磁盤空間、磁盤空間詳情：
這段時間的數據是一條直線，空間狀態都很穩定，沒有性能問題。
MySQL RDS磁盤占用包括日志文件(binlog文件、錯誤日志等)，數據文件(數據、索引文件)，和一些其他文件(ibdata，logfile_0,臨時文件等)
造成 MySQL 實例空間使用率過高，主要有如下四種原因：
Binlog 文件占用高。
數據文件占用高。
臨時文件占用高。
系統文件占用高。
對應解決方法：
1、定期刪除binlog，假如當前dml造成大量的binlog，可以通過RDS控制臺即使清理binlog
2、通過truncate或者drop及時清除不需要的表
3、終止對應的回話
4、ibdata中undo占用高可以進行undo分離，或者進行數據轉移；增加redo log file的大小和組數
MySQL內存使用率：
基本上是一條直線，沒有變化。因為MySQL有innodb_buffer_pool，大約為物理內存的50%-80%，內存使用率高一些，相對的性能也會提高
cpu/mem的使用率：
現在cpu的使用率在30%左右，不算高。內存的使用率基本平穩在30%左右，正常
CPU的使用率高的原因：
系統執行應用提交查詢(包括數據修改操作)時需要大量的邏 輯讀，(邏輯 IO，執行查詢所需訪問的表的數據行數)，需要消耗大量的 CPU 資源以維護從存儲系統讀取到內存中的數據一致性。造成邏輯讀高的原因，很可能是異常SQL，掃描的數據行數過多導致。
物理內存：
直線保持基本無變化，物理內存就是實際的內存條的內存大小
連接數：show processlist
連接數是指用戶能夠創建多少個連接，也就是MySQL show processlist命令輸出結果中運行著的線程個數。
當前總連接數： show processlist結果中的總線程個數
當前活躍連接數：show processlist結果中的活躍線程數(Command列狀態為sleep的不計入在內)
當前連接數在1500左右，后來增高至6000左右。但是活躍連接數一直在個位數，說明現在的空閑連接數過多。總連接數超過參考值2000。出現嚴重問題。
數據庫的連接一般是使用長連接，可能是應用側的連接池初始連接數設置過高，應用啟動后建立多個到RDS的空閑連接
解決方法：
1、長連接建議啟用連接池的復用連接功能。
2、對于交互式連接和非交互式連接，建議修改相應的wait_timeout和interactive_timeout參數。(空閑時間超過指定的時間后，RDS的連接會主動關閉)。通過DT，RDS控制臺，性能優化，參數設置中修改。
3、kill當前的空閑會話。
網絡流量：
Bytes_received/s：平均每秒的輸入流量，單位byte/s
Bytes_sent/s：平均每秒的輸出流量，單位byte/s
IOPS：
每秒讀寫的次數。現在是比較小的。在0-0.2之間。
如果IOPS比較高的話，有可能是以下原因：
1、實例內存滿足不了緩存數據或排序等需要，導致產生大量的物理 IO。
2、查詢執行效率低，掃描過多數據行。
解決方法：
1、查詢是否有慢SQL，優化慢SQL，可以參考杜康的實例卡慢診斷的優化建議，或者登錄DMS，通過診斷報告、優化來進行SQL優化
2、終止查詢語句
3、通過show processlist，或者DMS控制臺、杜康等來kill查詢回話id
QPS/TPS：
TPS= Com_insert/s + Com_update/s + Com_delete/s
QPS=Com_select/s + Com_insert/s + Com_update/s + Com_delete/s
官方文檔入口com
QPS比較高，在90000左右，最高到達110000 。每秒的事務數在10000以上。正常，業務量比較高
原因分析：
QPS比較高，每秒SQL的語句執行次數高，業務量上來，處于業務的高峰期，用戶連接數增加，訪問量增加。
如果QPS比較高，邏輯讀不高，慢SQL也不是系統的瓶頸，QPS和cpu使用率的變化曲線吻合，這時候優化的余地就不高了，可以從實例規格、應用架構方面進行考慮。
如果QPS不高，查詢執行效率低、執行時需要掃描大量表中數據、優化余地大，并且出現慢查詢問題，QPS和CPU的變化曲線不吻合
如果QPS比較高，并且邏輯讀也比較高，CPU的使用率增加，這時候可以優化優化相應的慢SQL，添加主實例的只讀實例來緩解壓力。
COMDML：
Com_select/s：平均每秒select語句執行次數
Com_insert/s：平均每秒insert語句執行次數
Com_update/s：平均每秒update語句執行次數
Com_delete/s：平均每秒delete語句執行次數
ROWDML：
innodb_rows_deleted: 平均每秒從innodb表刪除的行數
innodb_rows_inserted: 平均每秒從innodb表插入的行數
innodb_rows_read: 平均每秒從innodb表讀取的行數
innodb_rows_updated: 平均每秒從innodb表更新的行數
Innodb緩沖池：
緩沖池(innodb buffer pool)簡單來說就是一塊內存區域。緩沖池中緩存的數據頁類型有：索引頁、數據頁、undo頁、插入緩沖、自適應哈希索引、InnoDB存儲的鎖信息、數據字典信息等。不能簡單認為，緩沖池只是緩存索引頁和數據頁，它們只是占緩沖池很大的一部分而已。
在數據庫中進行讀取頁的操作，首先將從磁盤讀到的頁存放在緩沖池中，下一次再讀相同的頁時，首先判斷該頁是否在緩沖池中。若在，稱該頁在緩沖池中被命中，直接讀取該頁。否則，讀取磁盤中的頁。
innodb_buffer_pool_reads: 平均每秒從物理磁盤讀取頁的次數
innodb_buffer_pool_read_requests: 平均每秒從innodb緩沖池的讀次數
innodb_buffer_pool_write_requests: 平均每秒向innodb緩沖池的寫次數
innodb_buffer_pool_pages_dirty: 平均每秒innodb緩存池中臟頁的數目
innodb_buffer_pool_pages_flushed: 平均每秒innodb緩存池中刷新頁請求的數目
緩沖池的讀命中率
innodb_buffer_read_hit_ratio = ( 1 – innodb_buffer_pool_reads/innodb_buffer_pool_read_requests) * 100
緩沖池的利用率
innodb_buffer_usage = ( 1 – innodb_buffer_pool_pages_free / innodb_buffer_pool_pages_total) * 100
緩沖池的臟塊的百分率
innodb_buffer_pool_pages_dirty / innodb_buffer_pool_pages_total
Innodb讀寫量：
平均每秒讀取的數據量：innodb_data_read
平均每秒寫入的數據量：innodb_data_written
Innodb讀寫次數：
平均每秒Innodb從文件中讀取的次數：innodb_data_reads
平均每秒Innodb從文件中寫入的次數：innodb_data_writes
Innodb日志：
平均每秒向日志文件的物理寫次數：innodb_log_writes
平均每秒日志寫請求次數：innodb_log_write_requests
平均每秒向日志文件完成fsync()寫數量：innodb_os_log_fsyncs
臨時表：
Created_tmp_disk_tables：MySQL執行語句時在磁盤上自動創建的臨時表的數量
在某些情況下，MySQL服務器會自動創建內部臨時表。用explain查看select語句的執行計劃，如果extra列顯示“using temporary”,即使用了內部臨時表。一般情況下，MySQL會先創建內存臨時表，內存臨時表超過配置指定的值后，MySQL會將內存臨時表導出到磁盤臨時表。
使用臨時表一般都意味著性能比較低，特別是使用磁盤臨時表，性能更慢，因此我們在實際應用中應該盡量避免臨時表的使用。常見的方法有：
1)創建索引：在ORDER BY或者GROUP BY的列上創建索引；
2)分拆很長的列：一般情況下，TEXT、BLOB，大于512字節的字符串，基本上都是為了顯示信息，而不會用于查詢條件， 因此表設計的時候，應該將這些列獨立到另外一張表。
如果表的設計已經確定，修改比較困難，那么也可以通過優化SQL語句來減少臨時表的大小，以提升SQL執行效率。
MyISAM Key Buffer：
為了最小化磁盤I/O，MyISAM將最頻繁訪問的索引塊(Index block)都放在內存中，這樣的內存緩沖區我們稱之為Key Cache，它的大小可以通過參數key_buffer_size來控制。在MyISAM的索引文件中，連續的單元組成一個Block，Index block的大小等于該BTree索引節點的大小。Key Cache就是以Block為單位的。
當MySQL請求(讀或寫)MyISAM索引文件中某個Index Block時，首先會看Key Cache隊列中是否已經緩存了對應block。
如果有，就直接在Key Cache隊列中進行讀寫了，不再需要請求磁盤。如果是寫請求，那么Key Cache中的對應Block就會被標記為Dirty(和磁盤不一致)。在MyISAM在Key Cache成功請求(讀寫)某個Block后，會將該Block放到Key Cache隊列的頭部。
如果Key Cache中沒有待請求(讀或寫)的Block，MyISAM會向磁盤請求對應的Block，并將其放到Key Cache的隊列頭部。隊列如果滿了，會將隊列尾部的Block刪除，該Block如果是Dirty的，會將其Flush到磁盤上。我們看到MyISAM維護了一個LRU(Least Recently Used)的Key Cache隊列。隊列中的Dirty Block會在Block被踢出隊列時Flush到磁盤上。
MyISAM平均每秒key buffer利用率
Key_usage_ratio =Key_blocks_used/(Key_blocks_used+Key_blocks_unused)*100
MyISAM平均每秒key buffer讀命中率
Key_read_hit_ratio=(1-Key_reads/Key_read_requests)*100
MyISAM平均每秒key buffer寫命中率
Key_write_hit_ratio =(1-Key_writes/Key_write_requests)*100
MyISAM讀寫次數：
key_read_requests: MyISAM平均每秒鐘從緩沖池中的讀取次數
Key_write_requests: MyISAM平均每秒鐘從緩沖池中的寫入次數
key_reads : MyISAM平均每秒鐘從硬盤上讀取的次數
key_writes : MyISAM平均每秒鐘從硬盤上寫入的次數
線程狀態：
線程數跟連接數是對應的。此時也是連接的總線程數遠大于活躍的線程數。
備庫延遲：
目前主備延遲(slave-lag)為0.
主備延遲產生的原因：
1 主庫產生非常大的binlog
a) 主庫上執行大量的dml語句
b) 主庫上執行大事務
c) 主庫上沒有主鍵的全表掃描
2 主庫上執行ddl語句，時間過長
3 備庫上對myisam表長時間查詢，阻塞主庫的binlog同步語句
4 備庫實例的規格配置低，磁盤IO比較低
查看方法:
1 首先查看備庫的IOPS是否存在瓶頸
2 備庫show processlist查看是否存在大事務
3 主庫的寫入壓力是否過高，dml語句是否過多
4 只讀節點執行 show slave status \G，判斷是否有 Waiting for table metadata lock；同時在主庫排查下是否有DDL 操作
5 只讀節點執行 show slave status \G，判斷是否有 Waiting for table level lock; 同時通過 show full processlist; 同時在主庫檢查下是否有長時間對 MyISAM 引擎表的查詢
慢SQL：
慢SQL數量的變化曲線跟CPU的使用率的變化曲線吻合，在CPU使用率高的時候，慢SQL也跟著增加。可以通過杜康對產生的慢SQL進行優化。
全表掃描次數：
handeler_read%
隨著業務量的增加，全表掃描的次數也隨之增加。Sql要盡量避免全表掃描
主實例問題與建議：
QPS升高，業務量高的情況下，產生一些慢查詢SQL，并且空閑連接數太多
連接數：連接數嚴重超過參考值，并且有過多的空閑線程。首先檢查應用是否使用連接池，如果使用連接池，檢查連接池的配置是否合理
優化慢SQL
root@itpux 12:14: [(none)]> show global status like "%innodb%read%"\G
*************************** 1. row ***************************
Variable_name: Innodb_buffer_pool_read_ahead_rnd
Value: 0
*************************** 2. row ***************************
Variable_name: Innodb_buffer_pool_read_ahead
Value: 0
*************************** 3. row ***************************
Variable_name: Innodb_buffer_pool_read_ahead_evicted
Value: 0
*************************** 4. row ***************************
Variable_name: Innodb_buffer_pool_read_requests
Value: 1356
*************************** 5. row ***************************
Variable_name: Innodb_buffer_pool_reads
Value: 240
*************************** 6. row ***************************
Variable_name: Innodb_data_pending_reads
Value: 0
*************************** 7. row ***************************
Variable_name: Innodb_data_read
Value: 4002304
*************************** 8. row ***************************
Variable_name: Innodb_data_reads
Value: 271
*************************** 9. row ***************************
Variable_name: Innodb_pages_read
Value: 239
*************************** 10. row ***************************
Variable_name: Innodb_rows_read
Value: 8
10 rows in set (0.00 sec)
參數
說明
Innodb_buffer_pool_read_ahead
預讀次數
Innodb_buffer_pool_read_ahead_evicted
預讀的頁，但沒有被讀取就從緩沖池中被替換的頁的數量，一般用來判斷預讀的效率
Innodb_buffer_pool_read_requests
從緩存池中讀取頁的次數
Innodb_buffer_pool_reads
從物理磁盤讀取頁的次數
Innodb_data_read
總共讀入的字節數
Innodb_data_reads
發起讀取請求的次數，每次讀取可能需要讀取多個頁
緩沖池命中率:
= Innodb_buffer_pool_reads/(Innodb_buffer_pool_reads+Innodb_buffer_pool_read_ahead+Innodb_buffer_pool_read_requests)
參考鏈接
總結
以上是生活随笔為你收集整理的rds for mysql的监控指标_mysql(RDS)常用性能指标监控的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Opencv visual studio
- 下一篇： docker $PWD路径_Docker