记录一下那天晚上的排查过程。广告投放系统用 Redis 6.2 做去重，凌晨任务一开，客户端连接数冲到 10000 以上，新连接报 ERR max number of clients reached，任务大批失败，但 CPU 和内存在监控里都不高。
刚开始盯着「连接用完不关，TIME_WAIT 和空闲连接一起占着配额」，折腾了半个多小时，排掉了。
排查方向其实有限，先把可能性排一排。maxclients 默认 10000，已经顶到上限。还有一种是应用侧没有连接池，每个任务线程都新建一个连接。
不容易想到的是，ulimit -n 比 maxclients 小，Redis 启动时已经自动降过上限。
动手时先看当前连接数和上限
redis-cli INFO clients && redis-cli CONFIG GET maxclients接着看连接都是从哪来的
redis-cli CLIENT LIST | awk '{print $2}' | sort | uniq -c | sort -rn | head调大系统句柄上限
echo 'redis soft nofile 65535' >> /etc/security/limits.conf运行期先临时放开上限
redis-cli CONFIG SET maxclients 20000怎么算真的好了，看的是同一批现象。INFO clients 里的 connected_clients 稳定在 3000 以内，新连接不再报错，任务的成功率回到 100%。
调 maxclients 必须同步调大 nofile，否则重启后还是被压回去；根本办法是让应用改用连接池并设置空闲回收。这类问题最好一次改到位，反复小改反而容易把原因搅混。