前言

最近由于流量增大，redis 出現(xiàn)了一連串錯誤，比如：

• LOADING Redis is loading the dataset in memory
• use of closed network connection
• connection pool exhausted
• connection refuse by peer

一個個來分析。

LOADING Redis is loading the dataset in memory

這里至少有2種可能

• 可用內存太小，修改 redis.conf 中的 maxmemory 即可解決
• redis 在啟動時正在加載 dump.rdb 文件，由于加載比較慢導致 redis 在啟動時不可用

我遇到的就是第2種情況，AWS在自動擴容的時候，每個新產生的 EC2 實例都報錯，原因就是 redis 在啟動時發(fā)現(xiàn)有個 dump.rdb，然后就去加載它，導致服務器里的服務都報錯，然后就退出了，并且 redis 加載這個要好久（不知道為什么），supervisord 自動重啟了新的服務后依然報錯。

后來把鏡像中的 dump.rdb 文件刪了，服務才能正常啟動。

dump.rdb 文件產生的原因可能是之前 redis 出現(xiàn)了某種錯誤，然后在制作鏡像時也做進去了，導致新生成的實例個個都報錯。

這次吸取了教訓，下次制作鏡像之前都要先 stop 掉 redis 然后刪掉 dump.rdb 。

其他3種錯誤

一開始也是各種找資料，然后各種改配置，導致這3種錯誤都先后出現(xiàn)。

一開始我認為是 golang 代碼沒有正確處理 redis 連接異常的情況，于是各種升級 redigo，改 golang 中的 timeout 、max_active、wait 等的配置，發(fā)現(xiàn)都沒有用。

這樣來來回回折騰了大概一周，終于從 pool.Active 和 pool.MaxActive 中發(fā)現(xiàn)了貓膩。

因為我 MaxActive 設置的是 10000，于是我開了 10000 個 go runtine 去測試它，發(fā)現(xiàn)當前連接數(shù) pool.Active 老是才 4000 左右，然后就各種報錯。

那段時間也是腦子短路了，老是認為 redigo 沒有正確處理 redis 的連接才導致 pool.Active 不能上到最大。老是想著改 redigo 的代碼……

后來實在沒辦法，想著去改一改 ulimit，舊的是 500000，改到 990000，發(fā)現(xiàn)還是報連接錯誤，pool.Active 還是上不去，我想這不可能啊，這才想到會不會是 redis 本身有最大連接數(shù)的配置。上網(wǎng)一查，果然，redis-server 有一個 maxclients 的配置……默認是 4000 多，改到 10000 后，整個世界都清靜了……

其實也不能怪我，因為 redigo 也有個 max_active 參數(shù)，鬼知道 redis-server 還要設置呢 [笑哭]？

Redis 用于高并發(fā)服務的配置

Redis 客戶端（即 golang 代碼）

Wait: true 如果連接池滿了，就等待， Redis 處理很快的，等個幾微秒用戶也感覺不出來什么
IdleTimeout: 5s 一個業(yè)務邏輯5s都處理不完，那你應該優(yōu)化你的代碼了。如果設置為0，萬一這個連接失蹤了服務端就收回不了了，會產生僵尸連接的。

MaxActive: 10000 相當于這個服務器能處理每秒 10000 并發(fā)了。

Redis 服務器（即 redis-server）

maxclients 要設置得比 MaxActive 大

附加題：一臺服務器的最大文件數(shù)怎么算？

linux kernel - Need to “calculate” optimum ulimit and fs.file-max values according to my own server needs - Stack Overflow

this ends up being about 100 for every 1MB of ram.

例，如果是 4G 內存，那么打開文件數(shù)最大可以設置為：4 * 1024 * 100 = 409600

總結

以上就是這篇文章的全部內容了，希望本文的內容對大家的學習或者工作具有一定的參考學習價值，如果有疑問大家可以留言交流，謝謝大家對腳本之家的支持。

最新評論