答客問

MySQL 出現 too many connections ，程式掛點了（已解決）

4 月 01

每個網站擁有者都希望自己的站人氣鼎沸，但是隨著造訪人次和服務深度的提昇，對網站的資源就會有越大的需求。

一般而言，直接碰到的問題包括：

這些都需要花錢、花人力才能解決。但是，在確定投入金錢、人力之前，恐怕得先檢查一下出問題的原因，就像標題這種常見的問題，極可能像是蝴蝶效應般悄悄地伺機而動呢。

以下，就提供一個造成 MySQL 發出 too many connections 警訊的案例，足見程式設計的工作必須是很審慎、精密的計劃，否則將重重打擊系統的穩定性。

事情是從有人透過 FTP 持續大量下載開始，把有限的頻寬佔滿了。（問題一，不是人人都有無上限的頻寬，而現在上網的頻寬遠大於網站的頻寬）

之後，有網站是以程式方式管控網站上的檔案下載。因此，在下載檔案時，會與 MySQL 建立連線。
結果因為頻寬滿載了，造成下載檔案的速度變慢、時間拉長，也因此造成 MySQL Connection 佔線過久。

同時，部份網友慣用 Flashget 之類的多緒下載軟體，也造成下載一個檔案會建立多個連線，加重系統負載。

因此，原本運作正常的網站，只因為有人把頻寬佔滿，就造成 MySQL 出現 too many connections 的警訊，讓系統的穩定性大大降低。

檢討整個問題的關鍵，在於 MySQL connection 的連線時間不應該等同於下載的時間。

換言之，所有程式在與任何伺服器連線、取得資料的過程上，應該盡可能縮短。這可能包括：必要時才連線、盡可能集中查詢動作、用完即退出連線等等。

然而，在越複雜的系統中，與其他伺服器（如 MySQL、memcached、...）的連線可能是頻繁而分散的，要如何清楚掌握連線狀況作最有效的利用，一樣隨時在考驗著程式設計師的專注力。

註：實際測了一下 MySQL 建立連線的時間大約 0.00045 秒，中止連線的時間約 0.00015 秒。因此，在程式設計上應該採用隨用隨連、用完即還的作法，避免佔用連線通道。