PostgreSQL 中文参考文档
🌐 英文原版 官方 ↗

19.4. 资源消耗 #

19.4.1. 内存资源设置
19.4.2. 磁盘与临时文件设置
19.4.3. 内核资源使用
19.4.4. 后台写进程设置
19.4.5. 物理 I/O 控制参数
19.4.6. 工作进程与并行计算池设置

19.4.1. 内存资源设置 #

shared_buffers (integer) #

设置数据库服务器用于共享内存缓冲区池(Shared Buffers)的物理内存容量。默认通常为 128MB,但如果宿主机内核参数无法支持,系统会自动适度调低(由 initdb 确定)。该参数最低不能少于 128KB。然而,为了保障生产环境的高性能,通常需要设置显著高于最低要求的数值。如果指定该值时不带单位,系统默认将其作为以数据块(即 8KB)为单位的块数。该参数只能在服务器启动时设置。

对于配备 1GB 或更高物理内存的独立专用数据库服务器,shared_buffers 推荐的合理起步值为物理内存总量的 25%。某些极端业务场景下分配更高比例同样有效,但由于 PostgreSQL 同样极度依赖操作系统的文件系统缓存(Page Cache),通常将超过 40% 的内存分配给 shared_buffers 往往不如保留给系统缓存更高效。调大 shared_buffers 通常需要同步调大 max_wal_size,以便将海量脏页刷盘过程平滑分摊到更长的检查点周期中。

对于内存小于 1GB 的轻量系统,应当适当调低内存占比,为操作系统及其他进程保留足够的可用内存空间。

huge_pages (enum) #

控制是否为主共享内存区申请巨页(Huge Pages / 大页)。合法取值为 try(默认值)、on 以及 off。该参数只能在服务器启动时设置。当 huge_pages 设置为 try 时,服务器会尝试申请巨页,若申请失败则自动回退到常规内存页。若设置为 on,申请巨页失败将直接阻止服务器启动。若设置为 off,则不请求巨页。巨页的实际生效状态由系统参数 huge_pages_status 指示。

目前该设置仅在 Linux 和 Windows 上受支持。在其他操作系统上,设置为 try 时该设置会被忽略。在 Linux 上,仅当 shared_memory_type 设置为 mmap(默认值)时才支持该功能。

使用巨页可以显著减小内核页表(Page Table)体积,减少 CPU 在内存地址转换与 TLB 缺失上的开销,从而大幅提升高负载下的吞吐性能。有关在 Linux 上配置巨页的更多技术细节,请参阅 Section 18.4.5。

巨页在 Windows 系统中称为“大页面”(Large Pages)。若要使用大页面,必须为运行 PostgreSQL 的 Windows 用户账户分配“锁定内存页”(Lock pages in memory)用户权限。您可以使用 Windows 本地组策略编辑器(gpedit.msc)完成该权限分配。若在命令提示符下以独立前台进程而非 Windows 服务方式启动数据库,命令提示符必须以管理员身份运行,或者禁用用户账户控制(UAC)。因为在启用 UAC 的情况下,常规命令提示符启动时会自动剥夺“锁定内存页”权限。

请注意,该配置仅影响主共享内存区。Linux、FreeBSD 和 Illumos 等操作系统也可以在未经 PostgreSQL 显式请求的情况下,对常规内存分配自动采用大页面(在 Linux 上称为“透明巨页” Transparent Huge Pages,简称 THP)。已知在某些 Linux 内核版本上,THP 会引发 PostgreSQL 偶发严重的内存碎片与性能退化,因此强烈建议禁用系统的透明巨页 THP(这与显式启用数据库自身的 huge_pages 机制完全不同)。

huge_page_size (integer) #

控制通过 huge_pages 启用巨页时的巨页单页物理大小。默认值为 0(0)。当设置为 0 时,将采用操作系统配置的默认巨页尺寸。该参数只能在服务器启动时设置。

现代 64 位服务器硬件架构上常见的物理大页尺寸包括:2MB 和 1GB(Intel 与 AMD x86_64)、16MB 和 16GB(IBM POWER)以及 64kB、2MB、32MB 和 1GB(ARM aarch64)。关于系统配置与支持情况,请参阅 Section 18.4.5。

目前仅在 Linux 系统上支持指定非默认巨页尺寸。

temp_buffers (integer) #

设置每个数据库会话用于临时缓冲区的最大内存容量。这些缓冲区是仅用于访问临时表的会话局部缓冲区。若指定该值时不带单位,则按数据块(即 BLCKSZ 字节,通常为 8kB)为单位计算。默认值为 8MB(8MB)。可以在单个会话内部动态更改此设置,但仅限在当前会话首次使用临时表之前;后续更改该值的尝试对该会话将不再生效。

会话会根据实际负载按需分配临时缓冲区,上限为 temp_buffers 所规定的阈值。在并不需要大量临时缓冲区的会话中设置较大的数值,其开销仅仅是为每个缓冲区预留约 64 字节的缓冲区描述符。然而,一旦某个缓冲区被实际用于数据读写,则会实际占用 8192 字节(或常规的 BLCKSZ 字节)物理内存。

max_prepared_transactions (integer) #

设置允许同时处于“预备”(prepared)状态的最大两阶段提交(2PC)事务数(参见 PREPARE TRANSACTION)。将此参数设置为 0(默认值)将直接禁用两阶段预备事务功能。该参数只能在服务器启动时设置。

如果您不打算使用两阶段提交,应将此参数保持为 0,以防止误创建未提交的孤儿预备事务。如果业务依赖分布式事务或外部事务管理器,通常需要将 max_prepared_transactions 设置为至少与 max_connections 相同的大小,以确保每个会话都能持有一个待处理的预备事务。

在运行只读备用服务器时,必须将该参数设置为与主库相同或更高的数值。否则备库将禁止执行只读查询。

work_mem (integer) #

设置内部查询操作(如排序或哈希表)在向临时磁盘文件写入之前所能直接分配使用的基准最大内存容量。如果不带单位,系统默认将其作为千字节(kB)计算。默认值为 4MB。请注意:一个复杂的复杂查询可能会同时执行多个排序或哈希操作,每个操作在开始向磁盘溢出写临时文件之前通常均被允许消耗多达该参数所规定的内存。此外,多个并发会话可能会同时发起此类操作。因此,系统消耗的总内存可能是 work_mem 的数倍乃至数十倍,在规划调优该数值时必须充分评估并发连接峰值。排序操作常见于 ORDER BY、DISTINCT 与归并连接;哈希表常见于哈希连接、基于哈希的分组聚合、记忆化(Memoize)节点以及 IN 子查询处理。

基于哈希的操作通常比基于排序的等价操作对可用物理内存更加敏感。哈希表的内存上限通过将 work_mem 乘以 hash_mem_multiplier 计算得出。这使得哈希操作能够按比例使用超出基准 work_mem 的专属内存配额。

hash_mem_multiplier (floating point) #

用于计算基于哈希的操作所能消耗的最大物理内存。最终上限由 work_mem 乘以 hash_mem_multiplier 决定。默认值为 2.0,即允许哈希操作使用两倍于基准 work_mem 的物理内存。

在查询频繁溢出写临时磁盘文件的生产环境中,如果单纯调大 work_mem 会引发系统整体内存不足(OOM),可以考虑调大 hash_mem_multiplier。默认设置 2.0 在混合负载下通常非常有效。在 work_mem 已经提高到 40MB 或更高的分析型环境中,将其进一步提高到 2.0 至 8.0 或更大范围通常能显著加速复杂哈希聚合与哈希连接。

maintenance_work_mem (integer) #

指定维护操作(如 VACUUM、CREATE INDEX 以及 ALTER TABLE ADD FOREIGN KEY)所能使用的最大内存容量。若指定该值时不带单位,则按千字节(kB)计算。默认值为 64MB(64MB)。由于单个会话在同一时刻只能执行一个维护操作,且系统中并发运行的维护进程通常极少,因此将该数值设置得显著高于 work_mem 是安全可靠的。更大的设置能够大幅提升清理表垃圾和还原大型数据库备份转储的执行性能。

请注意,当自动清理(autovacuum)运行时,系统最多可能会分配 autovacuum_max_workers 倍于此参数的物理内存,因此切忌将默认值设置得过高。推荐通过单独配置 autovacuum_work_mem 来对自动清理的内存上限进行精准控制。

autovacuum_work_mem (integer) #

指定每个 autovacuum 自动清理工作进程所能消耗的最大物理内存。若指定该值时不带单位,则按千字节计算。默认值为 -1,表示直接继承沿用 maintenance_work_mem 的配置值。该参数对手动执行的常规 VACUUM 毫无影响。该参数只能在 postgresql.conf 文件中或在服务器命令行中设置。

vacuum_buffer_usage_limit (integer) #

指定 VACUUM 和 ANALYZE 命令所采用的 缓冲区访问策略 环形缓冲区大小。设置为 0 将允许操作不受限制地使用任意数量的 shared_buffers。合法的指定大小范围为 128 kB 至 16 GB。如果指定的大小超过 shared_buffers 总量的 1/8,系统会自动将其限制为 1/8。默认值为 2MB。该参数可随时动态设置,并可在执行 VACUUM 和 ANALYZE 时通过传入 BUFFER_USAGE_LIMIT 选项进行单次覆盖。调大该值可以让清理和分析运行得更快,但设置过大可能导致过多常驻热点数据页被逐出共享内存缓冲池。

logical_decoding_work_mem (integer) #

指定逻辑解码在将部分解码变更溢出写入本地磁盘之前所能使用的最大内存容量。这限制了逻辑流复制连接所消耗的内存总量。默认值为 64MB(64MB)。由于每个流复制连接仅占用一个该尺寸的缓冲区,且生产环境中受 max_wal_senders 限制并发连接数通常很少,因此将此数值设置得显著高于 work_mem 是安全可靠的,能够大幅减少已解码变更溢出落盘的 I/O 开销。

commit_timestamp_buffers (integer) #

指定用于缓存 pg_commit_ts(事务提交时间戳,参见 Table 66.1)内容的共享内存大小。若指定该值时不带单位,则按数据块(通常为 8kB)计算。默认值为 0,表示自动设置为 shared_buffers/512(最多 1024 个块,但不少于 16 个块)。该参数只能在服务器启动时设置。

multixact_member_buffers (integer) #

指定用于缓存 pg_multixact/members(元组多事务成员,参见 Table 66.1)内容的共享内存大小。若不带单位,则按数据块计算。默认值为 32 个数据块。该参数只能在服务器启动时设置。

multixact_offset_buffers (integer) #

指定用于缓存 pg_multixact/offsets(元组多事务偏移量,参见 Table 66.1)内容的共享内存大小。若不带单位,按数据块计算。默认值为 16 个数据块。该参数只能在服务器启动时设置。

notify_buffers (integer) #

指定用于缓存 pg_notify(LISTEN/NOTIFY 异步通知队列,参见 Table 66.1)内容的共享内存大小。若不带单位,按数据块计算。默认值为 16 个数据块。该参数只能在服务器启动时设置。

serializable_buffers (integer) #

指定用于缓存 pg_serial(可串行化快照隔离 SSI 提交事务,参见 Table 66.1)内容的共享内存大小。若不带单位,按数据块计算。默认值为 32 个数据块。该参数只能在服务器启动时设置。

subtransaction_buffers (integer) #

指定用于缓存 pg_subtrans(子事务状态,参见 Table 66.1)内容的共享内存大小。若不带单位,按数据块计算。默认值为 0,表示自动设置为 shared_buffers/512(最多 1024 个块,但不少于 16 个块)。该参数只能在服务器启动时设置。

transaction_buffers (integer) #

指定用于缓存 pg_xact(事务提交状态日志 CLOG,参见 Table 66.1)内容的共享内存大小。若不带单位,按数据块计算。默认值为 0,表示自动设置为 shared_buffers/512(最多 1024 个块,但不少于 16 个块)。该参数只能在服务器启动时设置。

max_stack_depth (integer) #

指定服务器执行调用栈的最大安全深度。该参数的理想设置应为操作系统内核强制执行的实际栈空间上限(通过 ulimit -s 或平台对应命令设置)减去大约 1MB 的安全裕量。需要此安全裕量是因为系统并非在每个函数例程中都执行栈深度检查,而仅在关键的潜在递归例程中进行检查。若不带单位,按千字节计算。默认设置为 2MB(2MB),此保守设置极少引发崩溃风险,但对于执行复杂的深度递归表达式或存储过程而言可能偏小。仅超级用户或具有特定权限的角色可以更改此设置。

将 max_stack_depth 设置得高于操作系统内核实际限制,意味着失控的无限递归函数可能会导致单个后端服务进程直接段错误崩溃。在系统能够探测到内核限制的操作系统上,服务器将拒绝将该变量设置为不安全的危险数值。但并非所有平台都提供此信息,因此在配置此数值时务必保持审慎。

shared_memory_type (enum) #

指定服务器用于存放共享缓冲池及其他全局共享数据的主共享内存区域所采用的底层物理实现。合法取值为 mmap(通过 mmap 分配的匿名共享内存)、sysv(通过 shmget 分配的传统 System V 共享内存)以及 windows(Windows 平台共享内存)。并非所有平台都支持全部取值;各平台的第一个受支持选项即为默认值。在任何平台上均不推荐使用已非默认的 sysv 选项,因为支持大内存分配通常需要调整操作系统的内核参数(参见 Section 18.4.1)。该参数只能在服务器启动时设置。

dynamic_shared_memory_type (enum) #

指定服务器应当采用的动态共享内存(DSM)底层机制。合法选项包括 posix(通过 shm_open 分配的 POSIX 共享内存)、sysv(通过 shmget 分配的 System V 共享内存)、windows(Windows 专用共享内存)以及 mmap(使用数据目录下内存映射文件模拟共享内存)。各平台通常以首个受支持选项为默认推荐配置。通常不建议使用 mmap,因为操作系统可能会将脏页反复持久化刷盘从而产生额外 I/O 负担;但当 pg_dynshmem 挂载在内存盘(RAM disk)上或没有其他可用共享内存机制时,它非常实用。该参数只能在服务器启动时设置。

min_dynamic_shared_memory (integer) #

指定在服务器启动时应预先分配的专供并行查询使用的共享内存容量。当该预留区域不足或被高并发并行查询耗尽时,新的并行查询会尝试通过 dynamic_shared_memory_type 配置的机制向操作系统临时申请额外共享内存,这可能会因内存管理系统开销而导致延迟增加。通过 min_dynamic_shared_memory 在启动时分配的内存会受到 huge_pages 配置的影响,并能在支持的系统上更充分地受益于大页机制。默认值为 0(无预分配)。该参数只能在服务器启动时设置。

19.4.2. 磁盘与临时文件设置 #

temp_file_limit (integer) #

指定一个进程可以用于临时文件的最大磁盘空间,例如排序和哈希 临时文件,或者保持打开的游标的存储文件。试图超过这一限制的 事务将被取消。 如果这个值没有指定单位,则以千字节为单位。 -1(默认值)表示没有限制。 只有超级用户和具有相应 SET 权限的用户可以更改这个设置。

这个设置限制一个给定的 PostgreSQL 进程在任一时刻使用的所有临时文件占用的总空间。 需要注意的是,显式临时表所使用的磁盘空间(与查询执行中 幕后使用的临时文件相对)不计入这个限制。

file_copy_method (enum) #

指定用于复制文件的方法。 可用的值是 COPY(默认)和 CLONE(如果操作系统支持可用)。

This parameter affects:

  • CREATE DATABASE ... STRATEGY=FILE_COPY

  • ALTER DATABASE ... SET TABLESPACE ...

CLONE 使用 copy_file_range() (Linux、FreeBSD)或 copyfile (macOS)系统调用,让内核有机会共享磁盘块,或在某些文件系统上 把工作下推到更低的层。

file_extend_method (enum) #

指定在 COPY 等批量操作期间扩展数据文件所用的方法。第一个可用的选项会被 用作默认值,具体取决于操作系统:

  • posix_fallocate(Unix)使用标准的 POSIX 接口分配磁盘空间,但在某些系统上缺失。如果它存在但底层 文件系统不支持,该选项会静默回退到 write_zeros。 据了解,当前版本的 BTRFS 在使用这个选项时会禁用压缩。 在拥有该函数的系统上这是默认值。

  • write_zeros 通过写出零字节块来扩展文件。 在没有 posix_fallocate 函数的系统上这是默认值。

当数据文件的扩展不超过 8 个块时, 总是使用 write_zeros 方法。

max_notify_queue_pages (integer) #

为 NOTIFY / LISTEN 队列指定已分配页面的最大数量。 默认值是 1048576。对于 8 KB 页面,它最多允许消耗 8 GB 磁盘空间。 这个参数只能在服务器启动时设置。

19.4.3. 内核资源使用 #

max_files_per_process (integer) #

设置每个服务器子进程允许同时打开的文件的最大数量;postmaster 中已经打开的文件不计入这个限制。默认是一千个文件。

如果内核在强制执行一个安全的每进程限制,你无需担心这个设置。 但在某些平台上(尤其是大多数 BSD 系统),如果许多进程都试图 打开那么多文件,内核会允许单个进程打开比系统实际能支持的 数量多得多的文件。如果你发现看到 “Too many open files”(打开的文件太多)之类的失败,请尝试减小这个 设置。 这个参数只能在服务器启动时设置。

19.4.4. 后台写进程设置 #

有一个称为后台写进程的独立服务器进程, 它的功能是发出对“脏”(新的或已修改的)共享缓冲区的写操作。 当干净共享缓冲区的数量看起来不足时,后台写进程把一些脏缓冲区 写到文件系统并把它们标记为干净。这降低了处理用户查询的服务器 进程找不到干净缓冲区、从而不得不自己写出脏缓冲区的可能性。 不过,后台写进程确实会导致 I/O 负载的净增加,因为一个被反复 弄脏的页面本来可能每个检查点间隔只写一次,而后台写进程在同一 间隔内随着它被弄脏可能会把它写多次。本小节讨论的参数可用于 按本地需求调优其行为。

bgwriter_delay (integer) #

指定后台写进程各活动轮次之间的延迟。在每一轮中,写进程 会对一定数量的脏缓冲区发出写操作(由以下参数控制)。然后它 睡眠 bgwriter_delay 的时长,如此重复。不过,当缓冲池中没有脏缓冲区时, 无论 bgwriter_delay 是多少, 它都会进入更长的睡眠。 如果这个值没有指定单位,则以毫秒为单位。 默认值是 200 毫秒(200ms)。注意,在某些系统上, 睡眠延迟的有效分辨率是 10 毫秒;把 bgwriter_delay 设置为不是 10 的倍数的值,可能与把它设置为下一个更高的 10 的倍数效果相同。这个参数只能在 postgresql.conf 文件中或服务器命令行上设置。

bgwriter_lru_maxpages (integer) #

在每一轮中,后台写进程写出的缓冲区不会多于这个数量。 把它设置为零会禁用后台写。(注意,由一个单独的专用辅助进程 管理的检查点不受影响。) 默认值是 100 个缓冲区。 这个参数只能在 postgresql.conf 文件中或服务器命令行上设置。

bgwriter_lru_multiplier (floating point) #

每一轮写出的脏缓冲区数量,基于最近几轮中服务器进程需要的 新缓冲区数量。把最近的平均需求乘以 bgwriter_lru_multiplier, 得到对下一轮所需缓冲区数量的估计。脏缓冲区会一直被写出, 直到有这么多的干净、可复用的缓冲区可用。 (不过,每一轮写出的缓冲区不会多于 bgwriter_lru_maxpages。) 因此,1.0 的设置代表一种“刚好及时”的策略, 即恰好写出预计需要的缓冲区数量。 较大的值为需求高峰提供一些缓冲余量,而较小的值则有意把 写操作留给服务器进程去完成。 默认值是 2.0。 这个参数只能在 postgresql.conf 文件中或服务器命令行上设置。

bgwriter_flush_after (integer) #

每当后台写进程写出的数据超过这个数量时,就尝试强制操作系统 把这些写操作下推到底层存储。这样做会限制内核页缓存中脏数据 的数量,降低在检查点结束时发出 fsync 时、或在后台操作系统分更大批次写回数据时发生停顿的可能性。 这通常会显著降低事务延迟,但在某些情况下(特别是工作负载 大于 shared_buffers 但小于操作系统页 缓存时),性能可能会下降。这个设置在某些平台上可能没有 效果。 如果这个值没有指定单位,则以块为单位,即 BLCKSZ 字节,通常为 8kB。 有效范围介于 0(禁用强制写回)与 2MB 之间。在 Linux 上默认为 512kB,其他地方默认为 0。(如果 BLCKSZ 不是 8kB,默认值和最大值会按比例缩放。) 这个参数只能在 postgresql.conf 文件中或服务器命令行上设置。

较小的 bgwriter_lru_maxpages 和 bgwriter_lru_multiplier 值会减少后台写进程 造成的额外 I/O 负载,但会更可能导致服务器进程不得不自己发出 写操作,从而拖慢交互式查询。

19.4.5. 物理 I/O 控制参数 #

backend_flush_after (integer) #

每当单个后端写出的数据超过这个数量时,就尝试强制操作系统把 这些写操作下推到底层存储。这样做会限制内核页缓存中脏数据的 数量,降低在检查点结束时发出 fsync 时、或在后台操作系统分更大批次写回数据时发生停顿的可能性。 这通常会显著降低事务延迟,但在某些情况下(特别是工作负载 大于 shared_buffers 但小于操作系统页 缓存时),性能可能会下降。这个设置在某些平台上可能没有 效果。 如果这个值没有指定单位,则以块为单位,即 BLCKSZ 字节,通常为 8kB。 有效范围介于 0(禁用强制写回)与 2MB 之间。默认值为 0,即不进行强制写回。(如果 BLCKSZ 不是 8kB, 最大值会按比例缩放。)

effective_io_concurrency (integer) #

设置 PostgreSQL 预期能够同时执行的并发存储 I/O 操作数量。提高这个值会增加 任何单个 PostgreSQL 会话尝试并行发起的 I/O 操作数量。允许的范围是 1 到 1000, 或 0 表示禁用异步 I/O 请求的发出。 默认值为 16。

较高的值对延迟较高的存储影响最大,在这类存储上查询否则会 经历明显的 I/O 停顿;此外它对高 IOPS 设备的影响也最大。不必要地设置过高的值可能会增加系统上 所有查询的 I/O 延迟。

在具有预取建议支持的系统上, effective_io_concurrency 还控制预取距离。

对于特定表空间中的表,可以通过设置同名的表空间参数来覆盖 这个值(参见 ALTER TABLESPACE)。

maintenance_io_concurrency (integer) #

与 effective_io_concurrency 类似,但用于代表许多客户端会话执行的维护工作。

默认值为 16。对于特定表空间中的表, 可以通过设置同名的表空间参数来覆盖这个值 (参见 ALTER TABLESPACE)。

io_max_combine_limit (integer) #

控制合并 I/O 的操作中最大的 I/O 尺寸,并静默限制用户可设置的 参数 io_combine_limit。 这个参数只能在服务器启动时设置。 如果这个值没有指定单位,则以块为单位,即 BLCKSZ 字节,通常为 8kB。 可能的最大尺寸取决于操作系统和块大小,但在 Unix 上通常是 1MB,在 Windows 上是 128kB。 默认值为 128kB。

io_combine_limit (integer) #

控制合并 I/O 的操作中最大的 I/O 尺寸。如果设置得高于 io_max_combine_limit 参数, 则会静默改用较低的值,因此可能需要同时调高两者才能增大 I/O 尺寸。 如果这个值没有指定单位,则以块为单位,即 BLCKSZ 字节,通常为 8kB。 可能的最大尺寸取决于操作系统和块大小,但在 Unix 上通常是 1MB,在 Windows 上是 128kB。 默认值为 128kB。

io_max_concurrency (integer) #

控制单个进程能够同时执行的 I/O 操作的最大数量。

-1 的默认设置会基于 shared_buffers 以及最大进程数 (max_connections、autovacuum_worker_slots、max_worker_processes 和 max_wal_senders)选择一个数字, 但不超过 64。

这个参数只能在服务器启动时设置。

io_method (enum) #

选择执行异步 I/O 的方法。 可能的值是:

  • worker(使用工作进程执行异步 I/O)

  • io_uring(使用 io_uring 执行异步 I/O,需要带有 --with-liburing / -Dliburing 的构建)

  • sync (execute asynchronous-eligible I/O synchronously)

The default is worker.

这个参数只能在服务器启动时设置。

io_workers (integer) #

选择要使用的 I/O 工作进程的数量。默认值为 3。这个参数只能在 postgresql.conf 文件中或服务器命令行上设置。

只有当 io_method 被设置为 worker 时才有效。

19.4.6. 工作进程与并行计算池设置 #

max_worker_processes (integer) #

设置集群可以支持的后台进程的最大数量。 这个参数只能在服务器启动时设置。默认值为 8。

在运行只读备用服务器时,必须将该参数设置为与主库相同或更高的数值。否则备库将禁止执行只读查询。

在更改这个值时,请考虑同时调整 max_parallel_workers、 max_parallel_maintenance_workers 和 max_parallel_workers_per_gather。

max_parallel_workers_per_gather (integer) #

设置单个 Gather 或 Gather Merge 节点能够启动的工作进程的最大数量。并行工作进程从由 max_worker_processes 建立的进程池中获取,并受 max_parallel_workers 限制。 注意,请求的工作进程数量在运行时可能实际不可用。如果发生 这种情况,计划将以少于预期的工作进程数量运行,这可能是低效 的。默认值为 2。把这个值设置为 0 会禁用并行查询执行。

注意,并行查询可能比非并行查询消耗多得多的资源,因为每个 工作进程都是一个完全独立的进程,对系统的影响大致相当于一个 额外的用户会话。在为这个设置选择取值时,以及在配置控制资源 使用的其他设置(例如 work_mem)时, 都应当考虑到这一点。诸如 work_mem 之类的资源限制会分别应用于每个 工作进程,这意味着所有进程的总使用量可能比任何单个进程的 正常用量高得多。 例如,一个使用 4 个工作进程的并行查询可能消耗多达 5 倍的 CPU 时间、内存、I/O 带宽等,相比之下一个完全不使用工作进程 的查询则不会。

有关并行查询的更多信息,请参见 Chapter 15。

max_parallel_maintenance_workers (integer) #

设置单个实用程序命令能够启动的并行工作进程的最大数量。 目前,支持使用并行工作进程的并行实用程序命令有:构建 B-tree、GIN 或 BRIN 索引时的 CREATE INDEX, 以及不带 FULL 选项的 VACUUM。 并行工作进程从由 max_worker_processes 建立的进程池中获取,并受 max_parallel_workers 限制。 注意,请求的工作进程数量在运行时可能实际不可用。 如果发生这种情况,实用程序操作将以少于预期的工作进程数量 运行。默认值为 2。把这个值设置为 0 会禁用实用程序命令使用并行工作进程。

注意,并行实用程序命令消耗的内存不应明显多于等效的非并行 操作。这一策略与并行查询不同,后者的资源限制通常按工作进程 分别应用。并行实用程序命令把资源限制 maintenance_work_mem 视为应用于整个实用程序命令的限制,而与并行工作进程的数量 无关。不过,并行实用程序命令仍可能消耗明显更多的 CPU 资源和 I/O 带宽。

max_parallel_workers (integer) #

设置集群可以支持用于并行操作的工作进程的最大数量。默认值为 8。在增大或减小这个值时,请考虑同时调整 max_parallel_maintenance_workers 和 max_parallel_workers_per_gather。 另外请注意,把这个值设置得高于 max_worker_processes 将不会有任何效果,因为并行工作进程是从该设置所建立的工作 进程池中获取的。

parallel_leader_participation (boolean) #

允许领导者进程在 Gather 和 Gather Merge 节点下执行查询计划,而不是等待工作进程。默认值为 on。把这个值设置为 off 会降低工作进程因领导者读取元组的速度不够快而被阻塞的 可能性,但要求领导者进程等待工作进程启动之后才能产生最初的 元组。领导者进程对性能有帮助还是有害,取决于计划类型、 工作进程数量和查询时长。