監(jiān)控 mysql 性能指標(biāo)和管理數(shù)據(jù)庫并不困難。是的，你沒聽錯(cuò)。有了適當(dāng)?shù)谋O(jiān)控策略和工具，您終于可以退居二線了。 red 方法與 releem 強(qiáng)大的監(jiān)控功能和易于應(yīng)用的配置建議相結(jié)合，可以為您完成繁重的工作。
紅色方法簡介
RED方法傳統(tǒng)上用于監(jiān)控Web應(yīng)用程序和服務(wù)的性能，但也可以應(yīng)用于MySQL性能監(jiān)控。 Releem 發(fā)現(xiàn)該框架在監(jiān)控 MySQL 性能指標(biāo)方面同樣有價(jià)值，因?yàn)閿?shù)據(jù)庫在性能和可靠性方面面臨的挑戰(zhàn)反映了 Web 應(yīng)用程序遇到的挑戰(zhàn)。
當(dāng)應(yīng)用于 MySQL 數(shù)據(jù)庫時(shí)，RED 方法分為三個(gè)關(guān)鍵關(guān)注領(lǐng)域，每個(gè)領(lǐng)域都提供有關(guān)數(shù)據(jù)庫運(yùn)行狀況的見解：
查詢率（Rate） – 這評估每秒執(zhí)行的查詢或命令的數(shù)量，提供服務(wù)器工作負(fù)載的直接測量。它有助于評估數(shù)據(jù)庫處理并發(fā)操作的能力及其對用戶需求的響應(yīng)能力。
錯(cuò)誤率（Errors） – 跟蹤查詢中的錯(cuò)誤頻率可以揭示數(shù)據(jù)庫中潛在的可靠性問題。高錯(cuò)誤率可能表明查詢語法、數(shù)據(jù)庫模式或影響整體數(shù)據(jù)庫完整性的系統(tǒng)約束存在潛在問題。用于監(jiān)控速率的主要 MySQL 指標(biāo)是 Aborted_clients。
查詢執(zhí)行持續(xù)時(shí)間（持續(xù)時(shí)間） – 持續(xù)時(shí)間指標(biāo)是查詢完成（從啟動(dòng)到執(zhí)行）所需時(shí)間的度量。該性能指標(biāo)評估數(shù)據(jù)檢索和處理操作的效率，這對用戶體驗(yàn)和系統(tǒng)吞吐量有直接影響。
這些指標(biāo)的運(yùn)行狀況可以讓您深入了解數(shù)據(jù)庫的性能，進(jìn)而了解用戶的體驗(yàn)。 RED 方法可以輕松判斷數(shù)據(jù)庫出了什么問題以及需要修復(fù)什么。例如，如果您發(fā)現(xiàn)查詢執(zhí)行緩慢，則可能表明需要調(diào)整索引或優(yōu)化受影響的查詢以提高效率。
RED 方法所必需的 8 個(gè) MySQL 性能指標(biāo)
為了將 RED 方法有效地應(yīng)用于 MySQL 性能監(jiān)控，Releem 專注于數(shù)據(jù)庫的八個(gè)關(guān)鍵方面。其中每一項(xiàng)都以某種方式與速率、錯(cuò)誤或持續(xù)時(shí)間聯(lián)系在一起：
1.MySQL 延遲
延遲測量執(zhí)行查詢所需的時(shí)間 – 從查詢發(fā)送到數(shù)據(jù)庫的那一刻到數(shù)據(jù)庫響應(yīng)。延遲直接影響用戶如何看待您的應(yīng)用程序。
對于大多數(shù) Web 應(yīng)用程序來說，數(shù)據(jù)庫操作的延遲在幾毫秒到大約 10 毫秒范圍內(nèi)被認(rèn)為是非常好的。此范圍可確保無縫的用戶體驗(yàn)，因?yàn)樽罱K用戶幾乎察覺不到延遲。
對于簡單到中等復(fù)雜的查詢，一旦延遲達(dá)到 100 毫秒或以上，用戶就會(huì)開始注意到延遲。在即時(shí)反饋至關(guān)重要的情況下，例如在表單提交、搜索查詢或動(dòng)態(tài)內(nèi)容加載中，這可能會(huì)成為問題。
有關(guān) MySQL 延遲的更多信息
2. 吞吐量
吞吐量，量化為每秒查詢數(shù) (QPS)，衡量數(shù)據(jù)庫的效率及其管理工作負(fù)載的能力。高吞吐量意味著經(jīng)過良好優(yōu)化的數(shù)據(jù)庫系統(tǒng)可以有效地處理大量查詢。低吞吐量可能表明性能瓶頸或資源限制。
實(shí)現(xiàn)高吞吐量通常涉及優(yōu)化的 SQL 查詢、適當(dāng)?shù)挠布Y源（CPU、內(nèi)存和快速 IO 子系統(tǒng)）以及微調(diào)的數(shù)據(jù)庫配置的組合。
有關(guān)吞吐量的更多信息
3.慢查詢計(jì)數(shù)
慢查詢本質(zhì)上是違反預(yù)定義執(zhí)行時(shí)間閾值的數(shù)據(jù)庫請求。您可以調(diào)整此閾值以適應(yīng)您的特定性能目標(biāo)或操作基準(zhǔn)。跟蹤慢速查詢的數(shù)量是您識(shí)別需要優(yōu)化的查詢的方法。
這些慢速查詢的識(shí)別和記錄發(fā)生在 Slow_query_log 中，這是一個(gè)專用文件，用于存儲(chǔ)有關(guān)無法滿足設(shè)定性能標(biāo)準(zhǔn)的查詢的詳細(xì)信息。
有關(guān)慢查詢計(jì)數(shù)的更多信息
4. 中止的客戶端
此指標(biāo)計(jì)算由于客戶端未正確關(guān)閉連接而中止的連接數(shù)。大量中止的客戶端可能表明了一系列原因：
網(wǎng)絡(luò)延遲和抖動(dòng)導(dǎo)致超時(shí)
服務(wù)器容量限制導(dǎo)致連接被拒絕
查詢之間的資源爭用
長時(shí)間運(yùn)行的查詢導(dǎo)致效率低下
MySQL 設(shè)置中的配置錯(cuò)誤
應(yīng)用程序錯(cuò)誤觸發(fā)過早斷開連接
有關(guān)中止客戶的更多信息
5.CPU使用率
CPU 是服務(wù)器的大腦。它執(zhí)行命令并執(zhí)行計(jì)算，允許數(shù)據(jù)庫存儲(chǔ)、檢索、修改和刪除數(shù)據(jù)。密切關(guān)注 CPU 使用情況有助于確保服務(wù)器有足夠的處理能力來處理其工作負(fù)載。高 CPU 使用率可能是服務(wù)器過載而難以滿足其需求的明顯跡象。
以下是一些關(guān)于 CPU 使用情況需要考慮的一般準(zhǔn)則：
50-70% 持續(xù) – 在此級別，您的 CPU 可以有效處理中度到重度工作負(fù)載，但仍有一些峰值負(fù)載空間。對于正常運(yùn)行的服務(wù)器來說這是一個(gè)健康的范圍。
70-90% 持續(xù) – 當(dāng) CPU 使用率持續(xù)在此范圍內(nèi)時(shí)，表明工作負(fù)載較高，為處理峰值需求留下的空間有限。您應(yīng)該密切監(jiān)控服務(wù)器。
超過 90% 持續(xù) – 這是服務(wù)器接近或達(dá)到其容量的有力指標(biāo)。可能會(huì)出現(xiàn)明顯的性能問題，包括查詢響應(yīng)時(shí)間慢和潛在的超時(shí)。調(diào)查原因并相應(yīng)地實(shí)施優(yōu)化或擴(kuò)展資源至關(guān)重要。
注意： 偶爾高于這些閾值的峰值不一定表示存在問題，因?yàn)閿?shù)據(jù)庫旨在處理可變負(fù)載。關(guān)鍵詞是持續(xù)。持續(xù)高使用率表明您的服務(wù)器承受著巨大的壓力。
6. 內(nèi)存使用情況
RAM 是數(shù)據(jù)庫的關(guān)鍵資源，因?yàn)樗鎯?chǔ)活動(dòng)數(shù)據(jù)和索引，允許快速訪問和高效的查詢處理。正確管理 RAM 使用可確保數(shù)據(jù)庫能夠有效處理工作負(fù)載，從而優(yōu)化數(shù)據(jù)檢索和操作操作。
以下是 RAM 使用時(shí)需要考慮的一些一般準(zhǔn)則：
– 這個(gè)范圍通常被認(rèn)為是安全的，表明有足夠的內(nèi)存可用于當(dāng)前數(shù)據(jù)庫操作和額外的工作負(fù)載峰值。
70-85% 利用率 – 當(dāng) RAM 使用率持續(xù)落在這個(gè)范圍內(nèi)時(shí)，表明數(shù)據(jù)庫正在充分利用可用內(nèi)存，但開始達(dá)到需要仔細(xì)監(jiān)控的閾值。在高峰時(shí)段保持在這個(gè)范圍內(nèi)可能會(huì)限制處理需求突然增加的緩沖。
85-90% 利用率 – 在此范圍內(nèi)，服務(wù)器接近其內(nèi)存容量。當(dāng)系統(tǒng)開始與磁盤交換數(shù)據(jù)時(shí)，高內(nèi)存利用率可能會(huì)導(dǎo)致磁盤 I/O 增加。將此視為一個(gè)警告信號(hào)，表明需要優(yōu)化工作負(fù)載或需要擴(kuò)展服務(wù)器的物理內(nèi)存。
>95% 利用率 – RAM 使用率達(dá)到或高于 95% 時(shí)至關(guān)重要，可能會(huì)導(dǎo)致性能問題。在此級別，服務(wù)器可能會(huì)頻繁地訴諸交換，從而導(dǎo)致嚴(yán)重的速度減慢，并可能導(dǎo)致客戶端應(yīng)用程序超時(shí)。您需要立即采取行動(dòng)。
7. 互換使用
當(dāng)數(shù)據(jù)庫的物理 RAM 被充分利用時(shí)，就會(huì)使用交換空間，允許系統(tǒng)將一些不常訪問的數(shù)據(jù)卸載到磁盤存儲(chǔ)。雖然此機(jī)制有助于緩沖內(nèi)存不足錯(cuò)誤，但依賴 SWAP 可能會(huì)嚴(yán)重影響性能，因?yàn)榕c RAM 相比，訪問時(shí)間要慢得多。
理想情況下，MySQL 服務(wù)器應(yīng)該表現(xiàn)出低至最低的 SWAP 使用率。這表明數(shù)據(jù)庫正在其可用 RAM 內(nèi)運(yùn)行。
高 SWAP 使用率是一個(gè)危險(xiǎn)信號(hào)，表明服務(wù)器的物理內(nèi)存不足以滿足其工作負(fù)載，迫使其依賴磁盤空間來進(jìn)行日常數(shù)據(jù)操作。您應(yīng)該立即采取措施解決這個(gè)問題，通過優(yōu)化應(yīng)用程序的內(nèi)存需求或擴(kuò)大服務(wù)器的 RAM。
8. 每秒輸入/輸出操作數(shù) (IOPS)
每秒輸入/輸出操作數(shù) (IOPS) 指標(biāo)指示數(shù)據(jù)庫與其底層存儲(chǔ)系統(tǒng)（又稱磁盤）交互的密集程度。高水平的 IOPS 意味著在存儲(chǔ)介質(zhì)之間傳輸?shù)臄?shù)據(jù)負(fù)載很重，這雖然表明數(shù)據(jù)庫繁忙，但也可以突出磁盤性能的潛在瓶頸。
影響 IOPS 的一些關(guān)鍵因素包括：
存儲(chǔ)介質(zhì)類型，SSD 的速度通常優(yōu)于 HDD
RAID 配置，可以優(yōu)化讀取或?qū)懭氩僮?br />
數(shù)據(jù)庫工作負(fù)載的具體需求，無論是讀密集型還是寫密集型
緩存策略的并發(fā)程度和有效性
Releem 的數(shù)據(jù)庫管理綜合策略
Releem 的 MySQL 性能監(jiān)控方法是密切關(guān)注重要細(xì)節(jié)。該策略包括對提到的 8 個(gè)指標(biāo)進(jìn)行認(rèn)真跟蹤——MySQL 延遲、吞吐量、慢速查詢、中止的客戶端、CPU、RAM、SWAP 使用情況和 IOPS——所有這些都在 RED 方法的框架內(nèi)。通過將此監(jiān)控集成為每日兩次運(yùn)行狀況檢查（19 個(gè)指標(biāo)！）的一部分，Releem 可以幫助您的數(shù)據(jù)庫實(shí)現(xiàn)并保持高水平的性能、可靠性和可擴(kuò)展性。
除了密切關(guān)注 MySQL 性能之外，Releem 還進(jìn)一步提供量身定制的配置建議，旨在修復(fù)監(jiān)控過程中發(fā)現(xiàn)的任何問題。我們將此功能稱為 Autopilot for MySQL。例如，如果您遇到高延遲問題，Releem 將提供可操作的見解，使您的延遲數(shù)字恢復(fù)正常。我們的最終目標(biāo)是通過強(qiáng)大、直觀的軟件消除手動(dòng)監(jiān)督的需要，該軟件可以處理您不想擔(dān)心的所有數(shù)據(jù)庫管理復(fù)雜性。
Releem 具有廣泛的兼容性，因此無論您使用 Percona、MySQL 還是 MariaDB 作為數(shù)據(jù)庫管理系統(tǒng) – Releem 都可以提供幫助。在這里查看支持系統(tǒng)的官方列表。
要深入探索 MySQL 數(shù)據(jù)庫監(jiān)控和優(yōu)化的每個(gè)指標(biāo)和最佳實(shí)踐，請考慮訪問 Releem.com。
