mysql監控

  innodb data written / read

計算每秒questions

數據庫性能變化趨勢判斷服務器資源是否足夠

 

 

select benchmark(100000000, 'call mysp()'); #第一個函數調用多少次，第二個函數執行的sql。 注意響應時間

select benchmark(100000000, ‘select 1+1');  #判斷服務器性能，做基准測試。然后監控系統監控每秒指標，響應時長。

mysqladmin ext | grep -i trx #判斷事物id,percona版本才有，官方版本查看information_schema查看trx信息&innodb status

select * from QUERY_RESPONSE_TIME;  percona查看sql區間響應耗時

 

idle = 100% - %user - %sys - %iowait

iowait越高說明當前IO性能差，io負載高。

真正可用的內存有：free + cached + buffer

IOwait高可能是buffer poll太小導致讀盤多，或者沒索引走全表掃描。

常用工具：top、free、ps、df、sysstat、（sar、mpstat、iostat）\dstat\omstaat、netstat、oprofile、systemtap、perf

iotop

sysstat（sar、mpstat、iostat）\ dstat \ omstaat \ iotop

 

select case when sum(DATA_LENGTH)+sum(INDEX_LENGTH) is NULL then 0 else sum(DATA_LENGTH)+sum(INDEX_LENGTH) end as innodb_tabsize from information_schema.TABLES where TABLE_SCHEMA not in ('information_schema','mysql','performance_schema','test') and ENGINE = 'InnoDB';#統計is庫

 

實際可用內存為buffer/cache + free

釋放 swap：swapoff/swapon  #負載高容易hang

 

sar -u #CPU利用率

sar -d #塊設備，IO利用率,rd_sec/s wr_sec/s （讀寫扇區）每個扇區是512字節 ，可計算相應多少字節，可用iotop定位。await,io等待。 svctm本次io響應時間，  util使用率ssd不用太擔心，機械是串行寫入，ssd可並行寫入。

sar -r #磁盤利用率 %memused 查看是否平穩。

 

 

vmstat: 

vmstat -S m 1 #只是內存用兆方式顯示，1秒刷新。

r：在運行隊列中等待未執行的進程數 。
b：在等待io的進程數 ，不能被中斷的進程。

表示正在發生的swap

bi = block in to mem read from disk，io讀
bo = block out from mem write to disk，io寫

si = block in to swap in from disk，swap讀（單位是block 4kb）
so = block out from swap out to disk，swap寫（單位是block 4kb）

swpd列：總的swap

us = %user

sy = %sys

id = %idle #cpu空閑率

wa = %iowait

st = 虛擬機使用的cpu資源

cpu比較高基本是沒有索引引起的

 

iostat -d -x 1

r/s+w/s=iops

await：總的服務時間包括隊列時間。通常大於svctm

svctm:服務時間

util:util比較高說明當前io占比高。如果是磁盤陣列，因為可以並行，所以不太靠譜。ssd並行IO更好，每秒一兩百m，也不太靠譜。

 io不高而svctm,util比較高，說明服務器性能比較差。

avgqu-sz是平均請求隊列的長度

iops \ iowait \ util  #查看io瓶頸

計算機械盤iops 10000轉/60s=167(iops),多盤可以並行*盤數*Linux（4kb）

配置最大連接數，如果每個線程配置的cache比較大，內存溢出導致服務不可用。

 

mysql監控：

1. 每秒活躍DML（sql）數，/事物數/請求數/當前並發連接數/平均響應時長

2.鎖：表鎖，行鎖，鎖等待，死鎖。#最大行鎖時間，發生次數。

3，內存：buffer/cache命中率、內存如果等待釋放（如果內存等待釋放，mysqld可能需要增加buffer）。

4.事物：事物ID增長，有沒有持續穩定增長。unpurged 未清除的歷史事物積壓有多少。

5.慢查詢：平均耗時，平均次數

 

mysqladmin ext|grep -i 'Innodb_buffer_pool_wait_free'
                 

3個等待事件狀態，如果有發生需要關注：

1.Innodb_buffer_pool_wait_free  #innodb等待更多的buffer、page釋放，比較嚴重，說明當前buffer使用很厲害，沒有空閑。

2.innodb_log_waits #redo log 需要切換，沒有足夠空間。

3.table_locks_waited #請求表鎖的時候沒有立刻獲得表鎖，需要等待。

慢日志，看哪種sql發生最多，優先解決，其次解決耗時最長。

 

查看mysql狀態：

1，show 【full processlist】  #sending data,超過1秒請求數據量太大。

2，show 【global】 status like"handler%"  #讀隨機下一行，發生全表掃描或者全表join， 產生臨時表甚至臨時文件，發生多少次。

 

鎖監控：

表鎖

1.table_locks_immediate #立刻獲得的表鎖

2.table_locks_waited  #發生的請求需要等待

 

行鎖

1.innodb_row_lock_current_waits  #當前等待的行鎖數量

2.innodb_row_lock_time  #從實例啟動到當前，請求行鎖總耗時

3.innodb_row_lock_time_avg  #請求行鎖平均耗時

4.innodb_row_lock_time_max   #請求行鎖最久耗時（ms，可以對此事物加監控）

5.innodb_row_lock_waits  #行鎖發生次數

 

show processlist；

copying to tmp table #沒有索引（條件鏈沒有合適索引）

 

 

 總耗時，是否發生全表掃描，全表join，掃描的數據頁有12252

select count（*） 通常優先訪問輔助索引。

dstat\orzdba.pl   #mysql兩個不錯的監控工具

 

監控事物ID的增長 

這兩種表示沒有利用索引發生的讀

 

show global status；或者mysqladmin extended-status 縮寫、簡寫模式 mysqladmin ext

Aborted_clients  #由於客戶端沒有正確關閉連接導致客戶端終止而中斷的連接數。

Binlog_cache_disk_use  #無法使用內存保存binlog，需要使用基於磁盤的臨時文件次數。

binlog-cache-size  #將內存中的binlog寫到磁盤之前緩沖，提升寫入。如果太小導致比較大的事物無法將binlog內存，會用到磁盤。

Binlog_stmt_cache_disk_use &Binlog_stmt_cache_use #非事務性的用到磁盤文件（以myisam為主）

Created_tmp_disk_tables  #用到磁盤表

Binlog_cache_use  #使用臨時二進制日志緩存的事務數量，越多越好。

Connections #試圖連接到(不管是否成功)MySQL 服務器的連接數

Created_tmp_tables  #服務器執行語句時自動創建的內存中的臨時表的數量。如果 Created_tmp_disk_tables 較大,你可能要增加 tmp_table_size 值使臨時表基於內 存而不基於硬盤。

 

Created_tmp_disk_tables #服務器執行語句時在硬盤上自動創建的臨時表的數量。

tmp-table-size & max-heap-table-size #允許在內存里面最大的臨時內存是多少。

Created_tmp_disk_tables/(Created_tmp_disk_tables+Created_tmp_tables)*100%  #高於10%的話,就需要注意，適當 調高 tmp_table_size ，但是不能設置太大,因為它是每個 session 都會分配的, 可能會導致 OOM

 

Handler_commit#內部交語句數。

Handler_read_first #索引中第一條記錄被讀的次數。如果較高,它表明服務器正執行大量全索引掃 ; 例如,SELECT id FROM table,假定 id 有索引。

Handler_read_key #根據索引讀取某一行的請求次數，例如：select … where id = 1024;

Handler_read_last  #order by倒序讀總次數

Handler_read_next #按照索引順序讀下一行的請求數。如果你用范圍約束或如果執行索引掃描來查詢索引列，該值增加。 例如：select * from t where id = 1024 order by id limit 5; 先read-key 然后4條是read-next

Handler_read_prev，例如倒序：select id from t where id = 1024 order by id DESC limit 5;往回讀增加4

 

Handler_read_rnd #根據固定位置讀一行的請求數。如果你正執行大量查詢並需要對結果進行排序該值較高，說明可能使用了大量需要MySQL掃描整個表的查詢或沒有正確使用索引。例如select * from t limit 1000,1; 數據庫層面邏輯讀

 

Handler_read_rnd_next #在數據文件中讀下一行的請求數。如果你正進行大量的表掃描，該值會較高。通常說明你的表索引不正確或寫入的查詢沒有利用索引。例如根據非索引列排序后再讀取多少條記錄（甚至發生基於磁盤的臨時文件進行排序，先從數據庫取到數據，再進行二次排序 select * from t order by non_key_col limit 100;

 

Handler_read_rnd&Handler_read_rnd_next沒有利用索引應該重點關注下。

如果懷疑某些SQL效率比較差：

flush status;#先將session 值清空

select xxx； #show status like 'handler_read%';

 

 

Innodb_buffer_pool_pages_data  #在innodb buffer_pool中有多少個page用來緩存熱點數據的，與InnoDB status的Database pages是同一個意思

Innodb_buffer_pool_pages_dirty #表示用來緩存臟頁的page 數量

Innodb_buffer_pool_pages_free  #沒有用到的page數量

Innodb_buffer_pool_pages_total #page總數

Innodb_buffer_pool_read_requests #InnoDB已經完成的邏輯讀請求數。（Innodb所有讀操作的次數）

Innodb_buffer_pool_reads# 讀操作不能從Innodb buffer pool中完成讀取，需要從磁盤中讀取數據的次數。

Innodb_buffer_pool_wait_free #innodb buffer pool不夠用了等待把熱點數據或臟頁的buffer pool釋放次數，該參數大於0比較嚴重

Innodb_buffer_pool_write_requests #一共發生的寫請求次數

Innodb_data_writes  #實際物理寫次數

Innodb_data_read #從啟動到現在已經讀取的數據數量（字節）

Innodb_data_written #從啟動到現在已經寫入的數據量（字節）。

Innodb_log_waits #我們必須等待的時間，因為redo日志緩沖區太小，我們在繼續前必須先等待對它清空。

所有帶wait關鍵字都需要引起注意。

 

鎖：

Innodb_row_lock_current_waits #當前等待行鎖的行數。

Innodb_row_lock_time #從啟動到現在，行鎖定花費的總時間，單位毫秒。

Innodb_row_lock_time_avg #行鎖定的平均時間，單位毫秒。

Innodb_row_lock_time_max #行鎖定等待的最長時間，單位毫秒（一般建議設置為10秒）。這個值太大的話，可以考慮調低 innodb_lock_wait_timeout 值

 

Open_tables #當前正在用打開表空間文件，打開表的數量。如果當前1個表被並發10個線程訪問，每個線程打開次數都算1.

Open_table_definitions #被緩存的.frm文件數量，一般該值就是表的數量。

table-open-cache，table-definition-cache #如果表cache不夠大，需要關閉歷史表才可以打開新表。

flush tables #把正在打開的表關閉，這種操作會產生mdl鎖，盡量不要操作。備份時的FTWRL也是將所有表重新打開一遍

Opened_tables #歷史總共打開次數，如果Opened_tables較大，table_open_cache 值可能太小。

no-auto-rehash #如果表太多，客戶端沒使用該參數，每次打開都會統計表信息。

Queries #已經發送給服務器的查詢的個數，通常指DML

Questions #發送到服務器的請求次數。

 

和性能有關：

Select_full_join #沒有使用索引的聯接的數量。如果該值不為0,你應仔細檢查表的索引，可以查慢日志。

Select_scan  #對一個表進行完全掃描的聯接的數量

Slow_queries #查詢時間超過 long_query_time秒的查詢的個數

Sort_merge_passes #對一個結果進行排序時，又不能基於索引排序，需要多次 遞進排序才能得到最終結果。排序算法已經執行的合並的數量，每次合並都要加1。如果這個變量值較大，應考慮增加sort_buffer_size系統變量的值，盡量不要產生基於磁盤的臨時文件。

default_tmp_storage_engine  #5.6開始可以強制定義產生的臨時表使用引擎

 

Table_locks_immediate #立即獲得的表的鎖的次數，絕大多數指的是myisam引擎，innodb 發生dml時做DDL操作也會發生表鎖。

Table_locks_waited #不能立即獲得的表的鎖的次數。如果該值較高，並且有性能問題，你應首先優化查詢，然后拆分表

 

Threads_cached #當前緩存了多少個線程

Threads_connected #當前正在打開的連接的數量。

Threads_created  #創建用來處理連接的線程數。如果Threads_created較大，你可能要增加thread_cache_size值。緩存訪問率的計算方法Threads_created/Connections。

Threads_running #激活的（非睡眠狀態）線程數

 

  innodb_thread_concurrency #innodb內部可以允許並發的數量，設置為邏輯CPU數量即可。