Azure Database for PostgreSQL 灵活服务器中的服务器参数

适用于:Azure Database for PostgreSQL 灵活服务器

Azure Database for PostgreSQL 为每个服务器都提供了一部分可配置的参数。 有关 Postgres 参数的详细信息,请参阅 PostgreSQL 文档

参数类型

Azure Database for PostgreSQL 灵活服务器预配置了每个参数的最佳默认设置。 参数分为以下类型之一:

  • 静态:这些参数需要重启服务器才能实现任何更改。
  • 动态:无需重启服务器实例即可更改这些参数。 但是,更改仅适用于修改后建立的新连接。
  • 只读:这些参数在维护服务的可靠性、安全性或其他操作方面起着关键作用,因此用户无法配置它们。

若要确定参数类型,请转到 Azure 门户,然后打开“服务器参数”窗格。 参数分组到选项卡中,以便轻松识别。

参数自定义

可以使用各种方法和级别根据特定需求来自定义参数。

全局级别

若要在实例或服务器级别全局更改设置,请转到 Azure 门户中的“服务器参数”窗格。 还可以使用其他可用工具,例如 Azure CLI、REST API、Azure 资源管理器模板或合作伙伴工具。

注意

Azure Database for PostgreSQL 是托管数据库服务,因此用户没有主机或操作系统访问权限,无法查看或修改配置文件(例如 postgresql.conf)。 这些文件的内容会根据所做的参数更改自动更新。

Azure 门户中服务器参数窗格的屏幕截图。

精细级别

可以在更精细的级别调整参数。 这些调整将覆盖全局设置的值。 它们的范围和持续时间取决于你创建它们的级别:

  • 数据库级别:使用 ALTER DATABASE 命令进行特定于数据库的配置。

  • 角色或用户级别:使用 ALTER USER 命令进行以用户为中心的设置。

  • 函数、过程级别:定义函数或过程时,可以指定或更改将在调用函数时设置的配置参数。

  • 表级别:例如,可在此级别修改与自动清理相关的参数。

  • 会话级别:在单个数据库会话的持续时间内,可以调整特定参数。 PostgreSQL 通过以下 SQL 命令促进这种调整:

    • 使用 SET 命令进行特定于会话的调整。 这些更改将作为当前会话期间的默认设置。 要访问这些更改,可能需要特定的 SET 权限,并且上述可修改参数和只读参数的限制不适用。 相应的 SQL 函数为 set_config(setting_name, new_value, is_local)
    • 使用 SHOW 命令检查现有参数设置。 其 SQL 函数等效项为 current_setting(setting_name text)

重要参数

以下部分描述了其中一些参数。

shared_buffers

Attribute
默认值 总 RAM 的 25%
允许的值 总 RAM 的 10-75%
类型 静态
Level 全局
特定于 Azure 的注释 当层中的 vCore 数增加时,shared_buffers 设置大致以线性方式扩展。

说明

shared_buffers 配置参数确定分配给 PostgreSQL 数据库用于缓冲数据的系统内存量。 它是可供所有数据库进程访问的集中式内存池。

需要数据时,数据库进程首先检查共享缓冲区。 如果存在所需的数据,会快速检索此数据,并绕过更耗时的磁盘读取。 通过在数据库进程和磁盘之间充当中介,shared_buffers 可以有效地减少所需的 I/O 操作数。

huge_pages

Attribute
默认值 TRY
允许的值 TRYONOFF
类型 静态
Level 全局
特定于 Azure 的注释 对于具有 4 个或更多 vCore 的服务器,会从基础操作系统自动分配大型页面。 此功能不适用于少于 4 个 vCore 的服务器。 如果更改了任何共享内存设置,则会自动调整大型页面数量,包括更改 shared_buffers

说明

通过大型页面功能,可以在较大的块中管理内存。 通常可管理最大 2 MB 的块,而不是标准的 4 KB 页面。

使用大型页面可提供有效分流 CPU 的性能优势:

  • 它们减少了与内存管理任务相关的开销,例如更少的转换后备缓冲区 (TLB) 未命中。
  • 它们缩短了内存管理所需的时间。

具体来说,在 PostgreSQL 中,只能将大型页面用于共享内存区域。 共享内存区域的很大一部分分配给了共享缓冲区。

另一个优点是,大型页面可阻止将共享内存区域交换到磁盘,这进一步稳定了性能。

建议

  • 对于具有大量内存资源的服务器,请不要禁用大型页面。 禁用大型页面可能会损害性能。
  • 如果一开始使用不支持大型页面的较小服务器,但预计会纵向扩展到支持大型页面的服务器,那么请将 huge_pages 设置保留为 TRY,以保证无缝转换和最佳性能。

work_mem

Attribute
默认值 4MB
允许的值 4MB-2GB
类型 动态
Level 全局和精细

说明

PostgreSQL 中的 work_mem 参数可控制在每个数据库会话的专用内存区域中为某些内部操作分配的内存量。 这些操作的示例包括排序和哈希处理。

与共享内存区域中的共享缓冲区不同,work_mem 是在每个会话或每个查询的专用内存空间中分配的。 通过设置足够的 work_mem 大小,可以显著提高这些操作的效率,并减少将临时数据写入磁盘的需求。

要点

  • 专用连接内存work_mem 是每个数据库会话使用的专用内存的一部分。 此内存不同于 shared_buffers 使用的共享内存区域。
  • 特定于查询的用法:并非所有会话或查询都使用 work_mem 简单的查询(例如 SELECT 1)不太可能需要 work_mem。 但是,涉及排序或哈希处理等操作的复杂查询可能使用 work_mem 的一个或多个区块。
  • 并行操作:对于跨多个并行后端的查询,每个后端可能会使用 work_mem 的一个或多个区块。

监视和调整 work_mem

必须持续监视系统性能,并根据需要调整 work_mem,主要是在与排序或哈希处理操作相关的查询执行时间缓慢时。 下面是使用 Azure 门户中提供的工具监视性能的方法:

  • 查询性能见解:查看“按临时文件数排名靠前的查询”选项卡,以确定生成临时文件的查询。 这种情况表明,可能需要增加 work_mem
  • 故障排除指南:使用故障排除指南中的“大量临时文件”选项卡来确定有问题的查询。
精细调整

在管理 work_mem 参数时,采用精细调整方法通常比设置全局值更高效。 此方法可确保根据进程和用户的特定需求明智地分配内存。 它还将遇到内存不足问题的风险降到最低。 下面是实现这一点的步骤:

  • 用户级别:如果特定用户主要涉及聚合或报告任务(内存密集型任务),请考虑自定义该用户的 work_mem 值。 使用 ALTER ROLE 命令提高用户操作的性能。

  • 函数/过程级别:如果特定函数或过程生成大量临时文件,那么增加特定函数或过程级别的 work_mem 值可能会有所帮助。 使用 ALTER FUNCTIONALTER PROCEDURE 命令专门为这些操作分配更多内存。

  • 数据库级别:如果只有特定数据库生成大量临时文件,请在数据库级别更改 work_mem

  • 全局级别:如果系统分析显示大多数查询生成小型临时文件,而只有少数查询创建大型临时文件,那么最好全局调高 work_mem 值。 此操作可促使在内存中处理大多数查询,这样就可避免基于磁盘的操作并提高效率。 但是,请始终谨慎操作并监视服务器上的内存利用率,确保它可处理增加的 work_mem 值。

确定排序操作的最小 work_mem 值

若要查找特定查询的最小 work_mem 值,尤其是在排序过程中生成临时磁盘文件的查询,请先考虑在查询执行期间生成的临时文件大小。 例如,如果一个查询生成一个 20 MB 的临时文件:

  1. 使用 psql 或偏好的 PostgreSQL 客户端连接到数据库。
  2. 设置略高于 20 MB 的初始 work_mem 值,以便在内存中处理时考虑到额外的标头。 使用 SET work_mem TO '25MB' 等命令。
  3. 在同一会话上对有问题的查询运行 EXPLAIN ANALYZE
  4. 查看 "Sort Method: quicksort Memory: xkB" 的输出。 如果指示 "external merge Disk: xkB",请以增量方式增加 work_mem 值并重新测试,直到出现 "quicksort Memory"。 出现 "quicksort Memory" 即表示查询现在内存中运行。
  5. 通过此方法确定值后,可以全局应用该值,也可在更精细的级别应用它(如上所述)来满足你的操作需求。

maintenance_work_mem

Attribute
默认值 依赖于服务器内存
允许的值 1MB-2GB
类型 动态
Level 全局和精细

说明

maintenance_work_mem 是 PostgreSQL 中的一个配置参数。 它可控制为维护操作(例如 VACUUMCREATE INDEXALTER TABLE)分配的内存量。 与影响查询操作内存分配的 work_mem 不同,maintenance_work_mem 是为维护和优化数据库结构的任务保留的。

要点

  • Vacuum 内存上限:如果想要通过增加 maintenance_work_mem 来更快地清理死元组,请注意,VACUUM 对于收集死元组标识符有内置限制。 对于此过程,只能使用最多 1 GB 的内存。
  • autovacuum 的内存分离:可以使用 autovacuum_work_mem 设置单独控制 autovacuum 操作使用的内存。 此设置充当 maintenance_work_mem 的子集。 你可以决定在不影响其他维护任务和数据定义操作的内存分配的情况下 autovacuum 使用的内存量。

后续步骤

若要了解受支持的 PostgreSQL 扩展,请参阅 Azure Database for PostgreSQL 灵活服务器中的 PostgreSQL 扩展