mysql伺服器io負載較高,mysql io高

本文目錄一覽：

1、MySQL CPU佔用過高怎麼辦
2、記一次mysql磁碟io高的問題排查
3、mysql中cpu負載很高，是什麼原因
4、如何定位導致mysql伺服器io壓力大的進程
5、Mysql伺服器負載很高，性能問題排查思路是怎樣的
6、如何查看mysql io高的表

MySQL CPU佔用過高怎麼辦

MySQL CPU佔用過高原因主要有以下幾種

CPU過時（比較舊的CPU）

RAM資源不足（RAM記憶體）

解決辦法如下：

①臨時解決方案

首先是ctrl+alt+delete快捷鍵打開工作管理員

然後找到下方圖一中的mysqld.exe

右擊移至詳細資料

再來右擊設定優先順序

按照下方圖二的步驟

根據佔用情況調整成低於標準或者低

這個方法只能臨時解決

②實際解決方法是更換CPU

總結：根據正常的mysql使用，即使大量數據往來也不會造成CPU佔用過高，目前推論應該是CPU比較過時的原因，治標不治本的臨時解決方案。

備註：如採取方案②你需要備份你的資料，因為更換CPU會有很大的機會需要重新安裝你的作業系統。

記一次mysql磁碟io高的問題排查

現象是，系統里的java連接mysql超時了，

於是去mysql的機器，查看/var/log/messages日誌，查對應的時間點的情況

發現mysql被阻塞了blocked for more than 120 seconds，mysql的io非常之高，用top查看系統的負載也到達了50的樣子

用mpstat查看cpu情況

好明顯，都在等io

用iostat查看io情況，%util的值，一直在80%，99%之間變化

以為磁碟有問題，用dd測下速看看

從上面的結果看，也還好，沒問題

以為可能磁碟有壞道，用下面命令也掃了一遍，沒問題

結果也沒有壞的塊，這個過程，很耗時。

用show processlist命令查看mysql正在忙著什麼，一看，也沒什麼任務在執行的

想看看mysql，研究寫哪個文件時，最耗時的

從上面結果來看，xxl_job是最耗時的。知道點眉目了，因為公司的定時任務是用的xxljob，定時任務里，有每幾秒執行的任務，我猜它的日誌記錄一定很大，於是查看一下

我的天，這個表的記錄有千萬！！！這些記錄，沒做定時任務來清理，由於都是一些沒用的記錄，所以這個表的數據我全清了

清了之後，再用iostat查看

%util一下子就降下來了，用iotop查看mysql進程的io也下降了

cpu的iowait也下降了

定義一個事件，讓mysql定時清理30天前的日誌記錄

記錄一下，希望對有需要的朋友也起一點提示

mysql中cpu負載很高，是什麼原因

1、確定高負載的類型 htop，dstat命令看負載高是CPU還是IO

看具體是哪個用戶哪個進程佔用了相關係統資源，當前CPU、內存誰在使用

2、監控具體的sql語句，是insert update 還是 delete導致高負載

抓取mysql包分析，一般抓3306埠的數據看出最繁忙的sql語句了

3、檢查mysql日誌

分析mysql慢日誌，查看哪些sql語句最耗時

檢查mysql配置參數是否有問題，引起大量的IO或者高CPU操作

innodb_flush_log_at_trx_commit 、innodb_buffer_pool_size 、key_buffer_size 等重要參數

4、檢查硬體問題

如何定位導致mysql伺服器io壓力大的進程

1.你可以在root賬戶下，運行iostat,vmstat,查詢看看。

分析磁碟IO，要用到兩個命令：iostat 和 sar。

iostat -d -x 10 3

Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util

主要欄位含義如下：

r/s 每秒讀操作數。

w/s 每秒寫操作數。

rsec/s 每秒從設備讀取的扇區數量。

wsec/s 每秒向設備寫入的扇區數量。

avgrq-sz I/O 請求的平均扇區數。

avgqu-sz I/O 請求的平均隊列長度。

await I/O 請求的平均等待時間，單位為毫秒。

svctm I/O 請求的平均服務時間，單位為毫秒。

%util 處理 I/O 請求所佔用的時間的百分比，即設備利用率。

#sar -pd 10 3

輸出的主要欄位含義如下：

DEV 正在監視的塊設備

tps 每秒鐘物理設備的 I/O 傳輸總量

rd_sec/s 每秒從設備讀取的扇區數量

wr_sec/s 每秒向設備寫入的扇區數量

avgrq-sz I/O 請求的平均扇區數

avgqu-sz I/O 請求的平均隊列長度

await I/O 請求的平均等待時間，單位為毫秒

svctm I/O 請求的平均服務時間，單位為毫秒

%util I/O 請求所佔用的時間的百分比，即設備利用率

Unix/Linux 系統磁碟 I/O 性能監控自動化腳本示例

2.用iotop可以看到是哪些進程IO佔用高，不過需要2.6.20以上的kernel

Mysql伺服器負載很高，性能問題排查思路是怎樣的

對於包括 mysql 在內的大多數資料庫系統而言

性能問題的排查主要有以下方向：

1. 需求的不合理造成的性能問題

比方說，不需要實時更新的內容，被要求做成實時更新

2. 架構的不合理造成的性能問題

比方說，不適合資料庫保存的數據，被存放在資料庫中

或者，頻繁訪問但是很少變更的數據，沒有做緩存

3. 查詢語句的不合理造成的性能問題

比方說，重複執行相同的 SQL 會造成資源浪費

或者，大量複雜的 join 語句會導致查詢效率低下

4. 資料庫設計的不合理造成的性能問題

比方說，盲目追求三範式、四範式，有時候並沒有必要

5. 硬體配置的不合理造成的性能問題

比方說，資料庫伺服器的 io 性能、CPU 、網路狀況，都會影響性能

以上這些都是性能問題定位和調優的方向

如何查看mysql io高的表

IO過高是指輸入輸出過高了這個有許多原因都會導致mysqlIO過高了，小編見過apache處理數據緩存導致mysqlIO過高問題當然也有其它關於mysql本身問題導致mysqlIO過高的問題了，下面給各位整理總結一下關於mysqlIO過高處理辦法。

scriptec(2);/script

1、日誌產生的性能影響:

由於日誌的記錄帶來的直接性能損耗就是資料庫系統中最為昂貴的IO資源。MySQL的日誌包括錯誤日誌（ErrorLog），更新日誌（UpdateLog），二進位日誌（Binlog），查詢日誌（QueryLog），慢查詢日誌（SlowQueryLog）等。當然，更新日誌是老版本的MySQL才有的，目前已經被二進位日誌替代。

在默認情況下，系統僅僅打開錯誤日誌，關閉了其他所有日誌，以達到儘可能減少IO損耗提高系統性能的目的。但是在一般稍微重要一點的實際應用場景中，都至少需要打開二進位日誌，因為這是MySQL很多存儲引擎進行增量備份的基礎，也是MySQL實現複製的基本條件。有時候為了進一步的性能優化，定位執行較慢的SQL語句，很多系統也會打開慢查詢日誌來記錄執行時間超過特定數值（由我們自行設置）的SQL語句。

一般情況下，在生產系統中很少有系統會打開查詢日誌。因為查詢日誌打開之後會將MySQL中執行的每一條Query都記錄到日誌中，會該系統帶來比較大的IO負擔，而帶來的實際效益卻並不是非常大。一般只有在開發測試環境中，為了定位某些功能具體使用了哪些SQL語句的時候，才會在短時間段內打開該日誌來做相應的分析。所以，在MySQL系統中，會對性能產生影響的MySQL日誌（不包括各存儲引擎自己的日誌）主要就是Binlog了。

2、mysql內執行如下指令：

set global sync_binlog=500;

當每進行500次事務提交之後，MySQL將進行一次fsync之類的磁碟同步指令來將binlog_cache中的數據強制寫入磁碟。

set global innodb_flush_log_at_trx_commit=2;

默認值1代表每一次事務提交或事務外的指令都需要把日誌寫入（flush）硬碟，這是很費時的。特別是使用電池供電緩存（Battery backed up cache）時。設置為2代表不寫入硬碟而是寫入系統緩存。日誌仍然會每秒flush到硬碟，所以你一般不會丟失超過1-2秒的更新。設成0會更快一點，但安全方面比較差，即使MySQL掛了也可能會丟失事務的數據。而值設置為2隻會在整個操作系統宕機時才可能丟數據。

註：重新開機後，該指令失效。可在服務啟動時，設置如上兩項。

原創文章，作者：KUAA，如若轉載，請註明出處：https://www.506064.com/zh-tw/n/141602.html