1. 为什么生产环境PostgreSQL一定要重新调参拿默认配置直接上生产是我见过最多、也最可惜的翻车方式。PostgreSQL安装完成后的postgresql.conf是为“能跑起来”设计的不是为“跑得好”设计的。默认的shared_buffers只有128MBmax_connections只有100work_mem只有4MB这些参数在家用笔记本上开发调试完全没问题可一旦面对生产环境的真实流量性能瓶颈会立刻暴露出来。我印象很深的一次经历接手一套运行了半年的业务系统数据库部署在16核64GB的云主机上但配置几乎全是默认值。业务高峰期一个报表查询能把CPU打到100%连带着正常交易接口都跟着超时。后来把shared_buffers从128MB调到12GBwork_mem从4MB调到16MB什么都没改高峰期CPU直接降到40%以下。这就是调参的价值——不花一分钱硬件成本靠合理配置把数据库潜力释放出来。这篇文章适合谁看如果你正在准备上线PostgreSQL生产实例或者已经上线但总觉得性能不对劲又或者单纯想搞明白postgresql.conf里那些参数到底该怎么填那这篇文章就是给你写的。我会按内存、查询规划、并发连接、WAL与检查点、日志监控这几个维度把生产环境最核心的参数一个一个拆开讲清楚告诉大家默认值是多少、推荐怎么设、为什么这么设、设错了会有什么后果。2. 内存类参数PostgreSQL性能的基石内存参数的设定直接决定了数据库在同等硬件条件下能跑多快。PostgreSQL对内存的管理方式和MySQL不太一样它没有一个大而全的Buffer Pool统一接管而是分为共享内存和进程私有内存两部分。理解这个区分是调好内存参数的前提。2.1 shared_buffers整个数据库的共享缓存池shared_buffers是PostgreSQL最核心的内存参数它是所有后端进程共享的缓存区负责缓存数据页和索引页。当查询请求的数据页不在shared_buffers里时PostgreSQL才会去操作系统磁盘读取。所以这个值越大数据页命中率越高磁盘I/O越少。默认值是128MB这对生产环境来说非常小。推荐设置为物理内存的25%左右。一个简单的估算表格如下物理内存推荐shared_buffers8GB2GB16GB4GB32GB8GB64GB16GB128GB32GB256GB64GB不建议超过这个值为什么不建议超过64GB因为shared_buffers太大后维护脏页列表和缓冲查找结构本身也会消耗大量CPU资源在超高并发场景下可能出现得不偿失的情况。另外PostgreSQL还要依赖操作系统页面缓存来补充我会在后面讲effective_cache_size时详细说明这层配合关系。设置方法很简单在postgresql.conf中修改shared_buffers 16GB这个参数修改后需要重启数据库才能生效。注意如果是Linux系统还要检查内核参数kernel.shmmax和kernel.shmall是否允许分配这么大的共享内存段不过现代PostgreSQL使用mmap分配共享内存这个限制已经不像以前那么严格了但如果系统日志中报出共享内存分配失败的记录还是要回头检查这两个内核参数。2.2 work_mem查询操作的内存上限work_mem是排序、哈希连接、聚合等操作可以使用的私有内存上限。它和shared_buffers完全不同——shared_buffers是所有会话共享的work_mem是每个会话每个操作独立分配的。这就带来了一个很有意思的权衡这个值设小了排序操作会落到磁盘临时文件性能急剧下降设太大了如果有几十个并发会话同时做排序操作内存就可能被一下子吃光。默认值是4MB对于生产环境来说偏小。一个常见经验是把work_mem设为16MB到64MB之间具体要看业务特征。怎么判断当前值够不够执行下面的查询SELECT datname, temp_files, temp_bytes FROM pg_stat_database;如果temp_files字段很大说明排序或哈希操作频繁溢出到磁盘了这时候就需要调大work_mem。反过来如果你观察到系统交换空间swap用量持续上升说明work_mem可能已经超配了。关键点work_mem是乘数效应。一条SQL里可能同时有多个排序和哈希操作每个操作都会申请独立的work_mem。如果系统配置了100个并发连接work_mem设为64MB理论上最坏情况下内存占用就能到6.4GB。所以设定时不能只看单条SQL的舒适度还要考虑并发度这也是为什么生产环境一定要配合连接池使用的原因。2.3 maintenance_work_mem后台维护操作的专属内存这个参数专门控制VACUUM、CREATE INDEX、ALTER TABLE ADD FOREIGN KEY等维护操作的内存上限。默认值是64MB在业务表数据量大、索引复杂的情况下这个值明显不够用。我个人的经验是maintenance_work_mem可以大方一点直接设为1GB到2GB。因为维护操作一般不是高频操作而且它超过阈值后影响的是维护任务本身的磁盘I/O不会像work_mem那样因并发而爆炸。特别是在重建大型索引的时候我用默认64MB试过几百万行的表建索引能等到怀疑人生改成2GB之后速度快了数倍。补充一个细节autovacuum worker进程默认使用的内存是autovacuum_work_mem如果没有单独设置它会沿用maintenance_work_mem的值。如果系统中有大量更新删除操作建议单独设置autovacuum_work_mem避免VACUUM任务把maintenance_work_mem吃满影响手动索引重建等操作的性能。2.4 effective_cache_size告诉优化器系统有多少缓存这个参数很有意思——它不实际分配任何内存而是向PostgreSQL的查询规划器提供“操作系统文件缓存大概有多大”的参考信息。规划器会根据这个数值判断是走索引扫描更划算还是走顺序扫描更划算。默认值是4GB对于现代服务器来说这个值严重偏小。推荐设置为物理内存的50%到75%。继续用shared_buffers的表格举例如果物理内存是32GBshared_buffers设为8GB那么effective_cache_size可以设为20GB左右。这个值加的是操作系统页面缓存的预估量不是共享缓冲区。为什么这个值只影响执行计划的选择因为PostgreSQL的规划器在计算扫描路径代价时会假设可以从系统缓存中免费读取一定量的数据。effective_cache_size越大规划器越倾向于认为“数据已经在缓存里了”从而更青睐索引扫描越小则越倾向顺序扫描。设置不当的典型症状是某个查询明明用索引更快但执行计划却选择了全表扫描往往就是因为effective_cache_size设置得太小了。3. 查询规划器参数让执行计划更聪明这部分参数经常被忽视但它们对查询性能的影响往往比内存参数更直接。规划器用代价模型来比较不同执行路径的开销而代价模型里两个最重要的基础参数就是seq_page_cost和random_page_cost。3.1 seq_page_cost与random_page_cost顺序扫描和随机扫描的代价默认情况下seq_page_cost是1.0random_page_cost是4.0。这组数字的含义是PostgreSQL认为随机读一个页面的开销是顺序读一个页面的4倍。这个假设来自机械硬盘时代——磁头寻道确实非常昂贵。但在SSD时代随机读和顺序读的差距已经大幅缩小4.0这个比例就过于保守了导致规划器经常低估顺序扫描的代价高估索引扫描的代价。对于SSD存储我建议将random_page_cost调整为1.1到1.5之间。已经用了NVMe固态硬盘可以试试1.1这个值会让规划器更积极地选择索引扫描在很多随机点查场景下能明显降低查询延迟。如何验证调整效果拿一个实际查询测试EXPLAIN (ANALYZE, BUFFERS) SELECT * FROM orders WHERE user_id 12345 AND created_at now() - interval 7 days;先看调整前的执行计划再调整参数后对比。如果调整前是Seq Scan调整后变成了Index Scan或Bitmap Index Scan并且查询时间显著下降那说明之前的代价估算确实有问题。3.2 调整代价参数时要注意的坑把random_page_cost调低并不是万能的。如果数据库是传统的机械硬盘或者存储层存在大量随机读写性能差的网络存储强行把这个参数调低可能导致规划器盲目选择索引扫描反而让查询更慢。这种情况下执行计划会频繁出现Bitmap Heap Scan但Block Hit Ratio却偏低说明索引把一个本来可以顺序扫描的查询变成了大量随机小I/O。另外不要单独调整random_page_cost而忽略effective_cache_size。这两个参数是配合使用的effective_cache_size决定“多少数据可以当作已经缓存在内存中”random_page_cost决定“那些没在缓存中的数据随机读取的成本有多高”。只调其中一个执行计划往往会在两种极端之间来回横跳。我的做法是先设置好effective_cache_size再用pgbench或真实业务SQL测试逐步微调random_page_cost。最后固定参数后在同一台机器上跑全量回归确保没有查询劣化。3.3 关于并行查询的几个参数PostgreSQL的并行查询能力从9.6开始逐渐成熟到了15版本已经相当可靠。并行查询相关的核心参数有参数默认值生产建议说明max_parallel_workers_per_gather22~4单个查询最多使用的并行worker数max_parallel_workers84~16整个实例的并行worker上限max_parallel_maintenance_workers24~8维护操作如CREATE INDEX的并行度parallel_setup_cost1000保持默认或调低启动并行worker的代价调低后小表也倾向走并行parallel_tuple_cost0.1保持默认每个tuple在并行worker间传递的代价我踩过的坑在一台只有4核的机器上把max_parallel_workers_per_gather设置成了8结果一个复杂查询直接创建了超过CPU核数的并行进程反而因为上下文切换开销导致查询变慢。后来改成2配合正确的random_page_cost查询性能反而提升了30%以上。并行度真不是越高越好它要和你机器的物理核数匹配。一个简单的原则max_parallel_workers_per_gather不要超过CPU核心数的一半。4. 并发连接与资源管理撑高吞吐但不压垮系统连接管理是最容易被低估的生产环境问题。默认max_connections是100很多人觉得不够用直接改成1000甚至更多。但PostgreSQL是进程模型——每个连接都会对应一个独立的操作系统进程而不是像MySQL那样是线程模型。1000个连接就意味着1000个进程光是上下文切换就能把CPU资源烧光。4.1 max_connections不是越大越好一句话总结我的经验max_connections设得越大的系统通常性能越差。因为每个PostgreSQL连接进程都要分配一定的内存还要参与调度。当活跃连接数远超过CPU核心数时大部分时间都浪费在进程切换上了。一个健康的配置思路是max_connections设置成“业务应用实际并发连接数上限”的2到3倍即可。绝大多数中小型业务系统应用层连接池的并发连接数保持在20~50之间就足够了所以max_connections设置在200到300之间是比较理想的范围。如果你真的需要支持成千上万的客户端连接正确做法不是疯狂调大max_connections而是在应用层和数据库之间加一层连接池中间件如PgBouncer或Pgpool-II。这既避免了进程数爆炸又能更高效地复用会话连接。我在生产环境中的推荐架构是应用连接PgBouncerPgBouncer再维护与PostgreSQL之间的一小撮稳定连接比如20~40个。这样数据库侧的压力完全可控。4.2 连接数耗尽的表现与快速定位当max_connections被耗尽时新连接会报出非常经典的错误FATAL: sorry, too many clients already。这时候很多人第一反应是重启数据库但重启只能暂时清空连接上线几分钟后又会满。我当时排查这个问题时首先用的是这条查询SELECT state, count(*) FROM pg_stat_activity GROUP BY state;如果看到大量state为idle的连接说明应用层连接池没有正确回收连接。再看看wait_event为ClientRead的连接有多少这些通常都是空闲连接。另外state为active的连接如果长时间不结束就要考虑是否有慢查询拖住了连接。把慢SQL找出来优化掉比单纯调大max_connections有效得多。4.3 每个连接的内存预算理解每个连接的内存预算能帮你更科学地决定max_connections。公式大致是每个连接的基础开销大约2MB再加上work_mem的潜在占用。假设work_mem是16MB连接数为300最坏情况下仅排序操作就能消耗约4.8GB内存。如果work_mem是64MB这个数字会变成19.2GB。所以max_connections和work_mem必须联动考虑不能一个一个孤立设置。建议用这个顺序做规划先确定业务需要的并发连接数再计算每个连接可能占用的最大内存最后看物理内存是否扛得住。如果扛不住要么减少连接数要么降低work_mem要么加内存。我在项目中专门做过一次压测把连接从200提升到500work_mem保持32MB内存从16GB一路涨到40GB左右但TPS并没有随之提升反而因为CPU调度开销掉了将近15%。从那以后我对“多开连接”这件事就谨慎了很多。5. WAL与检查点数据安全与性能的平衡术WALWrite-Ahead Logging预写日志是PostgreSQL保证数据一致性的核心机制。每次事务提交时数据修改会先写入WAL日志而不是直接写数据文件。WAL相关的参数调优直接影响两个维度崩溃恢复时的数据安全程度以及写入密集型场景下的性能表现。5.1 wal_level与synchronous_commit安全级别怎么定wal_level默认是replica这个值适合绝大多数生产场景它支持WAL归档和流复制。如果业务用不到这些高级特性可以改成minimal减少一些日志量但一旦后面要搭建从库或做时间点恢复就需要修改配置并重启。我的建议是生产环境直接保持replicanginx for future功能扩展日志量多出的那一部分完全可以接受。synchronous_commit是另一个关键的安全参数它决定事务提交时是否需要等待WAL刷盘完成。默认是on即每个事务提交都要等待WAL fsync安全但慢。如果业务对数据安全性要求极高可以设置成remote_apply以保证备库也应用了WAL后才返回到客户端但那样主库性能会被拖累得非常明显。如果业务允许极短时间的数据丢失例如某些日志系统、非核心告警记录可以设置成off性能提升非常可观——在写入密集场景下TPS能提升1.5到2倍。我的建议核心交易系统绝对不要动synchronous_commit保持on但对于一些可以容忍丢失最近几秒数据的旁路系统off是合理选择。不要一刀切。5.2 max_wal_size与checkpoint_completion_target检查点的节奏控制PostgreSQL的检查点checkpoint机制是把shared_buffers里的脏页刷到磁盘的过程。检查点过于频繁或者每次检查点要刷大量脏页都会导致I/O抖动。max_wal_size就是控制两次检查点之间允许累积的WAL数据量上限。默认max_wal_size是1GB这在生产环境中通常会导致检查点过于频繁。我推荐的标准做法是把max_wal_size设置为3GB到10GB之间具体要看写入量和可接受的恢复时间。检查点越不频繁数据库运行期间的I/O越平稳但崩溃恢复时需要回放的WAL就越多恢复时间越长。checkpoint_completion_target默认是0.5意思是检查点在生成到一半WAL量的时候就“分散”完成刷脏。推荐改为0.9把刷脏过程延伸到下一个检查点到来前尽量长的时间段避免刷脏集中在同一时刻造成I/O尖峰。这两个参数配合起来一个控制检查点的触发频率一个控制刷脏的分散程度共同压低“周期性I/O毛刺”。这是我在生产环境遇到过的真实案例某系统每两个小时就会出现一次数据库I/O延迟陡增监控图显示像是定期发作。后来发现就是检查点导致的——max_wal_size太小检查点频繁触发checkpoint_completion_target又是默认的0.5脏页全堆在检查点后半段突然刷盘。调整成max_wal_size8GB和checkpoint_completion_target0.9之后I/O曲线变得非常平顺再也没看到那种锯齿状尖峰。5.3 WAL日志写盘相关的目录与I/O能力如果业务是写入密集型除了参数配置WAL所在的目录也要单独考虑。PostgreSQL通过wal_levelreplica配合归档模式时WAL文件会不断产生并归档如果与数据文件放在同一块磁盘上写入I/O会相互竞争。生产环境的建议是为pg_wal目录挂载独立的高速存储比如单独的SSD卷并确保WAL磁盘的fsync性能过硬。调优时可以使用pg_test_fsync工具测试当前文件系统的fsync性能选择表现最好的配置。实际部署中把WAL目录分离出来之后我见过不少系统的写入延迟直接下降了一半以上。6. 日志与监控参数生产环境排障的必修课很多生产事故的排查之所以耗时很长不是因为没有监控而是PostgreSQL的日志配置太“勤俭”落下来的有效信息太少。默认配置下慢查询日志是关闭的连接日志也是关闭的真出问题了只能干瞪眼。6.1 慢查询日志参数慢查询日志是排查性能问题最直接的入口。我推荐的组合是logging_collector on log_destination csvlog log_directory log log_filename postgresql-%Y-%m-%d_%H%M%S.log log_statement none log_min_duration_statement 1000 log_line_prefix %t [%p]: [%l-1] user%u,db%d,app%a,client%h log_min_duration_statement1000表示只记录执行时间超过1000毫秒的SQL。初次上线时可以先设置为500ms等系统运行稳定后再调到1000ms甚至2000ms。反过来如果日志量太大不好分析可以配合log_statementnone只记录慢查询避免把所有SQL都打进去。一个我常用的调优小技巧先在低峰期把log_min_duration_statement设为0记录全量SQL半小时然后按执行时间从大到小排序找出最耗时的Top 20有针对性地优化这些语句之后再恢复成慢查询日志模式。这种方式相当于给数据库做一次“SQL体检”对摸清业务负载特征特别有效。6.2 追踪运行中的问题pg_stat_statements如果说慢查询日志是事后排查pg_stat_statements就是事中监控的神器。它是一个扩展需要在postgresql.conf中设置shared_preload_librariespg_stat_statements然后重启数据库再执行CREATE EXTENSION pg_stat_statements。设置完成后它会自动收集所有SQL语句的执行次数、总耗时、平均耗时、缓冲命中等信息是找TOP SQL最快的路径。查询方式SELECT query, calls, total_exec_time, mean_exec_time, rows FROM pg_stat_statements ORDER BY total_exec_time DESC LIMIT 10;uploads里我把pg_stat_statements直接作为生产环境标配。没有它做SQL调优就像闭着眼睛开车。还有一点要提醒pg_stat_statements会占用少量内存来保存SQL文本和统计信息如果SQL种类非常多要检查它的内存占用必要时调整pg_stat_statements.max默认是5000一般业务5000条足够复杂业务可以调到10000。6.3 自动清理参数防止数据库悄悄“发胖”autovacuum是PostgreSQL自动回收死行和更新统计信息的后台任务。默认autovacuum是开启的但生产环境中如果表非常大或者更新删除频率很高默认的触发阈值可能不够。相关参数包括参数默认值生产建议说明autovacuum_max_workers35~10并发清理worker数autovacuum_naptime6030~60两次清理检查间隔秒autovacuum_vacuum_scale_factor0.20.05~0.1表大小达到多少比例时触发清理autovacuum_vacuum_threshold5050最小触发行数autovacuum_analyze_scale_factor0.10.02~0.05统计信息更新触发比例重点是scale_factor。对于一个100GB的大表默认scale_factor是0.2意味着要积累20GB的死行才会触发一次VACUUM。这段时间内表会迅速膨胀查询性能下降非常明显。对于大表建议把scale_factor调低或者干脆在业务表上单独设置ALTER TABLE big_table SET (autovacuum_vacuum_scale_factor 0.02);这样设置后VACUUM会更频繁但更轻量避免一次清理扛太多死行。6.4 日志里最常见的几种警报有了合理配置的日志后还需要知道什么是严重问题。生产环境最常见的日志警报有checkpoint not completing检查点还没刷完下一个就又触发了说明max_wal_size偏小或刷盘I/O太慢worker process ... did not exit normally后端进程异常退出要关注是否有内存不足或崩溃long lock wait长事务锁等待通常意味着业务代码或死锁问题could not stat file ... Permission denied权限问题导致的WAL归档失败这些警报如果日志里频繁出现说明系统已经在亚健康状态了需要立即处理。我以前有一个习惯就是每天上班第一件事先登录服务器grep一下昨天日志里有没有以上模式。虽然现在很多公司都会上监控告警平台但在数据和告警之间有延迟时主动盯日志仍然能提前发现很多隐患。7. 实操从监控数据反推参数配置调参不是拍脑袋。下面展示一套我从零开始为生产实例做配置优化的完整路径供大家直接参考。7.1 第一步摸底现状先收集几个基础信息物理内存大小、CPU核数、磁盘类型HDD还是SSD、当前业务峰值并发数、读写比。然后查看当前配置和运行状态postgres# SELECT name, setting, unit FROM pg_settings WHERE name IN (shared_buffers,work_mem,max_connections);同时跑一下pgbench做一次粗略的基准测试确认当前配置的基准TPS和延迟。这步很有必要否则光凭感觉调之后也不知道究竟有没有变好。7.2 第二步按模板初始化在摸底基础上套一个经过验证的初始模板。就拿一台32GB内存、8核CPU、SSD磁盘的服务器举例shared_buffers 8GB effective_cache_size 24GB work_mem 32MB maintenance_work_mem 1GB max_connections 200 max_parallel_workers_per_gather 4 max_parallel_workers 8 random_page_cost 1.1 seq_page_cost 1.0 max_wal_size 8GB min_wal_size 2GB checkpoint_completion_target 0.9 synchronous_commit on logging_collector on log_min_duration_statement 1000 autovacuum_max_workers 6 autovacuum_vacuum_scale_factor 0.05 shared_preload_libraries pg_stat_statements注意work_mem这里我选了32MB而不是16MB原因是在这个配置下连接数200、最坏情况内存占用约6.4GB加上shared_buffers和其他进程32GB内存还是能稳稳扛住的。如果内存只有16GB同样的模板就要把work_mem下调到16MB、max_connections降到100。7.3 第三步动态调整与验证postgresql.conf中的参数分两类一类是不需要重启的用SELECT pg_reload_conf()即可生效另一类需要重启。内存参数shared_buffers、max_connections、wal_level这类需要重启。work_mem、effective_cache_size、random_page_cost、log_min_duration_statement这些可以动态调整。修改完需要重启的参数后用pg_settings视图确认SELECT name, setting, pending_restart FROM pg_settings WHERE name IN (shared_buffers,max_connections,wal_level);如果pending_restart为t说明参数还没有真正生效。重启后跑一遍业务压测对比调整前后的pgbench数据。我一般盯三个指标TPS、P95延迟、临时文件大小。TPS上去了P95降下来了临时文件几乎没有了说明这次调参是成功的。7.4 第四步持续观察与微调参数设置完不代表工作结束。我建议接下来两周内每天检查这几个视图pg_stat_database中的temp_files、temp_bytes——判断work_mem是否够用pg_stat_user_tables中每个表的n_dead_tup、last_vacuum——判断autovacuum是否有遗漏pg_stat_activity中的长事务和锁等待情况——判断是否出现连接或锁的瓶颈有时候系统性能问题不是参数不对而是分析思维不到位。比如work_mem已经调到128MB了临时文件还是很多。再仔细查发现是某一条SQL用了一个极不合理的联表条件导致每次要排序几GB的数据。这种时候正确的做法是把SQL拆开优化或者加索引而不是继续无脑调大work_mem。记住参数只是将系统资源转化为性能的“调度器”SQL本身的效率才是决定性能的上限。8. 常见问题与排查技巧实录整理了几个生产环境中大家最常踩的坑和排查心得直接按问题给方案。8.1 参数改了不生效这是最高频的问题。改完postgresql.conf后忘了执行SELECT pg_reload_conf()或者执行了但忘了部分参数需要重启。排查思路很简单查询pg_settings中pending_restart字段值为true就是没重启。还有一个容易忽略的点有些系统配置了多个配置文件片段需要在postgresql.conf中用include指令引入。检查pg_settings里的source字段就能确定当前值到底来自哪个文件。8.2 调整后性能反而更差大概率是参数与硬件不匹配。最常见的情况是把random_page_cost调得太低而存储恰好在随机I/O上有短板或者是max_parallel_workers_per_gather调得过高并行开销压过了收益。回退方式把有疑问的参数改回原值逐个变量验证。另一个原因是只调了内存参数但忽略了检查点参数导致内存大大增加后检查点刷脏量也成倍上涨I/O毛刺更严重。所以内存参数和检查点参数一定要配套调整。8.3 连接数耗尽但状态奇怪如果连接数耗尽了但pg_stat_activity里active连接并不多那很可能是idle in transaction状态的事务占用了连接。出现这种情况通常是因为应用代码里开了事务但忘了提交或回滚。这时可以查找SELECT pid, state, duration, query FROM pg_stat_activity WHERE state idle in transaction;对发现的进程做定格分析然后回头修应用代码。从这个角度看连接耗尽未必是数据库配置问题更可能是应用层事务管理问题杀数据库连接只是治标不治本。8.4 重启数据库失败修改shared_buffers或max_connections后重启失败通常有两个原因一是权限问题比如共享内存设置超限二是postgresql.conf语法错误。解决问题的第一步是查看数据库日志文件。如果日志没输出有效信息可以尝试用指定配置文件启动/usr/lib/postgresql/15/bin/postgres -D /etc/postgresql/15/main --config-file/path/to/custom.conf如果启动时报错会直接把错误打到终端上比翻日志快多了。另外强烈建议每次改配置文件之前先备份改完后用pg_ctl reload或restart测试不要在满是业务的时段直接重启。8.5 有哪些参数尽量不要动最后总结几个我不建议轻易改动的参数fsync默认on强行关闭虽然能提升写入性能但一旦操作系统或数据库崩溃数据文件可能损坏到无法恢复的程度full_page_writes默认on改动后崩溃恢复完整性没有保证wal_sync_method在大多数文件系统上默认就是最优选择手动改了可能反而变慢commit_delay和commit_siblings这两个参数配合synchronous_commit使用调不好会显著增加事务提交延迟收益却很小调优的边界在于优先保证数据安全和崩溃恢复能力在此基础上再追求性能上限。为了那点性能提升去牺牲数据安全绝对是得不偿失的。9. 根据个人经验再补几句大实话从10年前的PostgreSQL 9.x时代到现在的16、17版本我看过太多团队把时间花在“调参数”上却始终没有把基础配置和环境摸清。其实PostgreSQL官方文档和EXPLAIN输出的信息量非常大绝大多数性能问题都能通过日志和统计信息定位出方向真正的瓶颈往往不是参数没调好而是SQL写得不好、索引没建对、数据模型设计有问题。参数调整这件事本身需要建立在一个基本认知上每台服务器、每个业务场景的最优配置都不一样照抄任何现成的配置模板都只是起点不是终点。我建议拿到新环境后按照文章里的方法做一轮摸底、一轮设置、两到三周的持续观察才能逐步逼近最适合当前业务的参数组合。最后分享一个小技巧每完成一次重要调优把改动前后的参数快照、性能基线、业务现象都记录下来归档在项目文档里。下一次遇到类似问题时这些记录就是最宝贵的参考——比任何网上的默认配置模板都更贴近你的实际场景。筛选仅为所见内容进行改写。 PostgreSQL生产环境调参实战：从内存到WAL的关键配置
1. 为什么生产环境PostgreSQL一定要重新调参拿默认配置直接上生产是我见过最多、也最可惜的翻车方式。PostgreSQL安装完成后的postgresql.conf是为“能跑起来”设计的不是为“跑得好”设计的。默认的shared_buffers只有128MBmax_connections只有100work_mem只有4MB这些参数在家用笔记本上开发调试完全没问题可一旦面对生产环境的真实流量性能瓶颈会立刻暴露出来。我印象很深的一次经历接手一套运行了半年的业务系统数据库部署在16核64GB的云主机上但配置几乎全是默认值。业务高峰期一个报表查询能把CPU打到100%连带着正常交易接口都跟着超时。后来把shared_buffers从128MB调到12GBwork_mem从4MB调到16MB什么都没改高峰期CPU直接降到40%以下。这就是调参的价值——不花一分钱硬件成本靠合理配置把数据库潜力释放出来。这篇文章适合谁看如果你正在准备上线PostgreSQL生产实例或者已经上线但总觉得性能不对劲又或者单纯想搞明白postgresql.conf里那些参数到底该怎么填那这篇文章就是给你写的。我会按内存、查询规划、并发连接、WAL与检查点、日志监控这几个维度把生产环境最核心的参数一个一个拆开讲清楚告诉大家默认值是多少、推荐怎么设、为什么这么设、设错了会有什么后果。2. 内存类参数PostgreSQL性能的基石内存参数的设定直接决定了数据库在同等硬件条件下能跑多快。PostgreSQL对内存的管理方式和MySQL不太一样它没有一个大而全的Buffer Pool统一接管而是分为共享内存和进程私有内存两部分。理解这个区分是调好内存参数的前提。2.1 shared_buffers整个数据库的共享缓存池shared_buffers是PostgreSQL最核心的内存参数它是所有后端进程共享的缓存区负责缓存数据页和索引页。当查询请求的数据页不在shared_buffers里时PostgreSQL才会去操作系统磁盘读取。所以这个值越大数据页命中率越高磁盘I/O越少。默认值是128MB这对生产环境来说非常小。推荐设置为物理内存的25%左右。一个简单的估算表格如下物理内存推荐shared_buffers8GB2GB16GB4GB32GB8GB64GB16GB128GB32GB256GB64GB不建议超过这个值为什么不建议超过64GB因为shared_buffers太大后维护脏页列表和缓冲查找结构本身也会消耗大量CPU资源在超高并发场景下可能出现得不偿失的情况。另外PostgreSQL还要依赖操作系统页面缓存来补充我会在后面讲effective_cache_size时详细说明这层配合关系。设置方法很简单在postgresql.conf中修改shared_buffers 16GB这个参数修改后需要重启数据库才能生效。注意如果是Linux系统还要检查内核参数kernel.shmmax和kernel.shmall是否允许分配这么大的共享内存段不过现代PostgreSQL使用mmap分配共享内存这个限制已经不像以前那么严格了但如果系统日志中报出共享内存分配失败的记录还是要回头检查这两个内核参数。2.2 work_mem查询操作的内存上限work_mem是排序、哈希连接、聚合等操作可以使用的私有内存上限。它和shared_buffers完全不同——shared_buffers是所有会话共享的work_mem是每个会话每个操作独立分配的。这就带来了一个很有意思的权衡这个值设小了排序操作会落到磁盘临时文件性能急剧下降设太大了如果有几十个并发会话同时做排序操作内存就可能被一下子吃光。默认值是4MB对于生产环境来说偏小。一个常见经验是把work_mem设为16MB到64MB之间具体要看业务特征。怎么判断当前值够不够执行下面的查询SELECT datname, temp_files, temp_bytes FROM pg_stat_database;如果temp_files字段很大说明排序或哈希操作频繁溢出到磁盘了这时候就需要调大work_mem。反过来如果你观察到系统交换空间swap用量持续上升说明work_mem可能已经超配了。关键点work_mem是乘数效应。一条SQL里可能同时有多个排序和哈希操作每个操作都会申请独立的work_mem。如果系统配置了100个并发连接work_mem设为64MB理论上最坏情况下内存占用就能到6.4GB。所以设定时不能只看单条SQL的舒适度还要考虑并发度这也是为什么生产环境一定要配合连接池使用的原因。2.3 maintenance_work_mem后台维护操作的专属内存这个参数专门控制VACUUM、CREATE INDEX、ALTER TABLE ADD FOREIGN KEY等维护操作的内存上限。默认值是64MB在业务表数据量大、索引复杂的情况下这个值明显不够用。我个人的经验是maintenance_work_mem可以大方一点直接设为1GB到2GB。因为维护操作一般不是高频操作而且它超过阈值后影响的是维护任务本身的磁盘I/O不会像work_mem那样因并发而爆炸。特别是在重建大型索引的时候我用默认64MB试过几百万行的表建索引能等到怀疑人生改成2GB之后速度快了数倍。补充一个细节autovacuum worker进程默认使用的内存是autovacuum_work_mem如果没有单独设置它会沿用maintenance_work_mem的值。如果系统中有大量更新删除操作建议单独设置autovacuum_work_mem避免VACUUM任务把maintenance_work_mem吃满影响手动索引重建等操作的性能。2.4 effective_cache_size告诉优化器系统有多少缓存这个参数很有意思——它不实际分配任何内存而是向PostgreSQL的查询规划器提供“操作系统文件缓存大概有多大”的参考信息。规划器会根据这个数值判断是走索引扫描更划算还是走顺序扫描更划算。默认值是4GB对于现代服务器来说这个值严重偏小。推荐设置为物理内存的50%到75%。继续用shared_buffers的表格举例如果物理内存是32GBshared_buffers设为8GB那么effective_cache_size可以设为20GB左右。这个值加的是操作系统页面缓存的预估量不是共享缓冲区。为什么这个值只影响执行计划的选择因为PostgreSQL的规划器在计算扫描路径代价时会假设可以从系统缓存中免费读取一定量的数据。effective_cache_size越大规划器越倾向于认为“数据已经在缓存里了”从而更青睐索引扫描越小则越倾向顺序扫描。设置不当的典型症状是某个查询明明用索引更快但执行计划却选择了全表扫描往往就是因为effective_cache_size设置得太小了。3. 查询规划器参数让执行计划更聪明这部分参数经常被忽视但它们对查询性能的影响往往比内存参数更直接。规划器用代价模型来比较不同执行路径的开销而代价模型里两个最重要的基础参数就是seq_page_cost和random_page_cost。3.1 seq_page_cost与random_page_cost顺序扫描和随机扫描的代价默认情况下seq_page_cost是1.0random_page_cost是4.0。这组数字的含义是PostgreSQL认为随机读一个页面的开销是顺序读一个页面的4倍。这个假设来自机械硬盘时代——磁头寻道确实非常昂贵。但在SSD时代随机读和顺序读的差距已经大幅缩小4.0这个比例就过于保守了导致规划器经常低估顺序扫描的代价高估索引扫描的代价。对于SSD存储我建议将random_page_cost调整为1.1到1.5之间。已经用了NVMe固态硬盘可以试试1.1这个值会让规划器更积极地选择索引扫描在很多随机点查场景下能明显降低查询延迟。如何验证调整效果拿一个实际查询测试EXPLAIN (ANALYZE, BUFFERS) SELECT * FROM orders WHERE user_id 12345 AND created_at now() - interval 7 days;先看调整前的执行计划再调整参数后对比。如果调整前是Seq Scan调整后变成了Index Scan或Bitmap Index Scan并且查询时间显著下降那说明之前的代价估算确实有问题。3.2 调整代价参数时要注意的坑把random_page_cost调低并不是万能的。如果数据库是传统的机械硬盘或者存储层存在大量随机读写性能差的网络存储强行把这个参数调低可能导致规划器盲目选择索引扫描反而让查询更慢。这种情况下执行计划会频繁出现Bitmap Heap Scan但Block Hit Ratio却偏低说明索引把一个本来可以顺序扫描的查询变成了大量随机小I/O。另外不要单独调整random_page_cost而忽略effective_cache_size。这两个参数是配合使用的effective_cache_size决定“多少数据可以当作已经缓存在内存中”random_page_cost决定“那些没在缓存中的数据随机读取的成本有多高”。只调其中一个执行计划往往会在两种极端之间来回横跳。我的做法是先设置好effective_cache_size再用pgbench或真实业务SQL测试逐步微调random_page_cost。最后固定参数后在同一台机器上跑全量回归确保没有查询劣化。3.3 关于并行查询的几个参数PostgreSQL的并行查询能力从9.6开始逐渐成熟到了15版本已经相当可靠。并行查询相关的核心参数有参数默认值生产建议说明max_parallel_workers_per_gather22~4单个查询最多使用的并行worker数max_parallel_workers84~16整个实例的并行worker上限max_parallel_maintenance_workers24~8维护操作如CREATE INDEX的并行度parallel_setup_cost1000保持默认或调低启动并行worker的代价调低后小表也倾向走并行parallel_tuple_cost0.1保持默认每个tuple在并行worker间传递的代价我踩过的坑在一台只有4核的机器上把max_parallel_workers_per_gather设置成了8结果一个复杂查询直接创建了超过CPU核数的并行进程反而因为上下文切换开销导致查询变慢。后来改成2配合正确的random_page_cost查询性能反而提升了30%以上。并行度真不是越高越好它要和你机器的物理核数匹配。一个简单的原则max_parallel_workers_per_gather不要超过CPU核心数的一半。4. 并发连接与资源管理撑高吞吐但不压垮系统连接管理是最容易被低估的生产环境问题。默认max_connections是100很多人觉得不够用直接改成1000甚至更多。但PostgreSQL是进程模型——每个连接都会对应一个独立的操作系统进程而不是像MySQL那样是线程模型。1000个连接就意味着1000个进程光是上下文切换就能把CPU资源烧光。4.1 max_connections不是越大越好一句话总结我的经验max_connections设得越大的系统通常性能越差。因为每个PostgreSQL连接进程都要分配一定的内存还要参与调度。当活跃连接数远超过CPU核心数时大部分时间都浪费在进程切换上了。一个健康的配置思路是max_connections设置成“业务应用实际并发连接数上限”的2到3倍即可。绝大多数中小型业务系统应用层连接池的并发连接数保持在20~50之间就足够了所以max_connections设置在200到300之间是比较理想的范围。如果你真的需要支持成千上万的客户端连接正确做法不是疯狂调大max_connections而是在应用层和数据库之间加一层连接池中间件如PgBouncer或Pgpool-II。这既避免了进程数爆炸又能更高效地复用会话连接。我在生产环境中的推荐架构是应用连接PgBouncerPgBouncer再维护与PostgreSQL之间的一小撮稳定连接比如20~40个。这样数据库侧的压力完全可控。4.2 连接数耗尽的表现与快速定位当max_connections被耗尽时新连接会报出非常经典的错误FATAL: sorry, too many clients already。这时候很多人第一反应是重启数据库但重启只能暂时清空连接上线几分钟后又会满。我当时排查这个问题时首先用的是这条查询SELECT state, count(*) FROM pg_stat_activity GROUP BY state;如果看到大量state为idle的连接说明应用层连接池没有正确回收连接。再看看wait_event为ClientRead的连接有多少这些通常都是空闲连接。另外state为active的连接如果长时间不结束就要考虑是否有慢查询拖住了连接。把慢SQL找出来优化掉比单纯调大max_connections有效得多。4.3 每个连接的内存预算理解每个连接的内存预算能帮你更科学地决定max_connections。公式大致是每个连接的基础开销大约2MB再加上work_mem的潜在占用。假设work_mem是16MB连接数为300最坏情况下仅排序操作就能消耗约4.8GB内存。如果work_mem是64MB这个数字会变成19.2GB。所以max_connections和work_mem必须联动考虑不能一个一个孤立设置。建议用这个顺序做规划先确定业务需要的并发连接数再计算每个连接可能占用的最大内存最后看物理内存是否扛得住。如果扛不住要么减少连接数要么降低work_mem要么加内存。我在项目中专门做过一次压测把连接从200提升到500work_mem保持32MB内存从16GB一路涨到40GB左右但TPS并没有随之提升反而因为CPU调度开销掉了将近15%。从那以后我对“多开连接”这件事就谨慎了很多。5. WAL与检查点数据安全与性能的平衡术WALWrite-Ahead Logging预写日志是PostgreSQL保证数据一致性的核心机制。每次事务提交时数据修改会先写入WAL日志而不是直接写数据文件。WAL相关的参数调优直接影响两个维度崩溃恢复时的数据安全程度以及写入密集型场景下的性能表现。5.1 wal_level与synchronous_commit安全级别怎么定wal_level默认是replica这个值适合绝大多数生产场景它支持WAL归档和流复制。如果业务用不到这些高级特性可以改成minimal减少一些日志量但一旦后面要搭建从库或做时间点恢复就需要修改配置并重启。我的建议是生产环境直接保持replicanginx for future功能扩展日志量多出的那一部分完全可以接受。synchronous_commit是另一个关键的安全参数它决定事务提交时是否需要等待WAL刷盘完成。默认是on即每个事务提交都要等待WAL fsync安全但慢。如果业务对数据安全性要求极高可以设置成remote_apply以保证备库也应用了WAL后才返回到客户端但那样主库性能会被拖累得非常明显。如果业务允许极短时间的数据丢失例如某些日志系统、非核心告警记录可以设置成off性能提升非常可观——在写入密集场景下TPS能提升1.5到2倍。我的建议核心交易系统绝对不要动synchronous_commit保持on但对于一些可以容忍丢失最近几秒数据的旁路系统off是合理选择。不要一刀切。5.2 max_wal_size与checkpoint_completion_target检查点的节奏控制PostgreSQL的检查点checkpoint机制是把shared_buffers里的脏页刷到磁盘的过程。检查点过于频繁或者每次检查点要刷大量脏页都会导致I/O抖动。max_wal_size就是控制两次检查点之间允许累积的WAL数据量上限。默认max_wal_size是1GB这在生产环境中通常会导致检查点过于频繁。我推荐的标准做法是把max_wal_size设置为3GB到10GB之间具体要看写入量和可接受的恢复时间。检查点越不频繁数据库运行期间的I/O越平稳但崩溃恢复时需要回放的WAL就越多恢复时间越长。checkpoint_completion_target默认是0.5意思是检查点在生成到一半WAL量的时候就“分散”完成刷脏。推荐改为0.9把刷脏过程延伸到下一个检查点到来前尽量长的时间段避免刷脏集中在同一时刻造成I/O尖峰。这两个参数配合起来一个控制检查点的触发频率一个控制刷脏的分散程度共同压低“周期性I/O毛刺”。这是我在生产环境遇到过的真实案例某系统每两个小时就会出现一次数据库I/O延迟陡增监控图显示像是定期发作。后来发现就是检查点导致的——max_wal_size太小检查点频繁触发checkpoint_completion_target又是默认的0.5脏页全堆在检查点后半段突然刷盘。调整成max_wal_size8GB和checkpoint_completion_target0.9之后I/O曲线变得非常平顺再也没看到那种锯齿状尖峰。5.3 WAL日志写盘相关的目录与I/O能力如果业务是写入密集型除了参数配置WAL所在的目录也要单独考虑。PostgreSQL通过wal_levelreplica配合归档模式时WAL文件会不断产生并归档如果与数据文件放在同一块磁盘上写入I/O会相互竞争。生产环境的建议是为pg_wal目录挂载独立的高速存储比如单独的SSD卷并确保WAL磁盘的fsync性能过硬。调优时可以使用pg_test_fsync工具测试当前文件系统的fsync性能选择表现最好的配置。实际部署中把WAL目录分离出来之后我见过不少系统的写入延迟直接下降了一半以上。6. 日志与监控参数生产环境排障的必修课很多生产事故的排查之所以耗时很长不是因为没有监控而是PostgreSQL的日志配置太“勤俭”落下来的有效信息太少。默认配置下慢查询日志是关闭的连接日志也是关闭的真出问题了只能干瞪眼。6.1 慢查询日志参数慢查询日志是排查性能问题最直接的入口。我推荐的组合是logging_collector on log_destination csvlog log_directory log log_filename postgresql-%Y-%m-%d_%H%M%S.log log_statement none log_min_duration_statement 1000 log_line_prefix %t [%p]: [%l-1] user%u,db%d,app%a,client%h log_min_duration_statement1000表示只记录执行时间超过1000毫秒的SQL。初次上线时可以先设置为500ms等系统运行稳定后再调到1000ms甚至2000ms。反过来如果日志量太大不好分析可以配合log_statementnone只记录慢查询避免把所有SQL都打进去。一个我常用的调优小技巧先在低峰期把log_min_duration_statement设为0记录全量SQL半小时然后按执行时间从大到小排序找出最耗时的Top 20有针对性地优化这些语句之后再恢复成慢查询日志模式。这种方式相当于给数据库做一次“SQL体检”对摸清业务负载特征特别有效。6.2 追踪运行中的问题pg_stat_statements如果说慢查询日志是事后排查pg_stat_statements就是事中监控的神器。它是一个扩展需要在postgresql.conf中设置shared_preload_librariespg_stat_statements然后重启数据库再执行CREATE EXTENSION pg_stat_statements。设置完成后它会自动收集所有SQL语句的执行次数、总耗时、平均耗时、缓冲命中等信息是找TOP SQL最快的路径。查询方式SELECT query, calls, total_exec_time, mean_exec_time, rows FROM pg_stat_statements ORDER BY total_exec_time DESC LIMIT 10;uploads里我把pg_stat_statements直接作为生产环境标配。没有它做SQL调优就像闭着眼睛开车。还有一点要提醒pg_stat_statements会占用少量内存来保存SQL文本和统计信息如果SQL种类非常多要检查它的内存占用必要时调整pg_stat_statements.max默认是5000一般业务5000条足够复杂业务可以调到10000。6.3 自动清理参数防止数据库悄悄“发胖”autovacuum是PostgreSQL自动回收死行和更新统计信息的后台任务。默认autovacuum是开启的但生产环境中如果表非常大或者更新删除频率很高默认的触发阈值可能不够。相关参数包括参数默认值生产建议说明autovacuum_max_workers35~10并发清理worker数autovacuum_naptime6030~60两次清理检查间隔秒autovacuum_vacuum_scale_factor0.20.05~0.1表大小达到多少比例时触发清理autovacuum_vacuum_threshold5050最小触发行数autovacuum_analyze_scale_factor0.10.02~0.05统计信息更新触发比例重点是scale_factor。对于一个100GB的大表默认scale_factor是0.2意味着要积累20GB的死行才会触发一次VACUUM。这段时间内表会迅速膨胀查询性能下降非常明显。对于大表建议把scale_factor调低或者干脆在业务表上单独设置ALTER TABLE big_table SET (autovacuum_vacuum_scale_factor 0.02);这样设置后VACUUM会更频繁但更轻量避免一次清理扛太多死行。6.4 日志里最常见的几种警报有了合理配置的日志后还需要知道什么是严重问题。生产环境最常见的日志警报有checkpoint not completing检查点还没刷完下一个就又触发了说明max_wal_size偏小或刷盘I/O太慢worker process ... did not exit normally后端进程异常退出要关注是否有内存不足或崩溃long lock wait长事务锁等待通常意味着业务代码或死锁问题could not stat file ... Permission denied权限问题导致的WAL归档失败这些警报如果日志里频繁出现说明系统已经在亚健康状态了需要立即处理。我以前有一个习惯就是每天上班第一件事先登录服务器grep一下昨天日志里有没有以上模式。虽然现在很多公司都会上监控告警平台但在数据和告警之间有延迟时主动盯日志仍然能提前发现很多隐患。7. 实操从监控数据反推参数配置调参不是拍脑袋。下面展示一套我从零开始为生产实例做配置优化的完整路径供大家直接参考。7.1 第一步摸底现状先收集几个基础信息物理内存大小、CPU核数、磁盘类型HDD还是SSD、当前业务峰值并发数、读写比。然后查看当前配置和运行状态postgres# SELECT name, setting, unit FROM pg_settings WHERE name IN (shared_buffers,work_mem,max_connections);同时跑一下pgbench做一次粗略的基准测试确认当前配置的基准TPS和延迟。这步很有必要否则光凭感觉调之后也不知道究竟有没有变好。7.2 第二步按模板初始化在摸底基础上套一个经过验证的初始模板。就拿一台32GB内存、8核CPU、SSD磁盘的服务器举例shared_buffers 8GB effective_cache_size 24GB work_mem 32MB maintenance_work_mem 1GB max_connections 200 max_parallel_workers_per_gather 4 max_parallel_workers 8 random_page_cost 1.1 seq_page_cost 1.0 max_wal_size 8GB min_wal_size 2GB checkpoint_completion_target 0.9 synchronous_commit on logging_collector on log_min_duration_statement 1000 autovacuum_max_workers 6 autovacuum_vacuum_scale_factor 0.05 shared_preload_libraries pg_stat_statements注意work_mem这里我选了32MB而不是16MB原因是在这个配置下连接数200、最坏情况内存占用约6.4GB加上shared_buffers和其他进程32GB内存还是能稳稳扛住的。如果内存只有16GB同样的模板就要把work_mem下调到16MB、max_connections降到100。7.3 第三步动态调整与验证postgresql.conf中的参数分两类一类是不需要重启的用SELECT pg_reload_conf()即可生效另一类需要重启。内存参数shared_buffers、max_connections、wal_level这类需要重启。work_mem、effective_cache_size、random_page_cost、log_min_duration_statement这些可以动态调整。修改完需要重启的参数后用pg_settings视图确认SELECT name, setting, pending_restart FROM pg_settings WHERE name IN (shared_buffers,max_connections,wal_level);如果pending_restart为t说明参数还没有真正生效。重启后跑一遍业务压测对比调整前后的pgbench数据。我一般盯三个指标TPS、P95延迟、临时文件大小。TPS上去了P95降下来了临时文件几乎没有了说明这次调参是成功的。7.4 第四步持续观察与微调参数设置完不代表工作结束。我建议接下来两周内每天检查这几个视图pg_stat_database中的temp_files、temp_bytes——判断work_mem是否够用pg_stat_user_tables中每个表的n_dead_tup、last_vacuum——判断autovacuum是否有遗漏pg_stat_activity中的长事务和锁等待情况——判断是否出现连接或锁的瓶颈有时候系统性能问题不是参数不对而是分析思维不到位。比如work_mem已经调到128MB了临时文件还是很多。再仔细查发现是某一条SQL用了一个极不合理的联表条件导致每次要排序几GB的数据。这种时候正确的做法是把SQL拆开优化或者加索引而不是继续无脑调大work_mem。记住参数只是将系统资源转化为性能的“调度器”SQL本身的效率才是决定性能的上限。8. 常见问题与排查技巧实录整理了几个生产环境中大家最常踩的坑和排查心得直接按问题给方案。8.1 参数改了不生效这是最高频的问题。改完postgresql.conf后忘了执行SELECT pg_reload_conf()或者执行了但忘了部分参数需要重启。排查思路很简单查询pg_settings中pending_restart字段值为true就是没重启。还有一个容易忽略的点有些系统配置了多个配置文件片段需要在postgresql.conf中用include指令引入。检查pg_settings里的source字段就能确定当前值到底来自哪个文件。8.2 调整后性能反而更差大概率是参数与硬件不匹配。最常见的情况是把random_page_cost调得太低而存储恰好在随机I/O上有短板或者是max_parallel_workers_per_gather调得过高并行开销压过了收益。回退方式把有疑问的参数改回原值逐个变量验证。另一个原因是只调了内存参数但忽略了检查点参数导致内存大大增加后检查点刷脏量也成倍上涨I/O毛刺更严重。所以内存参数和检查点参数一定要配套调整。8.3 连接数耗尽但状态奇怪如果连接数耗尽了但pg_stat_activity里active连接并不多那很可能是idle in transaction状态的事务占用了连接。出现这种情况通常是因为应用代码里开了事务但忘了提交或回滚。这时可以查找SELECT pid, state, duration, query FROM pg_stat_activity WHERE state idle in transaction;对发现的进程做定格分析然后回头修应用代码。从这个角度看连接耗尽未必是数据库配置问题更可能是应用层事务管理问题杀数据库连接只是治标不治本。8.4 重启数据库失败修改shared_buffers或max_connections后重启失败通常有两个原因一是权限问题比如共享内存设置超限二是postgresql.conf语法错误。解决问题的第一步是查看数据库日志文件。如果日志没输出有效信息可以尝试用指定配置文件启动/usr/lib/postgresql/15/bin/postgres -D /etc/postgresql/15/main --config-file/path/to/custom.conf如果启动时报错会直接把错误打到终端上比翻日志快多了。另外强烈建议每次改配置文件之前先备份改完后用pg_ctl reload或restart测试不要在满是业务的时段直接重启。8.5 有哪些参数尽量不要动最后总结几个我不建议轻易改动的参数fsync默认on强行关闭虽然能提升写入性能但一旦操作系统或数据库崩溃数据文件可能损坏到无法恢复的程度full_page_writes默认on改动后崩溃恢复完整性没有保证wal_sync_method在大多数文件系统上默认就是最优选择手动改了可能反而变慢commit_delay和commit_siblings这两个参数配合synchronous_commit使用调不好会显著增加事务提交延迟收益却很小调优的边界在于优先保证数据安全和崩溃恢复能力在此基础上再追求性能上限。为了那点性能提升去牺牲数据安全绝对是得不偿失的。9. 根据个人经验再补几句大实话从10年前的PostgreSQL 9.x时代到现在的16、17版本我看过太多团队把时间花在“调参数”上却始终没有把基础配置和环境摸清。其实PostgreSQL官方文档和EXPLAIN输出的信息量非常大绝大多数性能问题都能通过日志和统计信息定位出方向真正的瓶颈往往不是参数没调好而是SQL写得不好、索引没建对、数据模型设计有问题。参数调整这件事本身需要建立在一个基本认知上每台服务器、每个业务场景的最优配置都不一样照抄任何现成的配置模板都只是起点不是终点。我建议拿到新环境后按照文章里的方法做一轮摸底、一轮设置、两到三周的持续观察才能逐步逼近最适合当前业务的参数组合。最后分享一个小技巧每完成一次重要调优把改动前后的参数快照、性能基线、业务现象都记录下来归档在项目文档里。下一次遇到类似问题时这些记录就是最宝贵的参考——比任何网上的默认配置模板都更贴近你的实际场景。筛选仅为所见内容进行改写。