Redis檔案串連數不夠導致listen sock總是可讀CPU跑滿

標籤：redis   cpu   

前幾天碰到碰到一個線上redis CPU跑滿的情況，基本無法處理正常請求了，剛開始以為是其他地方的問題，後來grep "Max open files" /proc/`pidof redis-server`/ -r  排查原來是啟動redis的時候。ulimit -n 只有1024，從而無法接受新串連。

晚高峰時間段突發的大量請求導致redis串連數超過1024，從而listen sock 持續可讀並且accept失敗，從而CPU跑滿，導致嚴重的雪崩。比如簡單複現的話，ulimit -n 20 修改當前會話的開啟檔案數，然後啟動某個伺服器程式，然後給其發送超過限制的TCP串連，這時候監聽通訊端一定會每次select / epoll的時候，都返回控制代碼可讀。從而不斷的accept調用，然後accept立即出現如下錯誤,也就是EMFILE：

accept failed. errno:24, errmsg:Too many open files.

但是，accept的實現裡面遇到控制代碼數不夠的處理方法為：留在下次處理，而不是斷開TCP串連，也是有道理的，因為下回說不定就關閉了一些呢。

但這一就會導致監聽通訊端不斷有可讀訊息，但卻accept無法接受，從而listen的backlog被塞滿；從而導致後面的串連被RST了。

這裡多囉嗦一下，memcached對於這種情況的處理有點特殊，或者說周到，如果memcache accept 的時候返回EMFILE，那麼它會立即調用listen(sfd, 0) ， 也就是將監聽通訊端的等待accept隊列的backlog設定為0，從而拒絕掉這部分請求，減輕系統負載，保全自我。還是挺不錯的。

本文出自 “技術成就夢想” 部落格，請務必保留此出處http://hxl2009.blog.51cto.com/779549/1543616

Redis檔案串連數不夠導致listen sock總是可讀CPU跑滿