【編者按】本文作者為 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/
