MySQL 出現 too many connections ,程式掛點了(已解決)
4 月 01
網路技術 MySQL, 主機管理 No Comments / 4,735 views
每個網站擁有者都希望自己的站人氣鼎沸,但是隨著造訪人次和服務深度的提昇,對網站的資源就會有越大的需求。
一般而言,直接碰到的問題包括:
- 頻寬需求 (bandwidth)
- 主機效能 (server performace)
- 儲存效率 (storage efficient)
- 穩定性 (stability)
這些都需要花錢、花人力才能解決。但是,在確定投入金錢、人力之前,恐怕得先檢查一下出問題的原因,就像標題這種常見的問題,極可能像是蝴蝶效應般悄悄地伺機而動呢。
以下,就提供一個造成 MySQL 發出 too many connections 警訊的案例,足見程式設計的工作必須是很審慎、精密的計劃,否則將重重打擊系統的穩定性。
事情是從有人透過 FTP 持續大量下載開始,把有限的頻寬佔滿了。(問題一,不是人人都有無上限的頻寬,而現在上網的頻寬遠大於網站的頻寬)
之後,有網站是以程式方式管控網站上的檔案下載。因此,在下載檔案時,會與 MySQL 建立連線。
結果因為頻寬滿載了,造成下載檔案的速度變慢、時間拉長,也因此造成 MySQL Connection 佔線過久。
同時,部份網友慣用 Flashget 之類的多緒下載軟體,也造成下載一個檔案會建立多個連線,加重系統負載。
因此,原本運作正常的網站,只因為有人把頻寬佔滿,就造成 MySQL 出現 too many connections 的警訊,讓系統的穩定性大大降低。
檢討整個問題的關鍵,在於 MySQL connection 的連線時間不應該等同於下載的時間。
換言之,所有程式在與任何伺服器連線、取得資料的過程上,應該盡可能縮短。這可能包括:必要時才連線、盡可能集中查詢動作、用完即退出連線等等。
然而,在越複雜的系統中,與其他伺服器(如 MySQL、memcached、...)的連線可能是頻繁而分散的,要如何清楚掌握連線狀況作最有效的利用,一樣隨時在考驗著程式設計師的專注力。
註:實際測了一下 MySQL 建立連線的時間大約 0.00045 秒,中止連線的時間約 0.00015 秒。因此,在程式設計上應該採用隨用隨連、用完即還的作法,避免佔用連線通道。