MYSQL CPU部分單核占滿是否會影響建立數(shù)據(jù)庫連接效率

MYSQL CPU部分單核占滿是否會影響建立數(shù)據(jù)庫連接效率，很多新手對此不是很清楚，為了幫助大家解決這個難題，下面小編將為大家詳細講解，有這方面需求的人可以來學習下，希望你能有所收獲。

問題描述：

cpu 瞬間爆滿，前臺應用程序報出 too many connection錯誤，mysql ERROR日志報出[Warning] Too many connections，操作系統(tǒng)日志報出： kernel: TCP: time wait bucket table overflow。

主機的資源情況如下：

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

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

3.數(shù)據(jù)庫所在磁盤IO幾乎打滿。

數(shù)據(jù)庫情況：

1.監(jiān)控采集程序連不上數(shù)據(jù)庫，無法采集到數(shù)據(jù)庫指標， 說明數(shù)據(jù)庫連接在短時間內(nèi)突然激增，無逐漸上升趨勢。

2.故障期間無慢日志。

3.抓取BINLOG，故障剛開始后無新事務產(chǎn)生。

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

5.登上數(shù)據(jù)庫時有發(fā)現(xiàn)大量會話是unauthenticated user狀態(tài)

業(yè)務情況：

1.正屬業(yè)務高峰期，但并無明顯的業(yè)務突然上漲情況

2.業(yè)務應用采用jdbc連接池，連接異常時會不斷重試連接

思路：

故障時有同事執(zhí)行了16并行的pigz 操作，這也是以上主機cpu及IO資源異常問題，懷疑此異常即影響了數(shù)據(jù)庫的連接。而主要是CPU 的請求異常影響了不斷涌進來的數(shù)據(jù)庫連接請求。

我的判斷依據(jù)：

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

2.那么連接可能hang在那個階段呢：

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

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

3）sleep的連接沒有釋放？首先程序并未做過任何變動，連接無法斷開可能是數(shù)據(jù)庫本地異常，但如果是這樣，我認為連接開始就不能正常連接了。因此連接應該能夠正常斷開

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

我做了個實驗，在CPU使用率持續(xù)100% 的情況下發(fā)起大量的連接在數(shù)據(jù)庫連接期間對CPU的需求還是比較大

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

目前仍無法肯定根因：

因為，CPU 只是一部分滿而已，這需要進一步了解LINUX CPU 調(diào)度的工作原理。

系統(tǒng)中斷和上下文切換是否可以說明就是大量的系統(tǒng)調(diào)用請求異常。

看完上述內(nèi)容是否對您有幫助呢？如果還想對相關知識有進一步的了解或閱讀更多相關文章，請關注億速云行業(yè)資訊頻道，感謝您對億速云的支持。