現場如下圖所示:

開始排查網絡問題
在監控里面發現網絡一直很穩定。而且如果是網絡出現問題，同一網段的應用應該也都會報錯才對。事實上只有對應的應用和中間件報錯。

排查日志

發現一旦有 中間件的register err 必定會出現中間件調用后端數據庫的sql read timeout的報錯。但這兩個報錯完全不是在一個線程里面的，一個是處理前端的Reactor線程，一個是處理后端SQL的Worker線程，如下圖所示:

這兩個線程是互相獨立的，代碼中并沒有發現任何機制能讓這兩個線程互相影響。

進一步進行排查

和之前的慢SQL一樣，都是調用第二個數據庫超時，而DBA那邊卻說SQL執行沒有任何異常，

感覺明顯SQL執行有問題，只不過DBA是采樣而且將采樣耗時平均的，偶爾的幾筆耗時并不會在整體SQL的耗時里面有所體現。

日志分析

從日志入手， REACTOR線程和Worker線程同時報錯，但兩者并無特殊的關聯，說明可能是同一個原因引起的兩種不同現象。在線上報錯日志里面進行細細搜索，發現在大量的

NIOReactor-1-RW register err java.nio.channels.CloasedChannelException

日志中會摻雜著這個報錯:

NIOReactor-1-RW Socket Read timed out

at XXXXXX . doCommit

at XXXXXX Socket read timedout

發現了端倪，Reactor作為一個IO線程，我們的中間件在處理commit/rollback這樣的操作時候還是在Reactor線程進行的。很明顯Reactor線程卡主是由于commit慢了

由于app1的commit特別慢而卡住了reactor1線程，從而落在reactor1線程上的握手操作都會超時！如下圖所示:

為什么commit會變慢?

commit變慢所關聯的DB正好也是出現慢SQL的那個DB。發現其中和存儲相關的HBA卡有報錯！如下圖所示: 

報錯時間都是一致的！

推薦閱讀：

明辰智航云安網絡與虛擬化性能管理系統（www.mingczh.com）