轉 MySQL連線逾時

標籤：

在負載較重的MySQL伺服器上，有時你偶爾會看到一些連線逾時的錯誤，諸如: Can’t connect to MySQL server on ‘mydb’(110)。如果當時你有多個串連請求，你會發現其它串連卻沒問題。這類問題開始時很不顯眼，且長時間來看幾乎可以忽略不計（註：次數不 多），類似於百萬分之一的發生率，但是在伺服器負載不斷加重時，可能出現的頻率將有所上升。

如果你對串連進行計時你會發現，串連一般都接近3-9秒。這個時間長度有時也很詭異，多年前我就曾遇到過一次，當時資料庫請求串連被重設，SYN包一直被丟 棄。3秒就有一個SYN包被拋棄，9秒有兩被拋棄。如果你也碰到了類似情況，則有可能是你的網路存在問題或你的資料庫伺服器請求偵聽隊列溢出，你可以通過 運行netstat -s命令進行檢查，可能會返回類似於：偵聽隊列的Socket發生了38409次溢出，38409個SYN包被丟棄，這就意味著偵聽Socket的核心緩 存溢出了，SYN包將不得不被丟棄 -- MySQL並不是在需要時就儘快接受串連。

如果發生了這種情況，有2個調優的地方你可以考慮。
1. Linux核心：net.ipv4.tcp_max_syn_backlog，這參數是用來設定所有Socket核心緩衝大小的。我的系統預設值為2048，其它版本可能不盡相同，如果你的串連並發較大則你可能需要將此值提高到8192左右。具體匹配情況我會在下面介紹。

2.
MySQL參數：back_log，預設值為50。你可能需將此值設定為1000或更高。同時，你可能提高net.core.somaxconn核心參數值，這個參數是用來設定偵聽隊列的最大深度。我本人核心中此參數設定的是128，這在很多情況下會偏低。

現在我們來深入研究下這個問題。首先看看MySQL是如何接受串連的。有個主線程將接受所有請求偵聽Socket的串連。當有個新串連來到時，主線程將為 新串連建立一個新的Socket，同時建立一個新的子線程或從緩衝中取一個子線程來處理這個串連。站在MySQL網路通訊基多線程這點來看，多核是有利 的，但對於主線程來說，多核並沒什麼用。通常主線程接受串連會很快，但是，如果主線程因為互斥等待或為啟動新線程而等待，則偵聽隊列可能會溢出。我們來看 看，如果一個資料庫一般每秒能接受1000個串連，這個值很高，但你可能會碰到更高的。因為串連請求的隨機到達特性，有時你可能會看到3000個串連並發。這種情況下，預設的back_log(50)僅能支撐17毫秒，主線程在某些地方處理稍有停滯超過17毫秒，則有些SYN包將被丟棄。

我建議將tcp_max_syn_backlog和back_log的值調整到足夠支撐2秒的串連請求（註：串連請求2秒未逾時）。比方說，正常情況下每 秒有100個串連，假設峰值為3倍正常情況，則為300串連/秒，這意味著前面提到的參數至少需設到600。(註：300串連/秒 * 2秒 = 600串連/秒)

將參數設到支援2秒以上請求的意義不大，因為用戶端在3秒內未收到應答後將發出新的串連請求。

另外，如果你每秒建立了1000個MySQL串連，你可能有點過了，畢竟建立和銷毀1000個串連需使用大量的資源。考慮下使用長串連或串連池吧，至少是那種大部分串連是由應用建立的情況。

轉 MySQL連線逾時