MySQL 性能監控4大指標——第二部分

【編者按】本文做者爲 John Matson，主要介紹 mysql 性能監控應該關注的4大指標。 第一部分介紹了前兩個指標：查詢吞吐量與查詢執行性能。本文將繼續介紹另兩個指標：MySQL 鏈接與緩衝池。文章系國內 ITOM 管理平臺 OneAPM 編譯呈現。

鏈接

檢查並設置鏈接限制

監控客戶端鏈接狀況至關重要，由於一旦可用鏈接耗盡，新的客戶端鏈接就會遭到拒絕。MySQL 默認的鏈接數限制爲 151，可經過下面的查詢加以驗證：

SHOW VARIABLES LIKE 'max_connections';
+-----------------+-------+
| Variable_name   | Value |
+-----------------+-------+
| max_connections | 151   |
+-----------------+-------+

MySQL 的文檔指出，健壯的服務器應該可以處理成百上千的鏈接數。

「常規狀況下，Linux 或 Solaris 應該可以支持500到1000個同時鏈接。若是可用的 RAM 較大，且每一個鏈接的工做量較低或目標響應時間較爲寬鬆，則最多可處理10000個鏈接。而 Windows 能處理的鏈接數通常不超過2048個，這是因爲該平臺上使用的 Posix 兼容層。」

鏈接數限制能夠在系統運行時進行調整：

SET GLOBAL max_connections = 200;

然而，此設置會在服務器重啓時恢復爲默認值。想要永久地改變鏈接數限制，能夠在 my.cnf 配置文件中添加以下配置（查看本文瞭解如何定位配置文件）：

max_connections = 200

監控鏈接使用率

MySQL 提供了 Threads_connected 指標以記錄鏈接的線程數——每一個鏈接對應一個線程。經過監控該指標與先前設置的鏈接限制，你能夠確保服務器擁有足夠的容量處理新的鏈接。MySQL 還提供了 Threads_running 指標，幫助你分隔在任意時間正在積極處理查詢的線程與那些雖然可用可是閒置的鏈接。

若是服務器真的達到 max_connections 限制，它就會開始拒絕新的鏈接。在這種狀況下，Connection_errors_max_connections 指標就會開始增長，同時，追蹤全部失敗鏈接嘗試的 Aborted_connects 指標也會開始增長。

MySQL 提供了許多有關鏈接錯誤的指標，幫助你調查鏈接問題。Connection_errors_internal 是個很值得關注的指標，由於該指標只會在錯誤源自服務器自己時增長。內部錯誤可能反映了內存不足情況，或者服務器沒法開啓新的線程。

應該設置告警的指標

• Threads_connected：當全部可用鏈接都被佔用時，若是一個客戶端試圖鏈接至 MySQL，後者會返回 「Too many connections(鏈接數過多)」錯誤，同時將 Connection_errors_max_connections 的值增長。爲了防止出現此類狀況，你應該監控可用鏈接的數量，並確保其值保持在 max_connections 限制之內。

• Aborted_connects：若是該計數器在不斷增加，意味着用戶嘗試鏈接到數據庫的努力全都失敗了。此時，應該藉助 Connection_errors_max_connections 與 Connection_errors_internal 之類細粒度高的指標調查該問題的根源。

緩衝池使用狀況

MySQL 默認的存儲引擎 InnoDB 使用了一片稱爲緩衝池的內存區域，用於緩存數據表與索引的數據。緩衝池指標屬於資源指標，而非工做指標，前者更多地用於調查（而非檢測）性能問題。若是數據庫性能開始下滑，而磁盤 I/O 在不斷攀升，擴大緩衝池每每能帶來性能回升。

檢查緩衝池的大小

默認設置下，緩衝池的大小一般相對較小，爲 128MiB。不過，MySQL 建議可將其擴大至專用數據庫服務器物理內存的80%大小。然而，MySQL 也指出了一些注意事項：InnoDB 的內存開銷可能提升超過緩衝池大小10%的內存佔用。而且，若是你耗盡了物理內存，系統會求助於分頁，致使數據庫性能嚴重受損。

緩衝池也能夠劃分爲不一樣的區域，稱爲實例。使用多個實例能夠提升大容量(多 GiB)緩衝池的併發性。

緩衝池大小調整操做是分塊進行的，緩衝池的大小必須爲塊的大小乘以實例的數目再乘以某個倍數。

innodb_buffer_pool_size = N * innodb_buffer_pool_chunk_size

• innodb_buffer_pool_instances

塊的默認大小爲 128 MiB，可是從 MySQL 5.7.5 開始能夠自行配置。以上兩個參數的值均可以經過以下方式進行檢查：

SHOW GLOBAL VARIABLES LIKE "innodb_buffer_pool_chunk_size";
SHOW GLOBAL VARIABLES LIKE "innodb_buffer_pool_instances";

若是 innodb_buffer_pool_chunk_size 查詢沒有返回結果，則表示在你使用的 MySQL 版本中此參數沒法更改，其值爲 128 MiB。

在服務器啓動時，你能夠這樣設置緩衝池的大小以及實例的數量：

$ mysqld --innodb_buffer_pool_size=8G --innodb_buffer_pool_instances=16

在 MySQL 5.7.5 版本，你能夠經過 SET 指令在系統運行時修改緩衝池的大小，並精確到字節數。例如，假設有兩個緩衝池實例，你能夠將其總大小設置爲 8 GiB，這樣每一個實例的大小即爲 4 GiB。

SET GLOBAL innodb_buffer_pool_size=8589934592;

關鍵的 InnoDB 緩衝池指標

MySQL 提供了許多關於緩衝池及其利用率的指標。其中一些有用的指標可以追蹤緩衝池的總大小，緩衝池的使用量，以及其處理讀取操做的效率。

指標 Innodb_buffer_pool_read_requests 及 Innodb_buffer_pool_reads 對於理解緩衝池利用率都很是關鍵。Innodb_buffer_pool_read_requests 追蹤合理讀取請求的數量，而 Innodb_buffer_pool_reads 追蹤緩衝池沒法知足，於是只能從磁盤讀取的請求數量。咱們知道，從內存讀取的速度比從磁盤讀取一般要快好幾個數量級，所以，若是 Innodb_buffer_pool_reads 的值開始增長，意味着數據庫性能大有問題。

緩衝池利用率是在考慮擴大緩衝池以前應該檢查的重要指標。利用率指標沒法直接讀取，可是能夠經過下面的方式簡單地計算獲得：

(Innodb_buffer_pool_pages_total - Innodb_buffer_pool_pages_free) / 
 Innodb_buffer_pool_pages_total

若是你的數據庫從磁盤進行大量讀取，而緩衝池還有許多閒置空間，這多是由於緩存最近才清理過，還處於熱身階段。若是你的緩衝池並未填滿，但能有效處理讀取請求，則說明你的數據工做集至關適應目前的內存配置。

然而，較高的緩衝池利用率並不必定意味着壞消息，由於舊數據或不常使用的數據會根據 LRU 算法 自動從緩存中清理出去。可是，若是緩衝池沒法有效知足你的讀取工做量，這可能說明擴大緩存的時機已至。

將緩衝池指標轉化爲字節

大多數緩衝池指標都之內存頁面爲單位進行記錄，可是這些指標也能夠轉化爲字節，從而使其更容易與緩衝池的實際大小相關聯。例如，你可使用追蹤緩衝池中內存頁面總數的服務器狀態變量找出緩衝池的總大小（以字節爲單位）：

Innodb_buffer_pool_pages_total * innodb_page_size

InnoDB 頁面大小是可調整的，可是默認設置爲 16 KiB，或 16,384 字節。你可使用 SHOW VARIABLES 查詢瞭解其當前值：

SHOW VARIABLES LIKE "innodb_page_size";

結論

在本文中，咱們介紹了許多你應該加以監控從而瞭解 MySQL 活動與性能表現的重要指標。若是你正在躊躇 MySQL 監控方案，抓取下面列出的指標能讓你真正理解數據庫的使用模式與可能的限制狀況。這些指標也能幫助你發現，什麼時候擴展服務器內存或將數據庫移至更爲強大的主機，從而保持良好的應用性能。

• 查詢吞吐量

• 查詢延遲與錯誤

• 客戶端鏈接與錯誤

• 緩衝池利用率

鳴謝

很是感謝來自 Oracle 的 Dave Stokes 與 VividCortex 的 Ewen Fortune，他們在本文發佈以前提供了許多寶貴的反饋意見。

本文系 OneAPM工程師編譯整理。OneAPM Cloud Insight 集監控、管理、計算、協做、可視化於一身，幫助全部 IT 公司，減小在系統監控上的人力和時間成本投入，讓運維工做更加高效、簡單。想閱讀更多技術文章，請訪問 OneAPM 官方技術博客。

本文轉自 OneAPM 官方博客

原文地址：https://www.datadoghq.com/blog/monitoring-mysql-performance-metrics/