☰

使用 Percona 實現 99% 的磁碟 IO 峰值

tag-icon • tag-icon linux mysql hard-drive io percona
使用 Percona 實現 99% 的磁碟 IO 峰值

因此，我們的伺服器的磁碟 I/O 看似隨機峰值，在隨機時間且沒有明顯原因的情況下達到 99.x%，保持較高水平一段時間，然後又下降。這過去並不是一個問題，但最近磁碟 I/O 長時間保持在 99%，在某些情況下長達 16 小時。

該伺服器是專用伺服器，具有 4 個 CPU 核心和 4 GB RAM。它運行 Ubuntu Server 14.04.2，運行 percona-server 5.6，沒有其他主要版本。我們正在監控其停機時間，並且我們有一個螢幕永久顯示我們處理的伺服器的 CPU/RAM/磁碟 I/O。伺服器也正在定期修補和維護。

此伺服器是副本鏈中的第三個伺服器，並且作為故障轉移電腦存在。 MySQL資料流如下。

主伺服器 --> 主/從伺服器 --> 問題伺服器

所有 3 台機器均具有相同的規格，並由同一家公司託管。問題伺服器與第一和第二個資料中心位於不同的資料中心。

「iotop」工具向我們顯示磁碟 I/O 是由「jbd2/sda7-8」進程引起的。據我們所知，這處理檔案系統日誌，並將內容刷新到磁碟。我們的“sda7”分區是“/var”，我們的 sda8 分區是/home。不應該定期對 /home 進行讀取/寫入操作。停止 mysql 服務會導致磁碟 I/O 立即回落到正常水平，因此我們相當確定是 percona 導致了問題，這與 /var 分割區相匹配，因為這是我們的 MySQL 所在的分割資料目錄駐留在（/var /lib/mysql）。

我們使用 NewRelic 來監控所有伺服器，當磁碟 I/O 激增時，我們看不到任何可能導致它的原因。平均負載約為 2。 CPU 使用率徘徊在 25% 左右，NewRelic 表示這是由「IO 等待」而不是特定進程引起的。

我們的 mysql 設定檔是透過 Percona 設定精靈和我們的客戶應用程式所需的一些設定的組合來產生的，但沒有什麼特別花俏的。

MySQL 設定 -http://pastebin.com/5iev4eNa

我們已嘗試以下方法來嘗試解決該問題：

  • 運行 mysqltuner.pl 查看是否有任何明顯錯誤。結果看起來與其他 2 個資料庫伺服器上相同工具的結果非常相似，並且在使用之間沒有太大變化。

  • 使用了 vmstat、iotop、iostat、pt-diskstats、fatrace、lsof、pt-stalk 以及可能還有其他一些工具，但沒有任何明顯的結果。

  • 調整了“innodb_flush_log_at_trx_commit”變數。曾嘗試將其設為 0、1 和 2，但似乎沒有任何效果。這應該改變 MySQL 將交易刷新到日誌檔案的頻率。

  • 當磁碟 I/O 較高時，mysql 的「顯示完整進程清單」非常無趣，它只顯示從屬裝置從主裝置讀取資料。

一些工具的輸出顯然相當長，因此我將提供 Pastebin 鏈接，並且我無法複製和貼上 iotop 的輸出，因此我提供了螢幕截圖。

奧托普

IOTop

pt-diskstats：http://pastebin.com/ZYdSkCsL

當磁碟 I/O 較高時，「vmstat 2」向我們顯示正在寫入的內容主要是由於「bo」（緩衝區輸出），它與磁碟日誌記錄（將緩衝區/RAM 刷新到磁碟）相關

http://pastebin.com/E3LWzwjj

「lsof -p mysql-pid」（列出進程的開啟檔案）向我們顯示，正在寫入的檔案主要是/var/lib/mysql目錄中的.MYI和.MYD文件，以及master.info和relay- bin 和中繼日誌檔。即使沒有指定 mysql 進程（因此在整個伺服器上寫入任何文件），輸出也非常相似（主要是 MySQL 文件，沒有太多其他內容），這向我證實這肯定是由 Percona 引起的。

當磁碟 I/O 較高時，「seconds_behind_master」會增加。我還不確定它們會以哪種方式發生。 「seconds_behind_master」也會暫時從正常值跳到任意大的值，然後幾乎立即恢復正常，有人認為這可能是由網路問題引起的。

'顯示從屬狀態'-http://pastebin.com/Wj0tFina

RAID 控制器 (3ware 8006) 沒有任何快取功能；有人也認為快取效能不佳可能是導致該問題的原因。該控制器具有與同一客戶（儘管是網路伺服器）的其他伺服器上的卡相同的韌體、版本、修訂版等，因此我相當確定它沒有故障。我還對數組進行了驗證，結果很好。我們還有 RAID 檢查腳本，它會提醒我們任何更改。

與第二個資料庫伺服器上的網路速度相比，網路速度很糟糕，所以我想這可能是網路問題。這也與磁碟 I/O 變高之前的頻寬峰值相關。然而，即使網路確實“激增”，它也不會達到很高的流量，只是與平均值相比相對較高。

網路/磁碟IO

網路速度（使用 iPerf 產生 AWS 實例）

問題伺服器 - 0.0-11.3 秒 2.25 MBytes 1.67 Mbits/sec 第二台伺服器 - 0.0-10.0 秒 438 MBytes 366 Mbits/sec

除了速度慢以外，網路似乎還不錯。無資料包遺失，但伺服器之間的跳躍速度較慢港鐵

我很樂意提供任何相關命令的輸出，但我只能添加 2 個連結到這篇文章，因為我是新用戶:(

編輯我們就這個問題聯繫了我們的託管提供商，他們很友善地將硬碟更換為相同大小的 SSD。我們在這些 SSD 上重建了 RAID，但不幸的是問題仍然存在。

答案1

您使用哪個版本的 MySQL 伺服器？ 5.5 之後，您可以使用 Performance_schema 從資料庫取得即時統計資料。我會開始查詢

 table_io_waits_summary_by_table
 table_io_waits_summary_by_table
 table_lock_waits_summary_by_table

看看究竟發生了什麼事。

另一種解決方案是，如果您檢查緩衝池使用情況，不可能存在需要移動到記憶體的冷頁嗎？

答案2

攻擊它的最好方法就是看http://www.brendangregg.com/linuxperf.html並遵循布倫丹的建議。

具體來說，您希望他的 iosnoop 工具能夠告訴您誰訪問儲存的次數最多。但是，如果您通讀它以了解他的思考過程和方法論，那麼您會對自己大有幫助，因為從長遠來看，這將使您受益匪淺。

相關內容