《FAQ系列 | 是什么導致MySQL數據庫服務器磁盤I/O高?》要點:
本文介紹了FAQ系列 | 是什么導致MySQL數據庫服務器磁盤I/O高?,希望對您有用。如果有疑問,可以聯系我們。
有個MySQL服務器的磁盤I/O總有過高報警,怎么回事?
我的朋友小明,TA有個MySQL服務器最近總是報告磁盤I/O非常高,想著我這有免費的不用白不用的企業技術服務(TA自己這么想的),就找我幫忙給把把脈.
作為一個經驗豐富(踩坑不斷)的DBA,出現這種問題,一般來說,磁盤I/O很高無非是下面幾個原因引起:
磁盤子系統設備性能差,或采用ext2/ext3之類文件系統,或采用cfq之類的ioscheduler,所以IOPS提上不去;
SQL效率不高,比如沒有索引,或者一次性讀取大量數據,所以需要更多的I/O;
可用內存太小,內存中能緩存/緩沖的數據不多,所以需要更多的I/O.
方法論已有,接下來就是動手開始排查了.
先看磁盤I/O設備,是由十幾塊SSD組成的RAID10陣列,按理說I/O性能應該不至于太差,看iops和%util的數據也確實如此.
再來看下文件系統、io scheduler的因素,發現采用xfs文件系統,而且io scheduler用的是noop,看來也不是這個原因.而且看了下iostat的數據,發現iops也不算低,說明I/O能力還是可以的.
再來看看當前的processlist,以及slow query log,也沒發現當前有特別明顯的slow query,所以也不是這個原因了.
現在只剩下內存不足這個因素了,看了下服務器物理內存是64G,用系統命令 free 看了下,發現大部分都在cached,而free的也不多.觀察InnoDB相關的配置以及status,看能不能找到端倪.
首先,看下 innodb-buffer-pool-size 分配了多少:
嗯,分配了18G,好像不是太多啊~
再看一下 innodb status:
重點關注下幾個wait值,再看下show engine innodb結果:
關注下unpurge列表大小,看起來還是比較大的(有111萬).
更為詭異的是,在已經停掉SLAVE IO & SQL線程后,發現redo log還在一直增長…
第一次看
停掉SLAVE線程后過陣子再看
看到這里,有經驗的DBA應該基本上能想明白了,主要是因為 innodb buffer pool 太小,導致了下面幾個后果:
還有,不知道大家注意到沒,Innodb_row_lock_current_waits 的值竟然是 18446744073709551615(想想bigint多大),顯然不可能啊.事實上,這種情況已經碰到過幾次了,明明當前沒有行鎖,這個 status 值卻不小,查了一下官方bug庫,竟然只報告了一例,bug id是#71520.
既然知道原因,問題解決起來也就快了,我們主要做了下面幾個調整:
調整完后,重啟實例(5.7版本前調整innodb-buffer-pool-size 和 innodb-purge-thread 需要重啟才生效).再經觀察,發現IOPS下降的很快,不再告警,同時 Innodb_buffer_pool_wait_free 也一直為 0,unpurge列表降到了數千級別,搞定,收工,繼續搬磚賣茶~
作者:葉金榮
文章出處:老葉茶館(訂閱號ID:iMySQL_WX)
轉載請注明本頁網址:
http://www.snjht.com/jiaocheng/4388.html