postgresql多实例部署需合理隔离资源：内存须按实例独占配置且总和不超物理内存25%～40%，cpu应绑定核心并限制连接数，磁盘i/o须分离存储路径，端口、数据目录与配置文件必须完全独立。
PostgreSQL 多实例部署时，不建议盲目共享核心资源，尤其是内存、CPU 和磁盘 I/O。多个实例共存本身就会带来资源竞争，若配置不当，反而导致整体性能下降、查询变慢、甚至实例间相互拖垮。关键在于“合理隔离 + 按需分配 + 可观测性”，而不是“尽量共享”。
内存（shared_buffers 和系统内存）不能共享
每个 PostgreSQL 实例都独立维护自己的 shared_buffers、work_mem、maintenance_work_mem 等内存参数。这些内存区域在启动时由各自进程独占申请，操作系统层面无法跨实例复用。
- 总内存分配量应 ≤ 主机物理内存的 70%～80%，预留空间给 OS 缓存、其他服务和突发负载
- 多个实例的
shared_buffers总和不宜超过物理内存的 25%～40%（例如 64GB 内存主机，3 个实例合计 shared_buffers 建议 ≤ 20GB） - 避免所有实例都设为“默认值”（如 128MB），要按实际数据规模和并发量差异化配置
CPU 资源可共用但需限制并发压力
CPU 是可被内核调度共享的资源，但多个实例同时执行复杂查询或 VACUUM 时，会争抢 CPU 时间片，造成响应延迟升高。
- 通过
cpuset（cgroups v1/v2）或 systemd 的AllowedCPUs=限制各实例绑定的 CPU 核心范围，避免全核争抢 - 设置
max_connections和effective_cache_size与 CPU 核心数匹配（例如 4 核机器，单实例 max_connections 不宜长期超 100） - 对批处理类实例（如 ETL）启用
idle_in_transaction_session_timeout和低优先级 CPU 调度（nice -10 启动）
磁盘 I/O 是最容易被忽视的瓶颈
多个实例若共用同一块 NVMe 或同一 RAID 组，随机读写会严重叠加，IOPS 和延迟迅速恶化，尤其在 checkpoint、WAL 写入、索引构建时。
- 生产环境强烈建议按实例划分物理/逻辑存储：不同实例使用不同挂载点，最好对应不同 SSD 或不同 LVM 逻辑卷
- WAL 目录（
pg_wal）务必与数据目录分离，多实例更需独立 WAL 存储路径，避免顺序写冲突 - 使用
iostat -x 1和pg_stat_bgwriter定期观察各实例的写放大、checkpoint 频率和平均 await
端口、数据目录、配置文件必须完全隔离
这是基础但常被轻视的一环。资源规划的前提是实例间无命名冲突、无路径交叉、无配置误覆盖。
- 每个实例使用唯一端口（如 5432、5433、5434）、独立数据目录（
/var/lib/pgsql/data-96-app）、独立日志路径 - 配置文件（
postgresql.conf、pg_hba.conf）逐实例管理，禁止软链接共用；建议用 ansible 或 pg_createcluster（Debian/Ubuntu）自动化生成 - 监控时按
port或application_name区分指标，Prometheus + postgres_exporter 中用instance=~"5432|5433"分组查告警
基本上就这些。多实例不是“多开几个服务”那么简单，它本质是多个数据库引擎在一台机器上并行运行——资源规划的核心逻辑是：把它们当独立小服务器来配，再根据实际负载做适度弹性让渡。不复杂，但容易忽略细节。
