MySQL監控模板說明-Percona MySQL Monitoring Template for Cacti

標籤：

http://blog.chinaunix.net/uid-16844903-id-3535535.htmlhttps://www.percona.com/doc/percona-monitoring-plugins/1.1/zabbix/index.html

 

• InnoDB Adaptive Hash Index
• InnoDB Buffer Pool Activity
• InnoDB Buffer Pool
• InnoDB Checkpoint Age
• InnoDB Current Lock Waits
• InnoDB I/O
• InnoDB I/O Pending
• InnoDB Insert Buffer
• InnoDB Insert Buffer Usage
• InnoDB Internal Hash Memory Usage
• InnoDB Lock Structures
• InnoDB Log
• InnoDB Memory Allocation
• InnoDB Row Lock Time
• InnoDB Row Lock Waits
• InnoDB Row Operations
• InnoDB Semaphores Wait Time
• InnoDB Semaphores Waits
• InnoDB Semaphores
• InnoDB Tables In Use
• InnoDB Transactions Active/Locked
• InnoDB Transactions
• MyISAM Indexs
• MyISAM Key Cache
• MySQL Binary/Relay Logs
• MySQL Command Counts
• MySQL Connections
• MySQL Files and Tables
• MySQL Handler
• MySQL Network Traffic
• MySQL Processlist
• MySQL Query Cache
• MySQL Query Cache Memory
• MySQL Query Response Time (Microseconds)
• MySQL Query Time Histogram(Count)
• MySQL Replication
• MySQL Select Types
• MySQL Sorts
• MySQL Table Locks
• MySQL Temporary Objects
• MySQL Threads
• MySQL Transaction Handler

InnoDB Adaptive HashIndex

顯示了“自適應雜湊索引”的使用方式,雜湊索引只能用來搜尋等值的查詢.
# Hash table size 17700827, node heap has 35112 buffer(s)
# 3577.42 hash searches/s, 507.49 non-hash searches/s

1. Hash Index Cells Total
   自適應雜湊表的槽數=innodb_buffer_pool_size/256
2. Hash Index Cells Used
   用到自適應雜湊表的查詢個數

InnoDB Buffer PoolActivity

顯示Innodb緩衝池的內部活動,頁的建立,讀取,寫入.如果有突然的增加或者減少,需要檢查應用

1. Pages Created
2. Pages Read
3. Pages Written

InnoDB Buffer Pool

1. Pool Size
   InnoDB緩衝池的頁數量,每頁大小16K
2. Database Pages
   資料頁大小
3. Free Pages
   空閑頁大小
4. Modified Pages
   "髒"資料頁.如果髒資料頁太多,則需要檢查磁碟IO狀態.

InnoDB Checkpoint Age

1. Uncheckpointed Bytes
   顯示了未寫入磁碟的資料量.如果該值的大小接近innodb_log_file_size * n 的總大小,則需要增加innodb_log_file_size的值,但是要注意,如果發生宕機,則需要更長的回複時間.(從redolog恢複)

InnoDB Current LockWaits

1. InnoDB Lock Wait Secs
   顯示每秒處於鎖等待的innodb事務總數.如果有一個非常大的值,應該檢查LOCK WAIT transactions,請看下面的模板

InnoDB I/O

1. File Reads
   顯示每秒檔案的讀次數
2. File Writes
   顯示每秒檔案的寫次數
3. Log Writes
   寫日誌的次數
4. File Fsyncs
   調用fsync()函數的次數.與innodb_flush_log_at_trx_commit值的設定有關.

InnoDB I/O Pending

顯示了InnoDB掛起的同步或非同步IO操作.如果擱置動作太多,則需要更大的RAM,更大的緩衝池,更快的磁碟.

1. Pending Aio Log Ios
2. Pending Aio Sync Ios
3. Pending Buf Pool Flushes
4. Pending Chkp Writes
5. Pending Ibuf Aio Reads
6. Pending Log Flushe
7. Pending Log Writes
8. Pending Normal Aio Reads
9. Pending Normal Aio Writes

InnoDB Insert Buffer

插入緩衝,並不是緩衝的一部分,而是物理頁,對於非叢集索引的插入或更新操作,不是每一次直接插入索引頁.而是先判斷插入的非叢集索引頁是否在緩衝池中.如果在,則直接插入,如果不再,則先放入一個插入緩衝區中.然後再以一定的頻率執行插入緩衝和非叢集索引頁子節點的合併作業.
使用條件:非叢集索引,非唯一

1. Ibuf Inserts
   插入的記錄數
2. Ibuf Merged
   合并的頁的數量
3. Ibuf Merges
   合并的次數

如果merges/merged的值等於3/1,則代表插入緩衝對於非叢集索引頁的IO請求大約降低了3倍

InnoDB Insert BufferUsage

1. Ibuf Cell Count
   分段大小
2. Ibuf Used Cells
   插入緩衝區的大小
3. Ibuf Free Cells
   "自由列表"的長度

InnoDB Internal HashMemory Usage

顯示了InnoDB內部各種雜湊結構(不可人工幹預),佔用的記憶體大小.

1. Adaptive Hash Memory
   自適應雜湊索引佔用的記憶體大小
2. Page Hash Memory
3. Dictionary Cache Memory
4. File System Memory
5. Lock System Memory
6. Recovery System Memory
7. Thread Hash Memory

InnoDB Lock Structures

1. InnoDB Lock Structs
   該圖形顯示了在innodb內部有多少鎖結構(不是死結).這大致與當前事務鎖住的行數有關係.可以用來判斷是否存在鎖爭用.
   對於數量多少算好或者算壞,沒有硬性的規定.實際情況下,大量的事務在等待鎖,很明顯,該值越小越好.
   這個資料來源是SHOW ENGINE INNODB STATUS;

# 23 lock struct(s), heap size 3024, undo log entries 27

# LOCK WAIT 12 lock struct(s), heap size 3024, undo log entries 5

# LOCK WAIT 2 lock struct(s), heap size 368

InnoDB Log

相關變數:innodb_log_buffer_size

1. InnoDB Log Buffer Size
2. Log Bytes Written
   Log sequence number
   當前日誌的位置
3. Log Bytes Flushed
   Log flushed up to
   日誌已經重新整理的位置
4. Unflushed Log
   是log_bytes_written與log_bytes_flushed的差值,表示日誌緩衝區裡還有多少資料沒被重新整理到記錄檔裡.
   如果這個差值超過了innodb_log_buffer_size設定的30%,則需要考慮是否加大該參數值.

InnoDB MemoryAllocation

# Total memory allocated8824815616; in additional pool allocated 0

1. Total Mem Alloc
   InnoDB申請的總記憶體量,單位位元組
2. Additional Pool Alloc
   分配給額外記憶體的總量,單位位元組

InnoDB Row Lock Time

1. InnoDB Row Lock Time
   該模板讀取的Innodb_row_lock_time狀態變數,表示InnoDB引擎在每次申請資料行鎖定時等待的總時間(以毫秒為單位).

InnoDB Row Lock Waits

1. InnoDB Row Lock Waits
   讀取的Innodb_row_lock_waits狀態變數,表示InnoDB經過這麼長時間才獲得一個行鎖.(毫秒)

InnoDB Row Operations

# Number of rows inserted50678311, updated 66425915, deleted 20605903, read 454561562
大致能表現InnoDB內部的操作

1. Row Read
2. Row Deleted
3. Row Updated
4. Row Inserted

InnoDB Semaphores WaitTime

1. InnoDB Sem Wait Time Ms
   顯示當前正在等待互斥量的InnoDB線程的等待時間的總耗時(毫秒).
   分析:
   正常情況下,InnoDB Semaphores Wait Time和 InnoDB Semaphores Waits應該是空的.除非伺服器運行著高並發的工作負載,它促使InnoDB採取讓作業系統等待的措施.資訊位於SHOW ENGINE INNODB STATUS的SEMAPHORES片段.
   相關php指令碼代碼部分如下:

            elseif (strpos($line, ‘seconds the semaphore:‘) > 0) {

            # --Thread 907205 has waited at handler/ha_innodb.cc line 7156 for 1.00 seconds the semaphore:

            increment($results, ‘innodb_sem_waits‘, 1);

            increment($results, ‘innodb_sem_wait_time_ms‘, to_int($row[9]) * 1000);

            }

其中innodb_sem_waits的值是多少,表示有多少線程在等待,而innodb_sem_wait_time_ms表示所有線程等待的時間,預設單位是秒,在指令碼中乘以1000,所以監控圖中的單位是毫秒.

• 應對這個問題
  InnoDB採取多階段等待策略.首先,嘗試對鎖進行迴圈等待.如果經過了一個預設的迴圈等待周期(innodb_sync_spin_loops = 30,當前設定檔預設為30次)之後還沒有成功,就會退到更昂貴更複雜的等待陣列裡,如果並發量太大的話,則導致系統負載突增.
  迴圈等待的成本相對比較低,但是需要不停地檢查一個資源是否被鎖定,消耗CPU周期,也就是說,當另外一條線程能處理事情時,迴圈等待也會獨佔處理器.
  迴圈等待的替換方案就是讓作業系統做環境切換(等待陣列),每秒鐘幾千次的切換會引發大量的系統開銷.
• 解決辦法
  根據具體的應用,調整參數;或者最佳化應用,減少並發.

InnoDB SemaphoresWaits

1. InnoDB Sem Waits
   顯示當前正在等待互斥量的InnoDB線程的數量.

InnoDB Semaphores

顯示innodb內部的訊號活動狀態.
包括Mutex spin waits,RW-shared spins,RW-excl spins等各種訊號量的數量總和.

1. Spin Rounds
   InnoDB內部預設的互斥量訊號數量
2. Spin Waits
   InnoDB內部對鎖進行迴圈等待的數量(與innodb_sync_spin_loops參數有關)
3. Os Wait系統等待
   事務退到作業系統的等待陣列的數量
   在高並發的情況,會發現這個值有尖峰狀,不穩定.映像主要顯示了,不合理的設計情況下,不同的連線類型之間的行鎖或互斥鎖的爭用.

InnoDB Tables In Use

# mysql tables in use 2,locked 2

1. InnoDB Tables In Use
   所有事務用到的表的數量
2. InnoDB Locked Tables
   所有事務鎖定的表的數量

InnoDB TransactionsActive/Locked

該圖顯示了InnoDB事務的狀態數量.

1. Active Transactions
   正在執行的事務數量
2. Locked Transactions
   鎖住的事務數量
3. Current Transactions
   當前的事務數量(包括not started,ACTIVE,...等各種狀態)
   not started # 事務已經提交到磁碟
   ACTIVE # 正在執行的事務
4. Read Views(待更新)
   read views open inside InnoDB

InnoDB Transactions

顯示了InnoDB事務相關的資訊

1. InnoDB Transactions
   InnoDB內部的事務總數.由以下數值計算出:
   Trx id counter 89F56195 # 當前事務ID,每建立一個新事務就會累加
   Purge done for trx‘s n:o < 89F5609C undo n:o < 0 # InnoDB清除舊版本MVCC時所用的事務ID.這個ID之前的老版本資料已經清除.
   該數值就是由當前事務ID減去清除舊資料的事務ID再由十六進位轉成十進位的值.(參考ss_get_mysql_stats.php指令碼902行)
2. History List
   記錄的長度.位於InnoDB資料檔案的撤銷空間裡的未清除事務的數目.當一個事務執行了更新並提交後,這個數字就會累加,當清除進程移除一箇舊版本資料時,它就會遞減.

MyISAM Indexs

顯示了在MyISAM索引上的讀寫情況

1. Key Reads Requests
   從金鑰快取讀出索引塊的讀操作的次數
2. Key Reads
   從磁碟讀出索引塊的讀操作次數
3. Key Write Requests
   向金鑰快取寫一個索引塊的請求的個數
4. Key Writes
   把索引塊寫入磁碟的寫操作的次數

MyISAM Key Cache

1. Key Buffer Size
   金鑰快取大小
2. Key Buf Bytes Used
   同Key_blocks_used變數
   金鑰快取裡已經被使用的緩衝塊的個數
3. Key Buf Bytes Unused
   同Key_blocks_unused
   金鑰快取裡尚未被使用過的緩衝塊的個數

MySQL Binary/RelayLogs

1. Binlog Cache Use
   儲存在二進位日誌緩衝裡的事務的個數
2. Binlog Cache Disk Use
   超過binlog_cache_size設定的緩衝大小,使用磁碟臨時檔案的事務的個數
3. Binlog Log Space
   二進位日誌的大小
4. Relay Log Space
   中繼日誌的大小

如果Binlog Cache Disk Use/Binlog Cache Use的值較大,那麼應該嘗試增加binlog_cache_size的大小.但是,也不要期望改善過多,如果寫臨時檔案的數量從每秒1個減少到每分鐘一個,這已經證明最佳化的足夠好了.沒必要耗費大量的記憶體,來處理binlog_cache_size中的事務.

MySQL Command Counts

命令計數器,顯示了MySQL(在過去1秒內)執行各種命令的次數

1. Questions
   記錄了伺服器收到的查詢和命令的總數.(Com_*變數的總數不一定相等.)
2. Com Select
3. Com Delete
4. Com Insert
5. Com Update
6. Com Replace
7. Com Load
8. Com Delete Multi
9. Com Insert Select
10. Com Update Multi
11. Com Replace Select

MySQL Connections

1. Max Connections
   允許同時保持在開啟狀態的客戶串連的最大個數
2. Max Used Connections
   此前曾同時開啟處於開啟狀態的串連的最大個數
3. Aborted Clients
   因用戶端沒有正確地關閉而被丟棄的串連的個數
4. Aborted Connects
   試圖串連MySQL伺服器但沒有成功的次數
5. Threads Connectd
   現在正處於開啟狀態的串連的個數
6. Connections
   試圖串連MySQL伺服器的嘗試次數

MySQL Files and Tables

1. Table Cache
2. Open Tables
   當前處於開啟狀態的資料表的個數.不包括TEMPORARY
3. Open Files
   當前處於開啟狀態的檔案的個數,如果與open_files_limit接近,則應該加大open_files_limit的值.
4. Opened Tables
   MySQL伺服器已開啟的資料表總數(包括顯式定義的暫存資料表).如果這個值很高,應該謹慎考慮,是否加大資料表緩衝(table_open_cache).

MySQL Handler

1. Handler_writer 向資料表裡插入一個資料行的請求的個數
2. Handler_update 對資料表裡的一個資料行進行修改的請求的個數
3. Handler_delete 從資料表刪除一個資料行的請求的個數
4. Handler_read_first 讀取索引中第一個索引項目的請求的個數
5. Handler_read_key 根據一個索引值而讀取一個資料行的請求的個數
6. Handler_read_next 按索引順序讀取下一個資料行的請求的個數
7. Handler_read_prev 按索引逆序讀取前一個資料行的請求的個數
8. Handler_read_rnd 根據某個資料行的位置而讀取該資料行的請求的個數
9. Handler_read_rnd_next 讀取下一個資料行的請求的個數.如果這個數字很高,就說明有很多語句需要通過全表掃描才能完成或有很多查詢沒有使用適當的索引

MySQL Network Traffic

1. Bytes Send
   發送位元組數
2. Bytes Received
   收到位元組數

MySQL Processlist

http://dev.mysql.com/doc/refman/5.5/en/general-thread-states.html

1. State Closing Tables
   The thread is flushing the changed table data to disk and closing the used tables. This should be a fast operation. If not, verify that you do not have a full disk and that the disk is not in very heavy use.
2. State Copying To Tmp Table
   The server is copying to a temporary table in memory
3. State End
   This occurs at the end but before the cleanup of ALTER TABLE, CREATE VIEW, DELETE, INSERT, SELECT, or UPDATE statements
4. State Freeing Items
   The thread has executed a command. Some freeing of items done during this state involves the query cache. This state is usually followed by cleaning up
5. State Init
   This occurs before the initialization of ALTER TABLE, DELETE, INSERT, SELECT, or UPDATE statements. Actions taken by the server in this state include flushing the binary log, the InnoDB log, and some query cache cleanup operations.
   For the end state, the following operations could be happening:
   Removing query cache entries after data in a table is changed
   Writing an event to the binary log
   Freeing memory buffers, including for blobs
6. State Locked
   The query is locked by another query.
   As of MySQL 5.5.3, this state was removed because it was equivalent to the Table lock state and no longer appears in SHOW PROCESSLIST output.
7. State Login
   login
   The initial state for a connection thread until the client has been authenticated successfully.
8. State Preparing
   This state occurs during query optimization.
9. State Reading From Net
   The server is reading a packet from the network.
10. State Sengding Data
    The thread is reading and processing rows for a SELECT statement, and sending data to the client. Because operations occurring during this this state tend to perform large amounts of disk access (reads), it is often the longest-running state over the lifetime of a given query.
11. State Sorting Result
    For a SELECT statement, this is similar to Creating sort index, but for nontemporary tables
12. State Statistics
    The server is calculating statistics to develop a query execution plan. If a thread is in this state for a long time, the server is probably disk-bound performing other work.
13. State Updating
    The thread is searching for rows to update and is updating them
14. State Writing To Net
    The server is writing a packet to the network.
15. State None
    什麼都沒有的,空的,注意不是NULL狀態
16. State Other
    其他

MySQL Query Cache MySQL Query CacheMemory MySQL Query ResponseTime (Microseconds)

Percona文檔

MySQL Query TimeHistogram(Count)

Percona文檔

MySQL Replication

預設用SHOW SLAVE STATUS命令擷取各狀態值

1. Slave Running
   從伺服器的I/O線程和SQL線程是否在運行
2. Slave Stopped
3. Slave Lag
   複寫延遲
4. Slave Open Tmp Tables
   從伺服器中的SQL線程曾經開啟的臨時檔案的個數
5. Slave Retried Transactions
   從伺服器中的SQL線程重新嘗試執行一個事務的次數

MySQL Select Types

1. Select Full Join
   沒有使用索引而完成的多表聯結操作的次數.這種情況是效能殺手,最好去最佳化sql.
2. Select Full Range Join
   利用一個輔助性的參照表(reference table)上的區間搜尋(range search)操作而完成的多資料表聯結操作的次數.
   該值表示使用了範圍查詢聯結表的次數.
3. Select Range
   利用第一個資料表上的某個區間而完成的多資料表聯結操作的次數.
4. Select Range Check
   該變數記錄了在聯結時,對每一行資料重新檢查索引的查詢計劃的數量,它的開銷很大.
   如果該值較高或正在增加,說明一些查詢沒有找到好索引.
5. Select Scan
   通過對第一個資料表進行全表掃描而完成的多資料表聯結操作的次數.

MySQL Sorts

1. Sort Rows
   對多少行排序
2. Sort Range
   利用一個區間進行的排序操作的次數
3. Sort Merge Passes
   查詢導致了檔案排序的次數.可以最佳化sql或者適當增加sort_buffer_size變數
4. Sort Scan
   利用一次全表掃作而完成的排序操作的次數

MySQL Table Locks

1. Table Locks Immediate
   無需等待就能夠立刻得到滿足的資料表鎖定請求的個數
2. Table Locks Waited
   顯示了有多少表被鎖住了並且導致伺服器級的鎖等待(儲存引擎級的鎖,如InnoDB行級鎖,不會使該變數增加).
   如果這個值比較高或者正在增加,那麼表明存在嚴重的並發瓶頸.
3. Slow Queries
   慢查詢的次數(執行時間超過long_query_time值)

MySQL TemporaryObjects

1. Created_tmp_tables
   MySQL伺服器在對SQL查詢語句進行處理時在記憶體裡建立的臨時資料表的個數.
   如果該值太高,唯一的解決辦法是:最佳化查詢語句.
2. Created_tmp_disk_tables
   MySQL伺服器在對SQL查詢語句進行處理時在磁碟上建立的臨時資料表的個數,如果這個值比較高,可能的原因:
   a.查詢在選擇BLOB或者TEXT列的時候建立了暫存資料表
   b.tmp_table_size和max_heap_table_size的值也許太小
3. Created_tmp_files
   MySQL伺服器所建立的臨時檔案的個數

MySQL Threads

1. Thread Cache Size
   線程緩衝所能容納的線程的最大個數.斷開的mysql串連會放到這個緩衝裡,建立立的串連就會重複使用它們而不建立新的線程.
   如果緩衝中有自由的線程,MySQL就能很快的響應串連請求,不必為每個串連都建立新的線程.每個在緩衝中的線程通常消耗256KB記憶體.
2. Thread Created
   為處理串連建立的線程總數

MySQLTransaction Handler

1. Handler Commit
   提交一個事務的請求的個數
2. Handler Rollback
   復原一個事務的請求的個數
3. Handler Savepoint
   建立一個事務儲存點的請求的個數
4. Handler Savepoint Rollback
   復原到一個事務儲存點的請求的個數.

 

參考:
http://www.percona.com/doc/percona-monitoring-plugins/cacti/mysql-templates.html
http://www.mysqlperformanceblog.com/2006/07/17/show-innodb-status-walk-through/
以Percona提供的模板為例.其中資訊擷取命令如下(不包括pt-heartbeat).

SHOW /*!50002 GLOBAL */ STATUS;

SHOW VARIABLES;

SHOW SLAVE STATUS;

SHOW MASTER LOGS;

SHOW PROCESSLIST;

SHOW /*!50000 ENGINE*/ INNODB STATUS;

MySQL監控模板說明-Percona MySQL Monitoring Template for Cacti