Supervisord守護Redis進程后無法調整maxclients問題的解決
前言
在服務器上運行Redis時，默認的最大連接數通常設置為10000。然而，在生產環境中，頻頻出現資源池打滿現象，和開發溝通后認為不可能打滿10000，所以開始排查吧。

問題現象
在高并發訪問Redis的場景下，Redis的最大連接數達到上限時，新的連接請求將會被拒絕。我們可以通過以下命令查看Redis當前的最大連接數及相關的系統資源限制：

連接Redis服務器，查看maxclients的當前設置：

竟然驚奇的發現最大連接數為4064，說明Redis的默認最大連接數配置異常，不是10000。

查看系統進程的文件描述符限制：
首先找到Redis的PID：

ps aux | grep redis

然后通過Redis的PID查看打開文件數限制：

cat /proc/<redis-pid>/limits

找到Max open files，通常情況下，默認值是4096，這將嚴重限制Redis的最大連接數。

嘗試的解決方案
1. 修改系統文件描述符限制
為了增加允許的最大打開文件數，我們首先嘗試修改系統級別的文件描述符限制。以下是步驟：

臨時修改當前會話的打開文件數限制：

ulimit -n 65536

這個命令將當前shell會話中的最大文件描述符數調整為65536。

永久修改：
編輯/etc/security/limits.conf文件，在末尾添加以下內容：

* soft nofile 65536
* hard nofile 65536

然后，修改/etc/sysctl.conf文件，添加或修改以下內容：

fs.file-max = 65536

運行以下命令使配置生效：

sysctl -p

2. 檢查

重啟redis后，通過redis-cli連接查看后仍然為4064。

定位問題
開始懷疑使用supervisord守護Redis進程時，盡管我們已經按照上述步驟修改了系統級別的限制和Redis配置文件，但是這些配置可能仍然無法生效。原因在于supervisord自身并沒有繼承系統的文件描述符限制。

我們需要在supervisord的服務配置中明確設置文件描述符限制。

最終解決方案
編輯supervisord的services配置文件

vim /usr/lib/systemd/system/supervisord.services
# 增加此配置，解除限制

LimitNOFILE=65535

如果使用systemd管理supervisord服務，還需重新加載systemd的配置：

systemctl daemon-reload
systemctl restart supervisord

驗證效果

重新啟動Redis后，可以再次通過以下命令確認Redis的maxclients和文件描述符限制已經生效：

連接Redis，查看當前的maxclients：

redis-cli CONFIG GET maxclients

查看Redis進程的文件描述符限制：

cat /proc/<redis-pid>/limits

確認Max open files已經大于10000了。

總結
在高并發場景下，調整Redis的maxclients和系統的文件描述符限制至關重要。通過修改系統設置、Redis配置文件以及supervisord守護進程的相關配置，可以確保Redis能夠處理更多的連接，避免因連接池打滿導致的服務中斷問題。