pgsql.cc 提供对 postgresql.org 官网内容的中文翻译,由 Pigsty 团队维护。
shared_buffers (integer) #设置数据库服务器用于共享内存缓冲区的内存量。默认值通常为 128 兆字节(128MB),但如果内核设置不支持,则可能更小(在 initdb 期间确定)。此设置必须至少为 128 千字节。(BLCKSZ 的非默认值会改变该最小值。)不过,要获得良好性能,通常需要远高于该最小值的设置。此参数只能在服务器启动时设置。
如果专用数据库服务器具有 1GB 或更多内存,shared_buffers 的合理初始值是系统内存的 25%。对于某些工作负载,将 shared_buffers 设得很大也有效,但由于 PostgreSQL 同时依赖操作系统缓存,将超过 40% 的内存分配给 shared_buffers 不太可能比更小的值效果更好。将 shared_buffers 设得更大时,通常还需要相应增加 max_wal_size,以便将大量新数据或已修改数据的写入过程分散到更长的时间内。
对于内存少于 1GB 的系统,适合使用更小的内存比例,以便为操作系统留出足够空间。另外,在 Windows 上,很大的 shared_buffers 设置并不那么有效。让该设置保持相对较低、更多地使用操作系统缓存,可能得到更好的结果。Windows 系统上 shared_buffers 的有效范围通常是从 64MB 到 512MB。
huge_pages (enum) #启用或禁用巨型内存页。有效值为 try(默认值)、on 和 off。
目前只有 Linux 支持此特性。在其他系统上,设置为 try 时会忽略此设置。
使用巨型页可缩小页表,减少内存管理所需的 CPU 时间,从而提高性能。更多信息参见 第 18.4.5 节。
将 huge_pages 设为 try 时,服务器会尝试使用巨型页,失败后则回退到普通内存分配。设为 on 时,使用巨型页失败会导致服务器无法启动。设为 off 时,不使用巨型页。
temp_buffers (integer) #设置每个数据库会话使用的临时缓冲区的最大数量。这些是会话本地的缓冲区,仅用于访问临时表。默认值为 8 兆字节(8MB)。可以在单个会话内更改此设置,但必须在该会话首次使用临时表之前更改;此后尝试更改该值,对该会话不会产生影响。
会话会按需分配临时缓冲区,上限为 temp_buffers。对于实际不需要很多临时缓冲区的会话,将此参数设得较大时,开销仅为 temp_buffers 每增加一就多分配一个缓冲区描述符,约为 64 字节。不过,如果实际使用了某个缓冲区,还会为它额外消耗 8192 字节(一般而言为 BLCKSZ 字节)。
max_prepared_transactions (integer) #设置可同时处于“预备”状态的事务的最大数量(见 PREPARE TRANSACTION)。将此参数设为零(默认值)会禁用预备事务功能。此参数只能在服务器启动时设置。
如果不打算使用预备事务,应将此参数设为零,以防意外创建预备事务。如果使用预备事务,通常应将 max_prepared_transactions 设为不小于 max_connections 的值,以便每个会话都能有一个待处理的预备事务。
运行备库时,必须将此参数设为与主库相同或更大的值。否则,备库上将不允许执行查询。
work_mem (integer) #指定内部排序操作和哈希表在写入临时磁盘文件之前可使用的内存量。默认值为 4 兆字节(4MB)。请注意,复杂查询可能并行执行多个排序或哈希操作,每个操作在开始向临时文件写入数据之前,都可以使用此值指定的内存量。此外,多个正在运行的会话也可能并发执行此类操作。因此,使用的总内存量可能是 work_mem 值的数倍;选择此值时必须考虑这一点。排序操作用于 ORDER BY、DISTINCT 和归并连接。哈希表用于哈希连接、基于哈希的聚合、以及基于哈希的 IN 子查询处理。
maintenance_work_mem (integer) #指定维护操作(如 VACUUM、CREATE INDEX 和 ALTER TABLE ADD FOREIGN KEY)可使用的最大内存量。默认值为 64 兆字节(64MB)。由于一个数据库会话一次只能执行一个此类操作,而一个数据库系统通常也不会并发运行很多此类操作,因此可以安全地将该值设得远大于 work_mem。更大的设置可能改善清理和恢复数据库转储的性能。
注意,自动清理运行时,最多可能分配此内存量的 autovacuum_max_workers 倍,因此不要将默认值设得过高。单独设置 autovacuum_work_mem 可能有助于控制这一点。
注意,在收集死元组标识符时,VACUUM 最多只能使用 1GB 内存。
replacement_sort_tuples (integer) #当待排序的元组数小于此数值时,排序会使用置换选择而非快速排序来产生第一个输出有序段。 在内存受限的环境中,如果较大排序操作的输入元组具有很强的物理顺序与逻辑顺序相关性,这可能很有用。 请注意,这不包括具有反向相关性的输入元组。 置换选择算法可能产生一个无需归并的长有序段,而默认策略会产生许多必须归并才能得到最终排序输出的有序段。 这可能让排序操作更快完成。
默认值为 150,000 个元组。请注意,更高的值通常也不会让效果好很多,甚至可能适得其反, 因为优先队列对可用 CPU 缓存的大小很敏感,而默认策略使用缓存无关算法对有序段进行排序。 这一特性让默认排序策略能够自动、透明地有效利用可用 CPU 缓存。
将maintenance_work_mem设置为默认值,通常会使工具命令的外部排序(例如CREATE INDEX构建 B-树索引时使用的排序) 完全不会使用置换选择排序,除非输入元组相当宽。
autovacuum_work_mem (integer) #指定每个自动清理工作进程可使用的最大内存量。默认值为 -1,表示改用 maintenance_work_mem 的值。该设置不影响其他上下文中运行的 VACUUM 的行为。此参数只能在 postgresql.conf 文件中或服务器命令行上设置。
在收集死元组标识符时,自动清理最多只能使用 1GB 内存,因此将 autovacuum_work_mem 设得更高,不会影响自动清理扫描表时能收集的死元组数量。
max_stack_depth (integer) #指定服务器执行栈的最大安全深度。此参数的理想设置是由内核强制执行的实际栈大小限制 (如由ulimit -s或本地等效设置),减去大约一兆字节的安全余量。 需要安全余量是因为服务器中并非每个例程都检查栈深度,而只在可能递归的关键例程(如表达式求值)中检查。 默认设置为两兆字节(2MB), 这是保守且不太可能引起崩溃的小值。但是,这可能太小,无法执行复杂函数。 只有超级用户才能更改此设置。
把max_stack_depth参数设置得高于实际的内核限制将意味着一个失控的递归函数可能会导致一个独立的后端进程崩溃。 在PostgreSQL能够检测内核限制的平台上, 服务器将不允许把这个参数设置为一个不安全的值。不过,并非所有平台都能提供该信息,所以我们还是建议你在选择值时要小心。
dynamic_shared_memory_type (enum) #指定服务器应使用的动态共享内存实现。可选值为 posix(使用 shm_open 分配的 POSIX 共享内存)、sysv(通过 shmget 分配的 System V 共享内存)、windows(Windows 共享内存)、mmap(使用存放在数据目录中的内存映射文件模拟共享内存),以及 none(禁用此功能)。并非所有平台都支持所有值;第一个受支持的选项是该平台的默认值。mmap 不是任何平台的默认选项,通常不建议使用,因为操作系统可能会反复将修改过的页面写回磁盘,增加系统 I/O 负载;不过,在调试、将 pg_dynshmem 目录存放在 RAM 磁盘上,或其他共享内存设施不可用时,它可能有用。
temp_file_limit (integer) #指定一个进程可用于临时文件的最大磁盘空间,例如排序和哈希临时文件,或保留游标的存储文件。尝试超过此限制的事务将被取消。该值以千字节为单位。-1(默认值)表示没有限制。只有超级用户才能更改此设置。
此设置限制单个 PostgreSQL 进程在任意时刻使用的所有临时文件的总空间。需要注意,显式临时表所用的磁盘空间不计入该上限;计入的是查询执行过程中内部使用的临时文件。
max_files_per_process (integer) #设置每个服务器子进程允许同时打开的最大文件数量。默认值为一千个文件。如果内核强制实施了安全的每进程上限,就不必担心此设置。但在某些平台上(尤其是大多数 BSD 系统),内核允许单个进程打开的文件数量很大,如果很多进程都尝试打开这么多文件,就会远超系统实际能够支持的总量。如果遇到 “Too many open files”(打开的文件过多)错误,可尝试减小此设置。此参数只能在服务器启动时设置。
执行 VACUUM 和 ANALYZE 命令期间,系统维护一个内部计数器,记录已执行的各种 I/O 操作的估算代价。 当累计代价达到上限(由 vacuum_cost_limit 指定)时,执行该操作的进程会休眠一小段时间,时长由 vacuum_cost_delay 指定。 随后重置计数器并继续执行。
此功能让管理员能够降低这些命令对并发数据库活动的 I/O 影响。在许多情况下,VACUUM 和 ANALYZE 等维护命令是否快速完成并不重要, 但避免它们显著干扰系统执行其他数据库操作的能力通常很重要。基于代价的清理延迟为管理员提供了实现这一点的方法。
对于手动执行的 VACUUM 命令,此功能默认禁用。要启用它,将 vacuum_cost_delay 变量设为非零值。
vacuum_cost_delay (integer) #超过代价上限后,进程将休眠的时长,单位为毫秒。默认值为零,表示禁用基于代价的清理延迟功能。正值会启用基于代价的清理。注意,在许多系统上,休眠延迟的有效分辨率为 10 毫秒;将 vacuum_cost_delay 设为不是 10 的倍数的值,可能与将它设为下一个更大的 10 的倍数效果相同。
使用基于代价的清理时,vacuum_cost_delay 的合适值通常较小,例如 10 或 20 毫秒。调整清理的资源消耗时,最好更改其他清理代价参数。
vacuum_cost_page_hit (integer) #清理在共享缓冲区缓存中找到的缓冲区时所计入的估算代价。它表示锁定缓冲池、查找共享哈希表和扫描页内容的代价。默认值为 1。
vacuum_cost_page_miss (integer) #清理必须从磁盘读取的缓冲区时所计入的估算代价。它表示锁定缓冲池、查找共享哈希表、从磁盘读取所需数据块并扫描其内容所需的工作量。默认值为 10。
vacuum_cost_page_dirty (integer) #清理操作修改原本干净的数据块时所计入的估算代价。它表示再次将脏块刷盘所需的额外 I/O。默认值为 20。
vacuum_cost_limit (integer) #会使清理进程休眠的累计代价。默认值为 200。
某些操作持有关键的锁,因此应尽快完成。这些操作期间不会发生基于代价的清理延迟,所以累计代价可能远超指定上限。 为避免此时出现无益的长时间延迟,实际延迟按 vacuum_cost_delay * accumulated_balance / vacuum_cost_limit 计算, 但最大不超过 vacuum_cost_delay * 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) #每当后台写入器写出的数据超过bgwriter_flush_after 字节时,就尝试强制操作系统将这些写操作发往底层存储。这样可以限制内核页缓存中的脏数据量,降低在检查点结束时调用 fsync,或操作系统在后台以较大批次写回数据时发生停顿的可能性。通常,这能大幅降低事务延迟,但在某些情况下性能可能下降,尤其是工作负载大于 shared_buffers 而小于操作系统页缓存时。此设置在某些平台上可能没有效果。有效范围为 0(禁用强制写回)至 2MB。Linux 上的默认值为 512kB,其他平台为 0。(如果 BLCKSZ 不是 8kB,默认值和最大值将按比例变化。)此参数只能在 postgresql.conf 文件中或服务器命令行上设置。
较小的 bgwriter_lru_maxpages 和 bgwriter_lru_multiplier 可以降低后台写入器造成的额外 I/O 负载, 但也会增加服务器进程必须自行发出写操作的可能性,从而延迟交互式查询。
effective_io_concurrency (integer) #设置 PostgreSQL 预期可以同时执行的并发磁盘 I/O 操作数量。提高此值会增加单个 PostgreSQL 会话尝试并行发起的 I/O 操作数量。允许的范围为 1 至 1000,或设为零以禁用异步 I/O 请求。目前,此设置仅影响位图堆扫描。
对于磁盘,可以将为数据库提供存储的 RAID 0 条带或 RAID 1 镜像中的独立磁盘数量作为合理初始值。(对于 RAID 5,不应计入校验盘。)不过,如果数据库经常忙于执行并发会话发出的多个查询,较小的值可能就足以使磁盘阵列保持繁忙。超过使磁盘保持繁忙所需的值只会增加 CPU 开销。SSD 和其他基于内存的存储通常可以处理大量并发请求,因此最佳值可能达到数百。
异步 I/O 依赖于有效的 posix_fadvise 函数,而某些操作系统缺少此函数。如果该函数不存在,将此参数设为任何非零值都会报错。在某些操作系统(如 Solaris)上,该函数虽然存在,却实际上不做任何事情。
支持此功能的系统上默认值为 1,其他系统为 0。对于位于特定表空间中的表,可以通过设置同名的表空间参数覆盖此值(见 ALTER TABLESPACE)。
max_worker_processes (integer) #设置系统能够支持的后台进程的最大数量。此参数只能在服务器启动时设置。默认值为 8。
运行备库时,必须将此参数设为与主库相同或更大的值。否则,备库上将不允许执行查询。
max_parallel_workers_per_gather (integer) #设置单个 Gather 节点能够启动的工作进程的最大数量。并行工作进程取自 max_worker_processes 建立的进程池。注意,运行时实际可用的工作进程可能不足请求的数量。此时,计划会使用少于预期的工作进程运行,效率可能较低。设为 0(即默认值)会禁用并行查询执行。
注意,并行查询消耗的资源可能远多于非并行查询,因为每个工作进程都是完全独立的进程,对系统的影响大致相当于额外增加一个用户会话。选择此设置的值,以及配置其他控制资源使用的设置(如 work_mem)时,都应考虑这一点。work_mem 等资源限制分别应用于每个工作进程,因此所有进程的总资源用量可能远高于单个进程通常的用量。例如,使用 4 个工作进程的并行查询,其 CPU 时间、内存、I/O 带宽等用量可能达到完全不使用工作进程的查询的 5 倍。
并行查询的更多信息参见 第 15 章。
backend_flush_after (integer) #每当单个后端写出的数据超过backend_flush_after 字节时,就尝试强制操作系统将这些写操作发往底层存储。这样可以限制内核页缓存中的脏数据量,降低在检查点结束时调用 fsync,或操作系统在后台以较大批次写回数据时发生停顿的可能性。通常,这能大幅降低事务延迟,但在某些情况下性能可能下降,尤其是工作负载大于 shared_buffers 而小于操作系统页缓存时。此设置在某些平台上可能没有效果。有效范围为 0(禁用强制写回)至 2MB。默认值为 0,即不强制写回。(如果 BLCKSZ 不是 8kB,最大值将按比例变化。)
old_snapshot_threshold (integer) #设置快照在使用时不会发生 snapshot too old 错误的最短可用时间。此参数只能在服务器启动时设置。
超过该阈值后,旧数据可以被清理掉。这有助于在快照长期保持使用时防止膨胀。为了避免因清理本应对该快照可见的数据而得到错误结果,当快照年龄超过该阈值,且该快照被用于读取自其建立以来已被修改过的页面时,就会报错。
值 -1 会禁用此功能,也是默认值。对生产环境而言,有用的取值大概从几个小时到几天不等。此设置会被强制调整为分钟粒度;较小的值(例如 0 或 1min)之所以被允许,只是因为它们有时可用于测试。虽然允许设置到 60d 这么高,但在许多工作负载中,严重膨胀或事务 ID 回卷可能会在更短时间内发生。
启用此功能后,关系末尾释放出来的空间不能返还给操作系统,因为那样可能会移除检测 snapshot too old 条件所需的信息。分配给某个关系的全部空间仍归属于该关系,只能在该关系内重用,除非显式释放(例如使用 VACUUM FULL)。
此设置不保证在任何特定情况下都一定会报错。实际上,如果仍能从某个对象(例如已物化结果集的游标)生成正确结果,那么即使被引用表中的底层行已被清理掉,也不会报错。有些表不能安全地提前清理,因此不受此设置影响。例如系统目录,以及任何带有哈希索引的表。对于这类表,此设置既不会减少膨胀,也不会在扫描时引入 snapshot too old 错误的可能性。
译文有误、术语不当或页面显示问题,请到译文仓库 pgsty/pgdoc 报告译文问题。 英文原文本身的问题,请在当前版本的对应页面向上游反馈;上游不再修订已结束维护的版本。