? ? 某臺服務(wù)器的IO負(fù)載很高（iostat中的util），但是無法快速的定位到IO負(fù)載的來源進(jìn)程和來源文件，查到是mysql導(dǎo)致的，不過不能定位是那個文件最占用IO
zabbix圖形：
# top
可以見到zabbix圖形有規(guī)則性，可能是定時任務(wù)導(dǎo)致，top命令可以見到cpu的%wa很高，io在等待寫入。
排查系統(tǒng)日志，關(guān)掉系統(tǒng)所有定時任務(wù)發(fā)現(xiàn)問題沒有消失，可能是程序定時任務(wù)導(dǎo)致？再排查，開發(fā)屏蔽當(dāng)前版本的定時任務(wù)，問題還是沒有消失。
定位IO負(fù)載來源：
一、# iotop
可以見到j(luò)bd2進(jìn)程某時刻占用IO達(dá)到99%,導(dǎo)致IO阻塞，mysql連接斷掉，用戶反映訪問出現(xiàn)緩慢。
JDB2導(dǎo)致磁盤io使用率高？
參考網(wǎng)上一篇文章，http://xujpxm.blog.51cto.com/8614409/1674378
http://ju.outofmemory.cn/entry/178162
1、yum update kernel 用yum升級系統(tǒng)內(nèi)核，重啟之后查看是否有效；
2、緩解方法：修改commit值，降低文件系統(tǒng)提交次數(shù)或者禁用barrier特性；
建議文件系統(tǒng)參數(shù)為：defaults,noatime,nodiratime,barrier=0,data=writeback,commit=60
（可以通過修改fstab表或者remount重新掛載）
3、慎用方法：關(guān)閉文件系統(tǒng)日志功能? ? tune2fs -O "^has_journal" 例如： tune2fs -O "^has_journal" /dev/mapper/VolGroup-lv_home
問題還是沒有解決，這次是mysql進(jìn)程占用IO到99%。
二、pt-ioprofile定位負(fù)載來源文件
可以看到占用IO的都是mysql日志文件和表結(jié)構(gòu)文件
可能是mysql日志占用IO或者分配給mysql的內(nèi)存空間不夠？
關(guān)掉mysql的二進(jìn)制文件寫入，優(yōu)化mysql的配置（增大內(nèi)存，減少IO），問題還是沒解決。
三、業(yè)務(wù)要求先遷移線上數(shù)據(jù)再進(jìn)行測試，遷移數(shù)據(jù)庫過程中報錯：
這個庫的'log_open_gift'表怎么備份都報錯
有可能是備份正在達(dá)到MySQL超時限制，修改mysql配置。
參考網(wǎng)址：https://ottomatik.groovehq.com/knowledge_base/topics/solving-error-2013-lost-connection-to-mysql-server-during-query-when-dumping-table
net_read_timeout = 120
net_write_timeout = 900
增加max_allowed_pa??cket設(shè)置。
max_allowed_pa??cket = 512M
還是備份失敗，判斷為損壞的表，嘗試修復(fù)無果，排查最后一步為ssd硬盤存在壞道？
#?badblocks -v /dev/vdb1 > badsectors.txt
OK，9個壞道好樣的。
記一次個人排查經(jīng)過，如有不足或不妥，多謝指出~
