**自 嚴陣以待
目錄上週客戶說系統突然變得很慢，而且時不時的蹦出乙個404和500，弄得真的是很沒面子，而恰巧出問題的時候正在深圳出差，所以一直沒有時間
看問題，一直到今天，才算是把問題原因找到。
剛開始得到是系統慢的反饋，沒有將問題點定位到資料庫上，查了半天服務是否正常（因為之前有一次dubbo記憶體洩漏）。
在將應用服務日誌檢視了一遍後，沒有發現任何異常，只是打了幾個警告的日誌。
於是又檢視了業務執行時的日誌，看到日誌都提示了乙個lock wait timeout exceeded; try restarting transaction的異常。
這時還是沒有將重心放到資料庫上，認為是**的原因，導致事務一直沒有提交。
重新將**審閱了一遍，覺得應該不是**邏輯的問題，而這個時候，lock wait timeout exceeded; try restarting transaction這個異常的日誌越來越多。
認為是資料庫層面出了問題，開始排查資料庫。
由於我們的資料庫不是用的 雲rds版本，是在一台8核32g的aws上的安裝版本。
使用 top 命令，檢視到 mysql 占用的 cpu 使用率高達 90% 左右。
心裡一慌，感覺不妙，這樣子高負載的cpu使用率，搞不好伺服器都要宕掉。
於是拿出了僅有的一點mysql基本知識，基本上這次只使用到了下面幾個語句：
檢視當前mysql所有的程序
show processlist;
檢視mysql的最大快取
show global variables like "global max_allowed_packet"
檢視當前正在進行的事務
select * from information_schema.innodb_trx
檢視當前mysql的連線數
show status like 'thread%'
按照上面的幾個語句，一步一步跟蹤定位下來。
show processlist; 下來，我們就可以檢視出當前所有的程序，並且得到最耗時的程序。
在當前資料庫中，看到處於sleep狀態的sql非常多，而這也是占用cpu過高的重大原因，休眠執行緒太多，於是配置了乙個wait_time_out為 600 秒的乙個解決方案。
為什麼配置600秒，因為我們應用超時時間配置的最大時間就是 600秒，10分鐘，這裡的配置需要根據業務來具體配置。
select * from information_schema.innodb_trx
執行這個語句，看到mysql中大部分處於 lock 的sql是一條update的sql，而且還有乙個單條件的sql，查詢居然耗時4分鐘，很是驚訝。
於是檢視了這張表。
剛一開啟結構，差點沒忍住口吐芬芳，居然乙個索引都沒有，資料量超過300w，沒有索引查詢基本上都要4分鐘往上走。
於是準備加上索引，在一陣漫長的等待中，索引終於加上去了。
show status like 'thread%'
索引加上去了之後，檢視了一下當前mysql的連線數，似乎沒有之前那麼高了，估計是擠壓的太多。
然後又檢視了下伺服器的cpu佔用率，這次好了一點，從1%到80%來回跳動，沒有出現90&那麼高的頻率。
mysql作為使用頻率非常高的資料庫，對於它的sql調優真的是一門技術活，而且專案中的一些sql看的也是想吐，這種調優起來真的難上加難。
其實 information_schema 這個資料庫，裡面的mysql日誌看起來比業務日誌順眼的很多。
排查Mysql突然變慢
剛開始得到是系統慢的反饋，沒有將問題點定位到資料庫上，查了半天服務是否正常 因為之前有一次dubbo記憶體洩漏 在將應用服務日誌檢視了一遍後，沒有發現任何異常，只是打了幾個警告的日誌。於是又檢視了業務執行時的日誌，看到日誌都提示了乙個lock wait timeout exceeded try re...
程式呼叫mysql突然變慢 排查Mysql突然變慢
定位問題 剛開始得到是系統慢的反饋，沒有將問題點定位到資料庫上，查了半天服務是否正常 因為之前有一次dubbo記憶體洩漏 在將應用服務日誌檢視了一遍後，沒有發現任何異常，只是打了幾個警告的日誌。於是又檢視了業務執行時的日誌，看到日誌都提示了乙個 lock wait timeout exceeded ...
網絡卡變慢 記一次線上請求偶爾變慢的排查
最近解決了個比較棘手的問題，由於排查過程挺有意思，於是就以此為素材寫出了本篇文章。這是乙個偶發的效能問題。在每天幾百萬比交易請求中，平均耗時大約為300ms，但總有那麼100多筆會超過1s，讓我們業務耗時監控的99.99線變得很尷尬。如下圖所示 為了精益求精,更為了消除這個尷尬的指標，筆者開始探尋起...