問題描述：

cpu 瞬間爆滿，前臺應用程式報出 too many connection錯誤，mysql ERROR日誌報出[Warning] Too many connections，作業系統日誌報出： kernel: TCP: time wait bucket table overflow。

主機的資源情況如下：

1.CPU 總體資源不高，但出現單核使用率100% 情況

2.CPU 系統中斷和上下文切換指標同時突然上漲。

3.資料庫所在磁碟IO幾乎打滿。

資料庫情況：

1.監控採集程式連不上資料庫，無法採集到資料庫指標， 說明資料庫連線在短時間內突然激增，無逐漸上升趨勢。

2.故障期間無慢日誌。

3.抓取BINLOG，故障剛開始後無新事務產生。

4.日常連線數基本在500以下，故障時達到閾值3000，連線數達到閾值是個結果，問題是找出為什麼會有連線不釋放。

5.登上資料庫時有發現大量會話是unauthenticated user狀態

業務情況：

1.正屬業務高峰期，但並無明顯的業務突然上漲情況

2.業務應用採用jdbc連線池，連線異常時會不斷重試連線

思路：

故障時有同事執行了16並行的pigz 操作，這也是以上主機cpu及IO資源異常問題，懷疑此異常即影響了資料庫的連線。而主要是CPU 的請求異常影響了不斷湧進來的資料庫連線請求。

我的判斷依據：

1.連線數瞬間爆滿是個結果，原因是因為前面大部分的連線HANG住。

2.那麼連線可能hang在那個階段呢：

1）沒有慢查詢，說明不是慢sql 問題

2）binlog沒有大量超長事務，甚至故障期間沒有事務產生。說明非長事務問題

3）sleep的連線沒有釋放？首先程式並未做過任何變動，連線無法斷開可能是資料庫本地異常，但如果是這樣，我認為連線開始就不能正常連線了。因此連線應該能夠正常斷開

4）因此我想連線hang在了連線階段了。加上之前看到大量會話會在unauthenticated user 狀態，這階段應該是實在客戶端與資料庫建立了tcp連線，然後進行認證，分配執行緒的階段，如果此時資料庫獲取CPU資源有問題是不是意味著連線被放慢了，甚至HANG住。

我做了個實驗，在CPU使用率持續100% 的情況下發起大量的連線在資料庫連線期間對CPU的需求還是比較大

此時也是能看到較多的unauthenticated user 會話!

目前仍無法肯定根因：

因為，CPU 只是一部分滿而已，這需要進一步瞭解LINUX CPU 排程的工作原理。

系統中斷和上下文切換是否可以說明就是大量的系統呼叫請求異常。

現在只是說說思路，希望有緣人看了能分享下您的見解！

MYSQL CPU部分單核佔滿會影響建立資料庫連線效率？

相關文章