maxclients调大无效？Redis连接受文件描述符限制，ulimit要一起改

后台开始报连接错误，Redis的日志里只有一行refused，没别的。重启Redis能好10分钟，之后照样。排到后面才发现不是Redis挂了，是新连接进不来。老连接一直好好的，所以监控上看不出异常。

客户端数有上限，配置项叫maxclients，默认1万。连接数到顶之后，新的TCP握手还能完成。认证那一步返回ERR max number of clients reached，然后断开。这个错误在应用日志里通常只记成连接失败，要看Redis这边才能确认。

1万这个数常常还没到，先撞的是另一个限制。Redis启动时要打开监听端口、日志文件、AOF文件，还得给每个客户端留一个文件描述符，进程能打开的文件数由ulimit -n决定。Redis会预留32个给自己用，实际能接的客户端数是maxclients和文件数上限里更小的那个。用systemd启动的，limits.conf里的设置不生效，得看unit文件里的LimitNOFILE。改完用cat /proc/进程号/limits确认，别只看配置文件。这个数跟Redis版本无关，升级不会让它变大。

INFO clients能看到connected_clients和blocked_clients两个数，前者是当前连着的，后者是被阻塞命令挂住的，两个加起来才接近上限。用redis-cli info clients一条命令就能看到，不用进监控系统。

CLIENT LIST打出来一行一个连接，带地址、空闲时间、最后执行的命令。按addr排一遍。同一台机器上几百条。先看age和cmd，再判断是没配连接池还是泄漏。最后执行的命令能看出谁在空转，全是ping的通常是健康检查没设间隔。

最常见的成因是不用连接池。每个请求新建一条连接，用完关掉，并发一上来就是几百条。PHP短生命周期，这个问题最突出，pconnect或者装个连接池中间件能压下去。连接池的初始连接数别设太大，按并发峰值配，闲置超时要回收。

另一种是泄漏，代码里拿了连接没还，进程跑得越久占得越多，重启应用就归零。看CLIENT LIST里的age字段，数值跟着进程启动时间走的，基本就是泄漏。泄漏要改代码，先止血就把应用分批重启。

调大要两边一起改。maxclients写在redis.conf里，LimitNOFILE写在systemd的unit里。只改一个不生效。改完重启，用redis-cli config get maxclients核对。config set改的是运行时的值，重启会回到配置文件里的，两个都要落盘。

急着恢复可以先CLIENT KILL ADDR 10.0.0.5:51234把异常来源踢掉，再CLIENT KILL ID按编号踢。这只治当下。根子还在应用那边。KILL之后应用会重连。起来就狂连的话照样打满，得先把连接池的上限压住。

你把连接池配好之后，connected_clients从四百多降到三十上下，告警也停了。这类问题看着像Redis扛不住，实际是客户端开得太多。监控上给connected_clients设条线，到八成报警，比等用户报错早。