目录
一 文件位置
data_directory (string)
config_file (string)
hba_file (string)
ident_file (string)
external_pid_file (string)
二 连接和认证
1 连接设置
listen_addresses (string)
port (integer)
max_connections (integer)
superuser_reserved_connections (integer)
unix_socket_directories (string)
unix_socket_group (string)
unix_socket_permissions (integer)
bonjour (boolean)
bonjour_name (string)
tcp_keepalives_idle (integer)
tcp_keepalives_interval (integer)
tcp_keepalives_count (integer)
tcp_user_timeout (integer)
2 安全和认证
authentication_timeout (integer)
password_encryption (enum)
krb_server_keyfile (string)
krb_caseins_users (boolean)
db_user_namespace (boolean)
3 SSL
ssl (boolean)
ssl_ca_file (string)
ssl_cert_file (string)
ssl_crl_file (string)
ssl_key_file (string)
ssl_ciphers (string)
ssl_prefer_server_ciphers (boolean)
ssl_ecdh_curve (string)
ssl_min_protocol_version (enum)
ssl_max_protocol_version (enum)
ssl_dh_params_file (string)
ssl_passphrase_command (string)
ssl_passphrase_command_supports_reload (boolean)
三 资源消耗
1. 内存
huge_pages (enum)
temp_buffers (integer)
max_prepared_transactions (integer)
work_mem (integer)
hash_mem_multiplier (浮点)
maintenance_work_mem (integer)
autovacuum_work_mem (integer)
logical_decoding_work_mem (integer)
max_stack_depth (integer)
2. 磁盘
temp_file_limit (integer)
3. 内核资源使用
max_files_per_process (integer)
4. 基于代价的清理延迟
5. 后台写入器
bgwriter_delay (integer)
bgwriter_lru_maxpages (integer)
bgwriter_lru_multiplier (floating point)
bgwriter_flush_after (integer)
6. 异步行为
effective_io_concurrency (integer)
maintenance_io_concurrency (integer)
max_worker_processes (integer)
max_parallel_workers_per_gather (integer)
max_parallel_maintenance_workers (integer)
max_parallel_workers (integer)
backend_flush_after (integer)
old_snapshot_threshold (integer)
除了已经提到过的postgresql.conf
文件之外,PostgreSQL还使用另外两个手工编辑的配置文件,它们控制客户端认证(其使用在第 20 章中讨论)。默认情况下,所有三个配置文件都存放在数据库集簇的数据目录中。 本节描述的参数允许配置文件放在别的地方(这么做可以简化管理,特别是如果配置文件被独立放置,可以很容易保证它得到恰当的备份)。
data_directory
(string
)指定用于数据存储的目录。这个选项只能在服务器启动时设置。
config_file
(string
)指定主服务器配置文件(通常叫postgresql.conf
)。这个参数只能在postgres
命令行上设置。
hba_file
(string
)指定基于主机认证配置文件(通常叫pg_hba.conf
)。这个参数只能在服务器启动的时候设置。
ident_file
(string
)指定用于用户名称映射的配置文件(通常叫pg_ident.conf
)。这个参数只能在服务器启动的时候设置。另见第 20.2 节。
external_pid_file
(string
)指定可被服务器创建的用于管理程序的额外进程 ID(PID)文件。这个参数只能在服务器启动的时候设置。
在默认安装中不会显式设置以上参数。相反,命令行参数-D
或者环境变量PGDATA
指定数据目录,并且上述配置文件都能在数据目录中找到。
如果你想把配置文件放在别的地方而不是数据目录中,那么postgres
-D
命令行选项或者环境变量PGDATA
必须指向包含配置文件的目录,并且postgresql.conf
中(或者命令行上)的data_directory
参数必须显示数据目录实际存放的地方。请注意,data_directory
将覆盖-D
和PGDATA
指定的数据目录位置,但是不覆盖配置文件的位置。
如果你愿意,可以使用选项config_file
、hba_file
和/或ident_file
单独指定配置文件名称和位置。config_file
只能在postgres
命令行上指定,但是其他文件可以在主配置文件中设置。如果所有三个参数外加data_directory
被显式地设置,则不必指定-D
或PGDATA
。
在设置任何这些参数时,相对路径将被解释为相对于postgres
启动路径的路径。
listen_addresses
(string
)指定服务器在哪些 TCP/IP 地址上监听客户端连接。值的形式是一个逗号分隔的主机名和/或数字 IP 地址列表。特殊项*
对应所有可用 IP 接口。项0.0.0.0
允许监听所有 IPv4 地址并且::
允许监听所有 IPv6 地址。如果列表为空,服务器将根本不会监听任何 IP 接口,在这种情况中只能使用 Unix 域套接字来连接它。默认值是localhost,它只允许建立本地 TCP/IP “环回”连接。虽然客户端认证(第 20 章)允许细粒度地控制谁能访问服务器,listen_addresses
控制哪些接口接受连接尝试,这能帮助在不安全网络接口上阻止重复的恶意连接请求。这个参数只能在服务器启动时设置。
port
(integer
)服务器监听的 TCP 端口;默认是 5432 。请注意服务器会同一个端口号监听所有的 IP 地址。这个参数只能在服务器启动时设置。
max_connections
(integer
)决定数据库的最大并发连接数。默认值通常是 100 个连接,但是如果内核设置不支持(initdb时决定),可能会比这个 数少。这个参数只能在服务器启动时设置。
当运行一个后备服务器时,你必须设置这个参数等于或大于主服务器上的参数。否则,后备服务器上可能无法允许查询。
superuser_reserved_connections
(integer
)为PostgreSQL超级用户连接而保留的连接“槽”数。 同时活跃的并发连接最多max_connections个。任何时候,活跃的并发连接数最多为max_connections
减去 superuser_reserved_connections
,新连接就只能由超级用户发起了,并且不会有新的复制连接被接受。
默认值是 3 连接 。这个值必须小于max_connections
。 这个参数只能在服务器启动时设置。
unix_socket_directories
(string
)指定服务器用于监听来自客户端应用的连接的 Unix 域套接字目录。通过列出用逗号分隔的多个目录可以建立多个套接字。 项之间的空白被忽略,如果你需要在名字中包括空白或逗号,在目录名周围放上双引号。 一个空值指定在任何 Unix 域套接字上都不监听,在这种情况中只能使用 TCP/IP 套接字来连接到服务器。 默认值通常是/tmp
,但是在编译时可以被改变。在windows上,默认值为空,意味着默认不建立UNIX-域嵌套。这个参数只能在服务器启动时设置。
除了套接字文件本身(名为.s.PGSQL.
,其中nnnn
nnnn
是服务器的端口号),一个名为.s.PGSQL.
的普通文件会在每一个nnnn
.lockunix_socket_directories
目录中被创建。任何一个都不应该被手工移除。
unix_socket_group
(string
)设置 Unix 域套接字的所属组(套接字的所属用户总是启动服务器的用户)。可以与选项unix_socket_permissions
一起用于对 Unix域连接进行访问控制。默认是一个空字符串,表示服务器用户的默认组。这个参数只能在服务器启动时设置。
Windows 上不支持这个参数,所有设置会被忽略。
unix_socket_permissions
(integer
)设置 Unix 域套接字的访问权限。Unix 域套接字使用普通的 Unix 文件系统权限集。这个参数值应该是数字的形式,也就是系统调用chmod
和umask
接受的 形式(如果使用自定义的八进制格式,数字必须以一个0
(零)开头)。
默认的权限是0777
,意思是任何人都可以连接。合理的候选是0770
(只有用户和同组的人可以访问, 又见unix_socket_group
)和0700
(只有用户自己可以访问)(请注意,对于 Unix 域套接字,只有写权限有麻烦,因此没有对读取和执行权限的设置和收回)。
这个访问控制机制与第 20 章中的用户认证没有关系。
这个参数只能在服务器启动时设置。
这个参数与完全忽略套接字权限的系统无关,尤其是自版本10以上的Solaris。 在那些系统上,可以通过把unix_socket_directories
指向一个把搜索权限 限制给指定用户的目录来实现相似的效果。
bonjour
(boolean
)通过Bonjour广告服务器的存在。默认值是关闭。 这个参数只能在服务器启动时设置。
bonjour_name
(string
)指定Bonjour服务名称。空字符串''
(默认值)表示使用计算机名。 如果编译时没有打开Bonjour支持那么将忽略这个参数。这个参数只能在服务器启动时设置。
tcp_keepalives_idle
(integer
)规定在操作系统向客户端发送一个TCP keepalive消息后无网络活动的时间总量。 如果指定值时没有单位,则以秒为单位。值0(默认值)表示选择操作系统默认值。 指定不活动多少秒之后通过 TCP 向客户端发送一个 keepalive 消息。 0 值表示使用默认值。 这个参数只有在支持TCP_KEEPIDLE
或等效套接字选项的系统或 Windows 上才可以使用。在其他系统上,它必须为零。在通过 Unix 域套接字连接的会话中,这个参数被忽略并且总是读作零。
注意
在 Windows 上,设定值为0将设置这个参数为 2 小时,因为 Windows 不支持读取系统默认值。
tcp_keepalives_interval
(integer
)规定未被客户端确认收到的TCP keepalive消息应重新传输的时间长度。 如果指定值时没有单位,则以秒为单位。值0(默认值)表示选择操作系统默认值。 这个参数只有在支持TCP_KEEPINTVL
或等效套接字选项的系统或 Windows 上才可以使用。在其他系统上,必须为零。在通过 Unix域套接字连接的会话中,这个参数被忽略并总被读作零。
注意
在 Windows 上,设定值为0将设置这个参数为 1 秒,因为 Windows 不支持读取系统默认值。
tcp_keepalives_count
(integer
)指定服务器到客户端的连接被认为中断之前可以丢失的TCP keepalive消息的数量。值0(默认值)表示选择操作系统默认值。 这个参数只有在支持TCP_KEEPCNT
或等效套接字选项的系统上才可以使用。在其他系统上,必须为零。在通过 Unix 域套接字连接的会话中,这个参数被忽略并总被读作零。
注意
Windows 不支持该参数,且必须为零。
tcp_user_timeout
(integer
)指定传输的数据在TCP连接被强制关闭之前可以保持未确认状态的时间量。 如果指定值时没有单位,则以毫秒为单位。值0(默认值)表示选择操作系统默认值。 这个参数只有在支持TCP_USER_TIMEOUT
的系统上才被支持;在其他系统上,它必须为零。 在通过Unix-domain 套接字连接的会话中,此参数将被忽略并且始终读取为零。
注意
在Windows上不支持该参数,并且必须为零。
authentication_timeout
(integer
)允许完成客户端认证的最长时间。如果一个客户端没有在这段时间里完成认证协议,服务器将关闭连接。 这样就避免了出问题的客户端无限制地占有一个连接。如果指定值时没有单位,则以秒为单位。 默认值是 1分钟(1m
)。这个参数只能在服务器命令行上或者在postgresql.conf
文件中设置。
password_encryption
(enum
)当在CREATE ROLE或者ALTER ROLE中指定了口令时,这个参数决定用于加密该口令的算法。默认值是md5
,它会将口令存为一个MD5哈希(on
也会被接受,它是md5
的别名)。将这个参数设置为scram-sha-256
将使用SCRAM-SHA-256来加密口令。
注意老的客户端可能缺少对SCRAM认证机制的支持,因此无法使用用SCRAM-SHA-256加密的口令。详情请参考第 20.5 节。
krb_server_keyfile
(string
)设置Kerberos服务器密钥文件的位置。详情请参考第 20.6 节。这个参数只能在postgresql.conf
文件中或者服务器命令行上设置。
krb_caseins_users
(boolean
)设置是否应该以大小写不敏感的方式对待GSSAPI用户名。默认值是off
(大小写敏感)。这个参数只能在postgresql.conf
文件中或者服务器命令行上设置。
db_user_namespace
(boolean
)这个参数启用针对每个数据库的用户名。这个参数默认是关掉的。这个参数只能在postgresql.conf
文件中或者服务器命令行上设置。
如果这个参数为打开,应该把用户创建成username@dbname
的形式。当一个连接客户端传来username
时,@
和数据库名会被追加到用户名并且服务器会查找这个与数据库相关的用户名。注意在SQL环境中用含有@
的名称创建用户时,需要把用户名放在引号内。
在这个参数被启用时,仍然可以创建平常的全局用户。而在客户端中指定这种用户时只需要简单地追加@
,例如joe@
。在服务器查找该用户名之前,@
会被剥离掉。
db_user_namespace
会导致客户端和服务器的用户名表达形式不同。认证检查总是会以服务器的用户名表达形式来完成,因此认证方法必须针对服务器用户名而不是客户端用户名来配置。由于md5
方法在客户端和服务器两端都使用用户名作为salt,md5
不能与db_user_namespace
同时使用。
注意
这种特性的目的是在找到完整的解决方案之前提供一种临时的措施。在找到完整解决方案时,这个选项将被去除。
有关设置SSL的更多信息请参考第 18.9 节。
ssl
(boolean
)启用SSL连接。这个参数只能在postgresql.conf
文件中或者服务器命令行上设置。默认值是off
。
ssl_ca_file
(string
)指定包含 SSL 服务器证书颁发机构(CA)的文件名。相对路径是相对于数据目录的。这个参数只能在postgresql.conf
文件中或者服务器命令行上设置。默认值为空,表示没有载入CA文件,并且客户端证书验证没有被执行。
ssl_cert_file
(string
)指定包含 SSL 服务器证书的文件名。相对路径是相对于数据目录的。这个参数只能在postgresql.conf
文件中或者服务器命令行上设置。默认值是server.crt
。
ssl_crl_file
(string
)指定包含 SSL 服务器证书撤销列表(CRL)的文件名。其中的相对路径是相对于数据目录的。这个参数只能在postgresql.conf
文件中或者服务器命令行上设置。默认值是空,表示没有载入CRL文件。
ssl_key_file
(string
)指定包含 SSL 服务器私钥的文件名。相对路径是相对于数据目录。这个参数只能在postgresql.conf
文件中或者服务器命令行上设置。默认值是server.key
。
ssl_ciphers
(string
)指定一个允许用于SSL连接的SSL密码套件列表。 这个设置的语法和所支持的值列表可以参见OpenSSL包中的ciphers手册页。 仅在使用 TLS 版本 1.2 及更低版本的连接才受影响。目前没有控制 TLS 版本 1.3 连接使用的密码选择的设置。 默认值是HIGH:MEDIUM:+3DES:!aNULL
。默认值通常是一种合理的选择,除非用户有特定的安全性需求。
这个参数只能在postgresql.conf
文件中或者服务器命令行上设置。
默认值的解释:
HIGH
使用来自HIGH
组的密码的密码组(例如 AES, Camellia, 3DES)
MEDIUM
使用来自MEDIUM
组的密码的密码组(例如 RC4, SEED)
+3DES
OpenSSL 对HIGH
的默认排序是有问题的,因为它认为 3DES 比 AES128 更高。这是错误的,因为 3DES 提供的安全性比 AES128 低,并且它也更加慢。 +3DES
把它重新排序在所有其他HIGH
和 MEDIUM
密码之后。
!aNULL
禁用不做认证的匿名密码组。这类密码组容易收到中间人攻击,因此不应被使用。
可用的密码组细节可能会随着 OpenSSL 版本变化。可使用命令 openssl ciphers -v 'HIGH:MEDIUM:+3DES:!aNULL'
来查看 当前安装的OpenSSL版本的实际细节。注意这个列表是根据服务器密钥类型 在运行时过滤过的。
ssl_prefer_server_ciphers
(boolean
)指定是否使用服务器的 SSL 密码首选项,而不是用客户端的。这个参数只能在postgresql.conf
文件中或者服务器命令行上设置。 默认值是 on
。
老的PostgreSQL版本没有这个设置并且总是使用客户端的首选项。这个设置主要用于与那些版本 的向后兼容性。使用服务器的首选项通常会更好,因为服务器更可能会被合适地配置。
ssl_ecdh_curve
(string
)指定用在ECDH密钥交换中的曲线名称。它需要被所有连接的客户端支持。 它不需要与服务器椭圆曲线密钥使用的曲线相同。这个参数只能在postgresql.conf
文件中或者服务器命令行上设置。默认值是prime256v1
。
OpenSSL 命名了最常见的曲线: prime256v1
(NIST P-256)、 secp384r1
(NIST P-384)、 secp521r1
(NIST P-521)。 openssl ecparam -list_curves
命令可以显示可用曲线的完 整列表。不过并不是所有的都在TLS中可用。
ssl_min_protocol_version
(enum
)设置要使用的最小SSL/TLS协议版本。当前的可用版本包括: TLSv1
, TLSv1.1
, TLSv1.2
, TLSv1.3
. 旧版本的 OpenSSL 库不支持所有值;如果选择了不支持的设置将会引发错误。 TLS 1.0之前的协议版本,也就是SSL 版本 2 and 3,总是禁用的。
默认为TLSv1.2
, 在本文撰写时的行业最佳实践。
ssl_max_protocol_version
(enum
)设定要使用的最大SSL/TLS协议版本。 有效的版本为 ssl_min_protocol_version, 添加一个空字符串,允许任何协议版本。 默认为允许任何版本。设置最大协议版本主要用于测试,或者某个组件在与较新的协议配合工作时出现了问题。
ssl_dh_params_file
(string
)指定含有用于SSL密码的所谓临时DH家族的Diffie-Hellman参数的文件名。默认值为空,这种情况下将使用内置的默认DH参数。使用自定义的DH参数可以降低攻击者破解众所周知的内置DH参数的风险。可以用命令openssl dhparam -out dhparams.pem 2048
创建自己的DH参数文件。
这个参数只能在 postgresql.conf
文件中或服务器命令行上进行设置。
ssl_passphrase_command
(string
)设置当需要一个密码(例如一个私钥)来解密SSL文件时会调用的一个外部命令。默认情况下,这个参数为空,表示使用内建的提示机制。
该命令必须将密码打印到标准输出并且以代码0退出。在该参数值中,%p
被替换为一个提示字符串(要得到文字%
,应该写成%%
)。注意该提示字符串将可能含有空格,因此要确保加上适当的引号。如果输出的末尾有单一的新行,它会被剥离掉。
该命令实际上并不一定要提示用户输入一个密码。它可以从文件中读取密码、从钥匙链得到密码等等。确保选中的机制足够安全是用户的责任。
这个参数只能在 postgresql.conf
文件中或服务器命令行上进行设置。
ssl_passphrase_command_supports_reload
(boolean
)这个参数决定在配置重载期间如果一个密钥文件需要口令时,是否也调用ssl_passphrase_command
设置的密码命令。 如果这个参数为off(默认),那么在重载期间将忽略ssl_passphrase_command
,如果在此期间需要密码则SSL配置将不会被重载。 对于要求一个TTY(当服务器正在运行时可能是不可用的)来进行提示的命令,这种设置是合适的。 例如,如果密码是从一个文件中得到的,将这个参数设置为on可能是合适的。
这个参数只能在postgresql.conf
文件中或者服务器命令行上设置。
shared_buffers
(integer
)设置数据库服务器将使用的共享内存缓冲区量。默认通常是 128 MB,但是如果你的内核设置不支持(在initdb时决定),那么可以会更少。 这个设置必须至少为 128 KB。不过为了更好的性能,通常会使用明显高于最小值的设置。 如果指定值时没有单位,则以块为单位,即BLCKSZ
字节,通常为8kB.(BLCKSZ
的非默认值改变最小值。) 此参数只能在服务器启动时设置。
如果有一个专用的 1GB 或更多内存的数据库服务器,一个合理的shared_buffers
开始值是系统内存的 25%。即使更大的shared_buffers
有效,也会造成一些工作负载, 但因为PostgreSQL同样依赖操作系统的高速缓冲区,将shared_buffers
设置为超过 40% 的RAM不太可能比一个小点值工作得更好。为了能把对写大量新的或改变的数据的处理分布在一个较长的时间段内,shared_buffers
更大的设置通常要求对max_wal_size
也做相应增加。
如果系统内存小于 1GB,一个较小的 RAM 百分数是合适的,这样可以为操作系统留下足够的空间。
huge_pages
(enum
)控制是否为主共享内存区域请求巨型页。有效值是try
(默认)、on
以及off
。如果huge_pages
被设置为try
,则服务器将尝试请求巨型页,但是如果失败会退回到默认的方式。如果为on
,请求巨型页失败将使得服务器无法启动。如果为off
,则不会请求巨型页。
当前,只有Linux和Windows上支持这个设置。在其他系统上这个参数被设置为try
时,它会被忽略。
巨型页面的使用会导致更小的页面表以及花费在内存管理上的 CPU 时间更少,从而提高性能。更多有关Linux上使用巨型页面的细节请见第 18.4.5 节。
巨型页在Windows上被称为大页面。要使用大页面,需要为运行PostgreSQL的Windows用户账号分配Lock Pages in Memory的用户权限。可以使用Windows的组策略工具(gpedit.msc)来分配用户权限Lock Pages in Memory。为了在命令窗口以单进程(而不是Windows服务)的方式启动数据库服务器,命令窗口必须以管理员身份运行或者禁用用户访问控制(UAC)。当UAC被启用时,普通的命令窗口会在启动时收回用户权限Lock Pages in Memory。
注意这种设置仅影响主共享内存区域。Linux、FreeBSD以及Illumos之类的操作系统也能为普通内存分配自动使用巨型页(也被称为“超级”页或者“大”页面),而不需要来自PostgreSQL的显式请求。在Linux上,这被称为“transparent huge pages”(THP,透明巨型页)。已知这种特性对某些Linux版本上的某些用户会导致PostgreSQL的性能退化,因此当前并不鼓励使用它(与huge_pages
的显式使用不同)。
temp_buffers
(integer
)为每个数据库会话设置用于临时缓冲区的最大内存.这些是仅用于访问临时表的会话本地缓冲。 如果指定值时没有单位,则以块为单位,即BLCKSZ
字节,通常为8kB。 默认为8兆字节 (8MB
)。(如果BLCKSZ
不是8kB,则默认值按比例缩放。) 这个设置可以在独立的会话内部被改变,但是只有在会话第一次使用临时表之前才能改变; 在会话中随后企图改变该值是无效的。
一个会话将按照temp_buffers
给出的限制根据需要分配临时缓冲区。如果在一个并不需要大量临时缓冲区的会话里设置一个大的数值, 其开销只是一个缓冲区描述符,或者说temp_buffers
每增加一则增加大概 64 字节。不过,如果一个缓冲区被实际使用,那么它就会额外消耗 8192 字节(或者BLCKSZ
字节)。
max_prepared_transactions
(integer
)设置可以同时处于“prepared”状态的事务的最大数目(见PREPARE TRANSACTION)。把这个参数设置 为零(这是默认设置)将禁用预备事务特性。这个参数只能在服务器启动时设置。
如果你不打算使用预备事务,可以把这个参数设置为零来防止意外创建预备事务。如果你正在使用预备事务,你将希望把max_prepared_transactions
至少设置为max_connections一样大,因此每一个会话可以有一个预备事务待处理。
当运行一个后备服务器时,这个参数必须至少与主服务器上的一样大。否则,后备服务器上将不会执行查询。
work_mem
(integer
)设置在写入临时磁盘文件之前查询操作(例如排序或哈希表)可使用的基础最大内存容量。 如果指定值时没有单位,则以千字节为单位。默认值是4兆字节 (4MB
)。 注意对于一个复杂查询, 可能会并行运行好几个排序或者哈希操作;每个操作通常都会被允许使用这个参数指定的内存量,然后才会开始写数据到临时文件。 同样,几个正在运行的会话可能并发进行这样的操作。因此被使用的总内存可能是work_mem
值的好几倍,在选择这个值时一定要记住这一点。 ORDER BY
、DISTINCT
和归并连接都要用到排序操作。 哈希连接、基于哈希的聚集以及基于哈希的IN
子查询处理中都要用到哈希表。
与等效的基于排序的操作相比,基于哈希的操作通常对内存可用性更敏感。 可用于哈希表的内存通过将work_mem
乘hash_mem_multiplier
来计算。 这使得基于哈希的操作可以使用超出通常work_mem
基本量的内存。
hash_mem_multiplier
(浮点
)用于计算基于哈希的操作可以使用的最大内存量。 最终限制通过将work_mem
乘以hash_mem_multiplier
来决定。 默认值为 1.0,这使得基于hash的操作与基于排序的操作一样,都取决于简单的work_mem
最大值。。
考虑在经常发生溢出的环境中增加hash_mem_multiplier
,尤其是在简单增加 work_mem
会导致内存压力(内存压力通常以间歇性的内存退出错误的形式出现)。 设置为 1.5 或 2.0 对混合工作负载有效。在 2.0 - 8.0 或更多范围内的较高设置在已work_mem
已经达到40MB 或更多的环境中可能有效。
maintenance_work_mem
(integer
)指定在维护性操作(例如VACUUM
、CREATE INDEX
和ALTER TABLE ADD FOREIGN KEY
)中使用的 最大的内存量。 如果指定值时没有单位,则以千字节为单位,其默认值是 64 兆字节(64MB
)。因为在一个数据库会话中,一个时刻只有一个这样的操作可以被执行,并且一个数据库安装通常不会有太多这样的操作并发执行, 把这个数值设置得比work_mem
大很多是安全的。 更大的设置可以改进清理和恢复数据库转储的性能。
注意当自动清理运行时,可能会分配最多达这个内存的autovacuum_max_workers倍,因此要小心不要把该默认值设置得太高。 通过独立地设置autovacuum_work_mem可能会对控制这种情况 有所帮助。
autovacuum_work_mem
(integer
)指定每个自动清理工作者进程能使用的最大内存量。如果指定值时没有单位,则以千字节为单位。其默认值为 -1,表示转而使用 maintenance_work_mem的值。当运行在其他上下文环境中时, 这个设置对VACUUM
的行为没有影响。
logical_decoding_work_mem
(integer
)指定逻辑解码要使用的最大内存量,在将某些解码的更改写入本地磁盘之前。 这将限制逻辑流复制连接使用的内存量。它默认为 64 兆字节(64MB
)。 由于每个复制连接仅使用此大小的单个缓冲区,并且安装通常不会同时具有多个此类连接(受 max_wal_senders
的限制),因此将此值设置得明显高于 work_mem
是安全的,从而减少写入磁盘的解码更改数量。
max_stack_depth
(integer
)指定服务器的执行堆栈的最大安全深度。这个参数的理想设置是由内核强制的实际栈尺寸限制(ulimit -s
所设置的或者本地等价物),减去大约一兆字节的安全边缘。 需要这个安全边缘是因为在服务器中并非所有例程都检查栈深度,只是在关键的可能递规的例程中才进行检查。如果指定值时没有单位,则以千字节为单位。默认设置是两兆字节(2MB
),这个值相对比较小并且不可能导致崩溃。但是,这个值可能太小了,以至于无法执行复杂的函数。只有超级用户可以修改这个设置。
把max_stack_depth
参数设置得高于实际的内核限制将意味着一个失控的递归函数可能会导致一个独立的后端进程崩溃。 在PostgreSQL能够检测内核限制的平台上, 服务器将不允许把这个参数设置为一个不安全的值。不过,并非所有平台都能提供该信息,所以我们还是建议你在选择值时要小心。
shared_memory_type
(enum
)指定服务器应用于主共享内存区域的共享内存实现,包括 PostgreSQL 的共享缓冲区和其他共享数据。 可能的值为 mmap
(对使用 mmap
分配的匿名共享内存),sysv
(通过 shmget
分配的系统V 共享内存),和windows
(Windows共享内存)。 并非在所有平台上都支持全部值;第一个被支持的选项是该平台的默认选项。 sysv
选项不是任何平台的默认选项,通常不建议使用,因为它通常需要非默认的内核设置来允许大量的地址分配(参见 第 18.4.1 节)。
dynamic_shared_memory_type
(enum
)指定服务器应该使用的动态共享内存实现。可能的值是posix
(用于使用 shm_open
分配的 POSIX 共享内存)、sysv
(用于通过shmget
分配的 System V 共享内存)、 windows
(用于 Windows 共享内存)、和mmap
(使用存储在数据目录中的内存映射文件模拟共享内存)。并非所有平台上都支持所有值,平台上第一个支持的选项就是其默认值。 在任何平台上mmap
选项都不是默认值,通常不鼓励使用它,因为操作系统会 反复地把修改过的页面写回到磁盘上,从而增加了系统的I/O负载。不过当 pg_dynshmem
目录被存储在一个 RAM 盘时或者没有其他共享内存功能可用时, 它还是有用的。
temp_file_limit
(integer
)指定一个进程能用于临时文件(如排序和哈希临时文件,或者用于保持游标的存储文件)的最大磁盘空间量。一个试图超过这个限制的事务将被取消。 如果指定值时没有单位,则以千字节为单位。-1
(默认值)意味着没有限制。只有超级用户能够修改这个设置。
这个设置约束着一个给定PostgreSQL进程在任何瞬间所使用的所有临时文件的总空间。应该注意的是,与在查询执行中在幕后使用的临时文件相反,显式临时表所用的磁盘空间不被这个设置所限制。
max_files_per_process
(integer
)设置每个服务器子进程允许同时打开的最大文件数目。默认是 1000 个文件。如果内核强制一个安全的针对每个进程的限制,那么你不用操心这个设置。但是在 一些平台上(特别是大多数 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
(floating point
)
当超出开销限制时进程将要休眠的时间量。如果指定值时没有单位,则以毫秒为单位。 其默认值为0,这将禁用基于代价的清理延迟特性。正值将启用基于代价的清理。
在使用基于代价的清理时,vacuum_cost_delay
的合适值通常很小,也许是小于1毫秒。 虽然vacuum_cost_delay
可以被设置为毫秒级别的值,但是在较老的平台上可能无法准确地测量这种延迟。 在这样的平台上,增加 VACUUM
的节流资源消耗在1ms以上,需要改变其他的清理开销参数。 尽管如此,你应该保持 vacuum_cost_delay
在平台能持续测量的情况下尽可能小;大延迟没有帮助。
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
)只要后台写入的数据超过这个数量,尝试强制 OS 把这些写发送到底层存储上。这样做将限制内核页缓存中脏数据的量,降低了在检查点末尾发出一个 fsync 时或者 OS 在后台大批量写回数据时卡住的可能性。 那常常会导致大幅度压缩的事务延迟,但是也有一些情况(特别是负载超过shared_buffers但小于 OS 页面高速缓存)的性能会降低。这种设置可能会在某些平台上没有效果。 如果指定值时没有单位,则以块为单位,即为BLCKSZ
字节,通常为8kB.合法的范围在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,或 0 表示禁用异步 I/O 请求。当前这个设置仅影响位图堆扫描。
对于磁盘驱动器,这个设置的一个很好的出发点是组成一个被用于该数据库的 RAID 0 条带或 RAID 1 镜像的独立驱动器数量(对 RAID 5 而言,校验驱动器不计入)。但是, 如果数据库经常忙于在并发会话中发出的多个查询,较低的值可能足以使磁盘阵列繁忙。比保持磁盘繁忙所需的值更高的值只会造成额外的 CPU 开销。SSD 以及其他基于内存的存储常常能处理很多并发请求,因此它们的最佳值可能是数百。
异步 I/O 依赖于一个有效的posix_fadvise
函数(一些操作系统可能没有)。 如果不存在这个函数,将这个参数设置为除 0 之外的任何东西将导致错误。在一些操作系统上(如Solaris)虽然提供了这个函数,但它不会做任何事情。
在支持的系统上默认值为 1,否则为 0。对于一个特定表空间中的表,可以通过设定该表空间的同名参数(见ALTER TABLESPACE)可以覆盖这个值。
maintenance_io_concurrency
(integer
)与effective_io_concurrency
相似,但用于支持许多客户端会话完成的维护工作。
在支持的系统上的默认值为 10,否则为 0。 对于特定表空间中的表,这个值可以被覆盖,通过设置同名的表空间参数(参见 ALTER TABLESPACE)。
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 个工作者的并行查询使用的 CPU 时间、内存、I/O 带宽可能是不使用工作者时的 5 倍之多。
并行查询的更多信息请见第 15 章。
max_parallel_maintenance_workers
(integer
)设置单一工具性命令能够启动的并行工作者的最大数目。 当前,支持使用并行工作者的工具性命令是CREATE INDEX
,并且只有在构建B-树索引时才能并行,并且 VACUUM
没有 FULL
选项。 并行工作者从由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将不会产生效果,因为并行工作者进程都是从max_worker_processes所建立的工作者进程池中取出来的。
backend_flush_after
(integer
)只要一个后端写入的数据量超过这个数量时,就会尝试强制 OS 把这些写发送到底层存储。这样做将会限制内核页高速缓存中的脏数据数量,降低在检查点末尾发出fsync
时或者 OS 在后台大批写回数据时卡住的可能性。这常常会导致极大降低的事务延迟,但是也有一些情况中(特别是负载超过shared_buffers但低于 OS 的页面高速缓存时),性能可能会下降。这个设置可能在某些平台上没有效果。 如果指定值时没有单位,则以块为单位,即为 BLCKSZ
字节,通常为8kB。合法的范围位于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”错误的可能性。