# Amazon Aurora PostgreSQL 的性能和扩展
<a name="AuroraPostgreSQL.Managing"></a>

下文将介绍如何管理 Amazon Aurora PostgreSQL 数据库集群的性能和扩缩。还包括有关其他维护任务的信息。

**Topics**
+ [扩展 Aurora PostgreSQL 数据库实例](#AuroraPostgreSQL.Managing.Performance.InstanceScaling)
+ [至 Aurora PostgreSQL 数据库实例的最大连接数](#AuroraPostgreSQL.Managing.MaxConnections)
+ [Aurora PostgreSQL 的临时存储限制](#AuroraPostgreSQL.Managing.TempStorage)
+ [Aurora PostgreSQL 的大页](#AuroraPostgreSQL.Managing.HugePages)
+ [使用错误注入查询测试 Amazon Aurora PostgreSQL](AuroraPostgreSQL.Managing.FaultInjectionQueries.md)
+ [显示 Aurora PostgreSQL 数据库集群的卷状态](AuroraPostgreSQL.Managing.VolumeStatus.md)
+ [指定 stats\$1temp\$1directory 的 RAM 磁盘](AuroraPostgreSQL.Managing.RamDisk.md)
+ [使用 PostgreSQL 管理临时文件](PostgreSQL.ManagingTempFiles.md)

## 扩展 Aurora PostgreSQL 数据库实例
<a name="AuroraPostgreSQL.Managing.Performance.InstanceScaling"></a>

您可通过两种方式扩展 Aurora PostgreSQL 数据库实例，即实例扩展和读取扩展。有关读取扩展的更多信息，请参阅[读取扩展](Aurora.Managing.Performance.md#Aurora.Managing.Performance.ReadScaling)。

您可以修改数据库集群中的每个数据库实例的数据库实例类，以扩展 Aurora PostgreSQL 数据库集群。Aurora PostgreSQL 支持多种针对 Aurora 优化的数据库实例类。不要将 db.t2 或 db.t3 实例类用于大小超过 40 TB 的较大 Aurora 集群。

**注意**  
建议仅将 T 数据库实例类用于开发和测试服务器，或其他非生产服务器。有关 T 实例类的更多详细信息，请参阅[数据库实例类类型](Concepts.DBInstanceClass.Types.md)。

扩缩不会即时完成。可能需要 15 分钟或更长时间才能完成对其他数据库实例类的更改。如果使用此方法修改数据库实例类，则应在下一个计划的维护时段内（而不是立即）应用更改，从而避免影响用户。

作为直接修改数据库实例类的替代方法，您可以使用 Amazon Aurora 的高可用性功能显著减少停机时间。首先，将 Aurora 副本添加到集群中。创建副本时，选择要用于集群的数据库实例类大小。Aurora 副本与集群同步后，您可以失效转移至新添加的副本。要了解更多信息，请参阅 [Aurora 副本](Aurora.Replication.md#Aurora.Replication.Replicas) 和 [Amazon Aurora PostgreSQL 的快速故障转移](AuroraPostgreSQL.BestPractices.FastFailover.md)。

有关 Aurora PostgreSQL 支持的数据库实例类的详细规格，请参阅[数据库实例类支持的数据库引擎](Concepts.DBInstanceClass.SupportAurora.md)。

## 至 Aurora PostgreSQL 数据库实例的最大连接数
<a name="AuroraPostgreSQL.Managing.MaxConnections"></a>

Aurora PostgreSQL 数据库集群根据数据库实例类及其可用内存分配资源。与数据库集群的每个连接都会占用这些资源（如内存和 CPU）的增量。每个连接占用的内存取决于查询类型、计数以及是否使用临时表。即使是空闲连接也会占用内存和 CPU。这是因为当查询在连接上运行时，系统将为每个查询分配更多内存，而且即使处理停止，内存也不会完全释放。因此，建议您确保应用程序不会占用空闲连接：每个空闲连接都会浪费资源并对性能产生负面影响。有关更多信息，请参阅[空闲 PostgreSQL 连接占用的资源](https://aws.amazon.com/blogs/database/resources-consumed-by-idle-postgresql-connections/)。

Aurora PostgreSQL 数据库实例允许的最大连接数量由该数据库实例的参数组中指定的 `max_connections` 参数值确定。`max_connections` 参数的理想设置是既能支持应用程序所需的所有客户端连接，又不会有太多未使用的连接，外加至少 3 个支持 AWS 自动化的连接。修改 `max_connections` 参数设置之前，建议您考虑以下内容：
+ 如果 `max_connections` 值太低，当客户端尝试连接时，Aurora PostgreSQL 数据库实例可能没有足够的可用连接。如果发生这种情况，尝试使用 `psql` 进行连接会引发如下错误消息：

  ```
  psql: FATAL: remaining connection slots are reserved for non-replication superuser connections
  ```
+ 如果 `max_connections` 值超过了实际需要的连接数，未使用的连接可能会导致性能降低。

`max_connections` 的默认值源自以下 Aurora PostgreSQL `LEAST` 函数：

`LEAST({DBInstanceClassMemory/9531392},5000)`.

如果要更改 `max_connections` 的值，您需要创建自定义数据库集群参数组并在其中更改其值。将自定义数据库参数组应用到集群之后，请务必重启主实例，这样新值才能生效。有关更多信息，请参阅[Amazon Aurora PostgreSQL 参数](AuroraPostgreSQL.Reference.ParameterGroups.md)和[在 Amazon Aurora 中创建数据库集群参数组](USER_WorkingWithParamGroups.CreatingCluster.md)。

**提示**  
如果您的应用程序经常打开和关闭连接，或使大量长期连接保持打开，建议您使用 Amazon RDS 代理。RDS 代理是一种完全托管的高可用性数据库代理，它使用连接池安全有效地共享数据库连接。要了解有关 RDS 代理的更多信息，请参阅 [适用于 Aurora 的Amazon RDS 代理](rds-proxy.md)。

 有关 Aurora Serverless v2 实例如何处理此参数的详细信息，请参阅 [Aurora Serverless v2 的最大连接数](aurora-serverless-v2.setting-capacity.md#aurora-serverless-v2.max-connections)。

## Aurora PostgreSQL 的临时存储限制
<a name="AuroraPostgreSQL.Managing.TempStorage"></a>

Aurora PostgreSQL 将表和索引储存在 Aurora 存储子系统中。Aurora PostgreSQL 对于非持久性临时文件使用单独的临时存储。这包括用于在查询处理过程对大型数据集进行排序或者用于索引构建操作等用途的文件。有关更多信息，请参阅文章[如何解决 Aurora PostgreSQL 兼容实例中的本地存储问题？](https://repost.aws/knowledge-center/postgresql-aurora-storage-issue)

这些本地存储卷由 Amazon Elastic Block Store 提供支持，并可以通过使用更大的数据库实例类来进行扩展。有关存储的更多信息，请参阅 [Amazon Aurora 存储](Aurora.Overview.StorageReliability.md)。您还可以使用启用 NVMe 的实例类型和启用 Aurora 优化型读取功能的临时对象，来增加临时对象的本地存储。有关更多信息，请参阅 [使用 Aurora 优化型读取功能提高 Aurora PostgreSQL 的查询性能](AuroraPostgreSQL.optimized.reads.md)。

**注意**  
当扩展数据库实例（例如，从 db.r5.2xlarge 扩展到 db.r5.4xlarge）时，您可能会看到 `storage-optimization` 事件。

下表显示了每个 Aurora PostgreSQL 数据库实例类可用的最大临时存储空间。有关 Aurora 的数据库实例类支持的更多信息，请参阅 [Amazon Aurora数据库实例类](Concepts.DBInstanceClass.md)。


| 数据库实例类 | 最大可用临时存储空间 (GiB) | 
| --- | --- | 
| db.x2g.16xlarge | 1829 | 
| db.x2g.12xlarge | 1606 | 
| db.x2g.8xlarge | 1071 | 
| db.x2g.4xlarge | 535 | 
| db.x2g.2xlarge | 268 | 
| db.x2g.xlarge | 134 | 
| db.x2g.large | 67 | 
| db.r8g.48xlarge | 3072 | 
| db.r8g.24xlarge | 1536 | 
| db.r8g.16xlarge | 998 | 
| db.r8g.12xlarge | 749 | 
| db.r8g.8xlarge | 499 | 
| db.r8g.4xlarge | 250 | 
| db.r8g.2xlarge | 125 | 
| db.r8g.xlarge | 63 | 
| db.r8g.large | 31 | 
| db.r7g.16xlarge | 1008 | 
| db.r7g.12xlarge | 756 | 
| db.r7g.8xlarge | 504 | 
| db.r7g.4xlarge | 252 | 
| db.r7g.2xlarge | 126 | 
| db.r7g.xlarge | 63 | 
| db.r7g.large | 32 | 
| db.r7i.48xlarge | 3072 | 
| db.r7i.24xlarge | 1500 | 
| db.r7i.16xlarge | 1008 | 
| db.r7i.12xlarge | 748 | 
| db.r7i.8xlarge | 504 | 
| db.r7i.4xlarge | 249 | 
| db.r7i.2xlarge | 124 | 
| db.r7i.xlarge | 62 | 
| db.r7i.large | 31 | 
| db.r6g.16xlarge | 1008 | 
| db.r6g.12xlarge | 756 | 
| db.r6g.8xlarge | 504 | 
| db.r6g.4xlarge | 252 | 
| db.r6g.2xlarge | 126 | 
| db.r6g.xlarge | 63 | 
| db.r6g.large | 32 | 
| db.r6i.32xlarge | 1829 | 
| db.r6i.24xlarge | 1500 | 
| db.r6i.16xlarge | 1008 | 
| db.r6i.12xlarge | 748 | 
| db.r6i.8xlarge | 504 | 
| db.r6i.4xlarge | 249 | 
| db.r6i.2xlarge | 124 | 
| db.r6i.xlarge | 62 | 
| db.r6i.large | 31 | 
| db.r5.24xlarge | 1500 | 
| db.r5.16xlarge | 1008 | 
| db.r5.12xlarge | 748 | 
| db.r5.8xlarge | 504 | 
| db.r5.4xlarge | 249 | 
| db.r5.2xlarge | 124 | 
| db.r5.xlarge | 62 | 
| db.r5.large | 31 | 
| db.r4.16xlarge | 960 | 
| db.r4.8xlarge | 480 | 
| db.r4.4xlarge | 240 | 
| db.r4.2xlarge | 120 | 
| db.r4.xlarge | 60 | 
| db.r4.large | 30 | 
| db.t4g.large | 16.5 | 
| db.t4g.medium | 8.13 | 
| db.t3.large | 16 | 
| db.t3.medium | 7.5 | 

**注意**  
启用 NVMe 的实例类型最多可以将可用临时空间增加到 NVMe 的总大小。有关更多信息，请参阅 [使用 Aurora 优化型读取功能提高 Aurora PostgreSQL 的查询性能](AuroraPostgreSQL.optimized.reads.md)。

您可以使用 `FreeLocalStorage` CloudWatch 指标监控数据库实例可用的临时存储，如[Amazon Aurora 的 Amazon CloudWatch 指标](Aurora.AuroraMonitoring.Metrics.md)中所述。（这不适用于 Aurora Serverless v2。）

对于某些工作负载，您可以通过为执行操作的进程分配更多内存来减少临时存储量。要增加操作可用的内存，请增加 [work\$1mem](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM) 或 [maintenance\$1work\$1mem](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-MAINTENANCE-WORK-MEM) PostgreSQL 参数的值。

## Aurora PostgreSQL 的大页
<a name="AuroraPostgreSQL.Managing.HugePages"></a>

*大页*是一项内存管理功能，可以减少数据库实例处理大量连续内存数据块（例如共享缓冲区使用的内存数据块）时的开销。Aurora PostgreSQL 的当前所有可用版本都支持这项 PostgreSQL 功能。

对于除 t3.medium、db.t3.large、db.t4g.medium、db.t4g.large 实例类之外的所有数据库实例类，默认情况下都会开启 `Huge_pages` 参数。您无法在 Aurora PostgreSQL 支持的实例类中更改 `huge_pages` 参数值或关闭此功能。

在不支持大页内存功能的 Aurora PostgreSQL 数据库实例上，特定进程内存使用量可能会增加，而不会相应地改变工作负载。

在服务器启动期间，系统会分配共享内存段，例如缓冲区缓存。当大内存页不可用时，系统不会向 postmaster 进程收取这些分配的费用。相反，它包括首先访问共享内存段中每个 4 KB 页面的进程中的内存。

**注意**  
活动连接会根据需要共享分配的内存，而无论如何跨进程跟踪共享内存使用量。