如何调整最大连接数限制_processes与sessions参数修改

PostgreSQL的max_connections未生效主因是shared_buffers不足或系统ulimit限制MySQL连接数告警多因wait_timeout过长导致Sleep连接堆积Python多进程下各worker独立占用连接需统一管控盲目调高连接数会加剧内存与锁竞争。PostgreSQL 的 max_connections 改了但没生效检查 shared_buffers 和 OS 限制改完 max_connections 却连不上新连接大概率不是配置写错了而是被底层卡住了。postgresql 启动时会校验几个硬性配比比如 shared_buffers 至少要达到 max_connections / 4 * 16mb 左右具体看版本否则直接拒绝启动更隐蔽的是系统级限制——linux 的 ulimit -n文件描述符上限必须 ≥ max_connections reserved_connections 一些后台进程开销否则日志里只报 out of memory 或静默失败。修改前先算假设设 max_connections 500shared_buffers 建议 ≥ 128MB别死守文档公式实测 64MB 在小内存机器上也可能崩用 ulimit -n 查当前限制临时提可用 ulimit -n 65536永久改需编辑 /etc/security/limits.conf 加 postgres soft nofile 65536改完 postgresql.conf 必须重启服务pg_reload_conf() 不生效别信“热重载支持所有参数”这种过时说法MySQL 的 max_connections 被 wait_timeout 和连接池悄悄吃掉明明 max_connections 1000监控显示活跃连接才 200却频繁报 Too many connections——八成是空闲连接没及时释放。MySQL 默认 wait_timeout 288008 小时如果应用层不显式 CLOSE 或连接池配置激进比如 HikariCP 的 maximumPoolSize 设太高大量连接卡在 “Sleep” 状态占着坑位。查真实占用SHOW PROCESSLIST 重点看 Command Sleep 且 Time 超过 300 秒的连接调低超时wait_timeout 300 和 interactive_timeout 300注意改完只影响新连接应用侧必须配连接池的 idleTimeout如 HikariCP 的 idle-timeout且值要略小于 MySQL 的 wait_timeout否则池子会往已断开的连接发请求Python 多进程场景下 max_connections 是每个子进程独立算的用 multiprocessing.Process 或 concurrent.futures.ProcessPoolExecutor 启了 8 个 worker每个都连 PostgreSQL结果数据库瞬间爆满——因为每个子进程都按配置里的 max_connections 单独申请连接8 × 100 800 连接全打到 DB 上。这不是数据库配少了是架构没对齐。别让每个 worker 自己建连接池改用父进程预建连接并传递注意PostgreSQL 连接不能跨进程共享得用 psycopg2.pool 的 ThreadedConnectionPool 替代或换 asyncpg 配合 asyncio更稳的路把数据库访问抽成单独服务HTTP/gRPCworker 全走 API连接数由服务端统一控如果非要用多进程直连务必在 postgresql.conf 里把 max_connections 设为 worker 数 × 单 worker 预估峰值连接数 × 1.5留缓冲连接数调太高反而拖慢响应留意 work_mem 和锁竞争盲目把 max_connections 拉到 2000发现简单查询变慢、CPU 持续 90%——高并发下每个连接都会分到一份 work_mem用于排序、哈希等总内存可能远超物理 RAM同时更多连接意味着更多锁等待、WAL 写放大、甚至 bgwriter 压力暴增。 灵办AI 免费一键快速抠图支持下载高清图片