调整PostgreSQL shared_buffers后响应时间飙升的性能问题排查

一、shared_buffers调大后响应飙升的可能原因 #

1. WSL+Docker的内存资源竞争/swap触发 #

WSL2默认内存上限通常为主机内存的50%（你24GB内存的话默认约12GB），Docker容器运行在WSL虚拟机内。当你将shared_buffers从128MB调至256MB时，若WSL可用内存被其他进程占用，PostgreSQL的共享缓冲区可能被系统置换到swap分区——swap读写速度远慢于物理内存，直接导致响应时间暴涨，且该开销在单请求场景下也会显现。

2. 配置未协同调整 #

shared_buffers增大后，若未同步调整effective_cache_size，可能误导查询优化器，但你的场景是唯一键查询（走索引），这种概率较低，核心问题仍集中在内存层面。

二、系统性能优化方案 #

1. 修复WSL+Docker内存问题 #

• 调整WSL内存上限：在Windows用户目录下创建/修改.wslconfig文件，分配足够内存并关闭swap：

  [wsl2]
  memory=16GB
  swap=0GB
  

  保存后执行wsl --shutdown重启WSL，避免swap触发。
• 限制Docker容器内存：在docker-compose.yml中给PostgreSQL容器设置内存配额，确保容器内有足够内存容纳shared_buffers：

  services:
    postgres:
      image: postgres:latest
      deploy:
        resources:
          limits:
            memory: 2G
  

2. 优化连接池配置 #

你的连接池最大仅3个连接，完全无法支撑1000QPS并发，请求会排队等待连接。建议根据CPU核心数（Ryzen 5 3600为6核12线程）调整为max_connections=20左右，同时设置min_connections=5，确保有足够连接处理并发请求。PostgreSQL默认max_connections=100，无需额外修改。

3. 确保查询效率 #

• 验证索引有效性：执行EXPLAIN ANALYZE SELECT * FROM users WHERE cpf = '测试值';，确认查询走Index Scan（唯一索引扫描）。若未创建索引，立即执行：

  CREATE UNIQUE INDEX idx_users_cpf ON users(cpf);
  

• 检查Rust代码计时逻辑：确保代码计时仅包含数据库查询耗时，未混入其他业务逻辑开销；确认使用SQLX异步API（如query_one的异步版本），避免同步阻塞拖慢响应。

4. 微调PostgreSQL核心配置 #

• 设置effective_cache_size：设为WSL可用内存的50%-70%（如WSL分配16GB则设为10GB），帮助优化器判断内存缓存情况：

  effective_cache_size = 10GB
  

• 调整work_mem：设置为4MB-8MB，避免排序、哈希等操作使用临时文件：

  work_mem = 4MB
  

内容的提问来源于stack exchange，提问作者rick