雲計算之路-阿里雲上：服務器CPU 100%問題是memcached鏈接數限制引發的

很是抱歉，昨天的服務器CPU 100%問題是達到 memcached 的鏈接數限制引發的，不是阿里雲服務器的問題。

以前咱們用的是阿里雲「雲數據庫 memcached 版」，上個週末咱們換成了本身搭建——基於阿里雲「內存網絡加強型」服務器用 docker 跑 memcached 。

docker run -d --net=host --restart unless-stopped memcached -m 15360

但咱們在部署 memcached 時沒有設置 conn-limit 參數（默認值是 1024） 。

因爲週一週二兩天服務器沒出現問題，並且週二的訪問量超過了上週的最高，咱們誤覺得此次 memcached 的部署調整沒問題。而沒問題的背後是由於週一週二的web服務器數量比昨天少，恰好沒達到 memcached 的鏈接數限制。

昨天（週三）咱們收到 1 臺服務器的 CPU 報警後，多加了 1 臺服務器，恰好讓 memcached 的鏈接數達到了臨界值，在下午併發鏈接數上去後，很容易觸發 memcached 的鏈接限制，web 服務器因沒法使用緩存而讓 CPU 不堪重負。在這樣的狀況下，減服務器反而是有利的，而咱們慌亂之下依照 CPU 負載高就加服務器的錯誤直覺操做則是雪上加霜。。。

當今天上午再次有服務器出現 CPU 100% 問題時，咱們纔想到 memcached 的鏈接數限制

STAT max_connections 1024
STAT curr_connections 960

趕忙將 max_connections 由默認的 1024 修改成 2048

docker run -d --net=host --restart unless-stopped memcached -m 15360 -c 2048 && docker stop 51bd3b240ede

以後 CPU 100% 的問題就解決了

STAT max_connections 2048
STAT curr_connections 1232

很是抱歉，因爲咱們在處理故障時不夠冷靜、考慮不周，給您帶來了麻煩，請您諒解。

咱們會吸收教訓，提升咱們在處理故障時的判斷與定位能力。