limit_conn_zone 是 nginx 内存异常的隐蔽源头之一，因其 slab 预分配、哈希冲突及 slot 膨胀导致 rss 远超配置值；需通过 ipcs、nginx -t、ss 等命令定位并优化 zone 大小、key 选择与限流策略。
连接数告警本身不直接等于内存过高，但当 limit_conn_zone 共享内存区配置过大或客户端连接激增时，Nginx 会为每个客户端分配 slot 并维护状态，导致共享内存（SHM）持续增长——这正是内存占用异常的隐蔽源头之一。
确认是否是 limit_conn_zone 占用过多内存
共享内存段由 limit_conn_zone 指令定义，其大小在配置中显式指定（如 zone=addr:10m），但实际 RSS 增长可能远超该值：因为 Nginx 使用 slab 分配器管理，预分配页后即使未填满也会计入 RSS；同时高并发下哈希冲突增多，会触发额外内存申请。
- 运行
ipcs -m | grep nginx查看所有 Nginx 相关的共享内存段，重点关注 key、size 和 nattch（附加进程数） - 对比配置中
zone=name:size的 size 值与ipcs显示的字节数是否接近；若 RSS 明显偏高（例如配置 10MB，ipcs显示 15MB+），说明存在过度分配或哈希膨胀 - 检查
nginx -T | grep limit_conn_zone，确认 zone 名称和大小，并核对是否重复定义（重复会导致多个独立内存段）
分析客户端分布与连接密度
内存压力往往来自“少量 IP 占用大量 slot”，比如爬虫、恶意扫描或上游代理复用单一出口 IP。一个 zone 若按 $binary_remote_addr 划分，单个 IPv4 地址固定占 32 字节 slot，但哈希桶数量不足时会链式扩容，加剧内存开销。
- 用
ss -tnp | grep :80 | awk '{print $5}' | cut -d':' -f1 | sort | uniq -c | sort -nr | head -10快速定位连接最多的客户端 IP - 若某 IP 连接数远超合理范围（如 >500），它很可能在 zone 中独占数十甚至上百个 slot，尤其当使用
$remote_addr（含端口）而非$binary_remote_addr时更严重 - 临时验证：注释掉
limit_conn指令并重载，观察 RSS 是否明显回落；若下降显著，基本锁定是限流模块引发的内存压力
优化 limit_conn_zone 配置与替代方案
不是 zone 越大越好，关键是匹配真实连接基数。盲目设 50m 或 100m 容易造成内存浪费，且无法缓解哈希冲突问题。
- 估算合理 size：
zone=addr:10m理论支持约 32 万个唯一 IP（10×1024×1024 ÷ 32 ≈ 327680），日常业务够用；超过 10 万活跃客户端才考虑升至 20m - 改用更紧凑的 key：优先用
$binary_remote_addr（IPv4 固定 4 字节，IPv6 16 字节），避免$remote_addr:$remote_port类组合，后者会使 slot 数量指数级上升 - 搭配
limit_req降低连接频次：对高频短连接场景，用漏桶限速比硬性限连接数更省内存，例如limit_req zone=burst burst=20 nodelay - 启用
limit_conn_log_level warn，在 error.log 中记录被拒绝连接，辅助识别异常来源
结合 worker 进程 RSS 综合判断
limit_conn_zone 内存由所有 worker 共享，不体现在单个 worker 的 RSS 中，但它的分配行为会影响 worker 的整体内存映射。若发现 worker RSS 异常升高且 pmap -x [pid] | grep anon 显示大量匿名页，需排查是否因限流触发频繁 slab 重分配或与 lua_shared_dict 等其他 SHM 模块叠加占用。
- 执行
pmap -x $(pgrep nginx | head -n1) | grep -E "(anon|shmid)"，观察是否有多个 shmid 行或 anon-rss 突增 - 若
ipcs -m显示多个 zone，检查配置是否误写多个limit_conn_zone（如不同 server 块重复定义同名 zone） - 对已上线配置，可先将 zone 大小减半（如 10m → 5m），观察是否触发 “limit_conn: zone is full” 错误；若有，则说明当前设置已逼近上限，需优化 key 或引入前置负载均衡分流
