使用池管理 Aurora PostgreSQL 连接流失
当客户端应用程序经常连接和断开连接，以至于 Aurora PostgreSQL 数据库集群响应时间变慢时，则称集群经历 连接流失 。与 Aurora PostgreSQL 数据库集群端点的每个新连接都会消耗资源，从而减少可用于处理实际工作负载的资源。我们建议您按照以下讨论的一些最佳实践来管理连接流失问题。
对于初学者来说，您可以缩短连接流失率较高的 Aurora PostgreSQL 数据库集群的响应时间。为此，您可以使用 RDS 代理之类的连接池程序。 连接池程序 为客户端提供了一个随时可用连接的缓存。几乎 Aurora PostgreSQL 的所有版本均支持 RDS 代理。有关更多信息，请参阅 Amazon RDS Proxy with Aurora PostgreSQL 。
如果特定 Aurora PostgreSQL 版本不支持 RDS 代理，则可以使用另一个 PostgreSQL 兼容的连接池程序，例如 PgBouncer。要了解更多信息，请参阅
PGBouncer
要查看您的 Aurora PostgreSQL 数据库集群能否从连接池中受益，您可以查看
postgresql.log
文件以了解连接与断开连接。您还可以使用性能详情来了解您的 Aurora PostgreSQL 数据库集群正在经历的连接流失量。接下来，您将了解有关这两个主题的信息。
记录连接和断开连接
PostgreSQL
log_connections
和
log_disconnections
参数可以捕获与
Aurora PostgreSQL 数据库集群的写入器实例
的连接和断开连接。原定设置情况下，这些参数处于关闭状态。要开启这些参数，请使用自定义参数组并通过将值更改为 1 来开启。有关自定义数据库参数组的更多信息，请参阅
使用数据库集群参数组
。要检查设置，请使用 psql 和查询连接到 Aurora PostgreSQL 的数据库集群端点，如下所示。
labdb=>SELECT setting FROM pg_settings WHERE name = 'log_connections';setting --------- (1 row)labdb=>SELECT setting FROM pg_settings WHERE name = 'log_disconnections';setting --------- (1 row)
开启这两个参数后，日志会捕获所有新的连接和断开连接。您将看到每个新的授权连接的用户和数据库。在断开连接时，还记录会话持续时间，如以下示例中所示。
2022-03-07 21:44:53.978 UTC [16641] LOG: connection authorized: user=labtek database=labdb application_name=psql 2022-03-07 21:44:55.718 UTC [16641] LOG: disconnection: session time: 0:00:01.740 user=labtek database=labdb host=[local]要检查您的应用程序是否存在连接流失，请开启这些参数（如果尚未开启）。然后，通过在实际工作负载和时间段内运行应用程序，在 PostgreSQL 日志中收集数据以进行分析。您可以在 RDS 控制台中查看日志文件。选择您的 Aurora PostgreSQL 数据库集群的写入器实例，然后选择 Logs & events（日志和事件）选项卡。有关更多信息，请参阅查看和列出数据库日志文件。
也可以从控制台下载日志文件并使用以下命令序列。此序列查找每分钟授权和断开的连接总数。
grep "connection authorized\|disconnection: session time:" postgresql.log.2022-03-21-16|\ awk {'print $1,$2}' |\ sort |\ uniq -c |\ sort -n -k1在示例输出中，您可以看到授权连接出现峰值，随后从 16:12:10 开始出现断开连接。
..... ,...... ......... 5 2022-03-21 16:11:55 connection authorized: 9 2022-03-21 16:11:55 disconnection: session 5 2022-03-21 16:11:56 connection authorized: 5 2022-03-21 16:11:57 connection authorized: 5 2022-03-21 16:11:57 disconnection: session 32 2022-03-21 16:12:10 connection authorized: 30 2022-03-21 16:12:10 disconnection: session 31 2022-03-21 16:12:11 connection authorized: 27 2022-03-21 16:12:11 disconnection: session 27 2022-03-21 16:12:12 connection authorized: 27 2022-03-21 16:12:12 disconnection: session 41 2022-03-21 16:12:13 connection authorized: 47 2022-03-21 16:12:13 disconnection: session 46 2022-03-21 16:12:14 connection authorized: 41 2022-03-21 16:12:14 disconnection: session 24 2022-03-21 16:12:15 connection authorized: 29 2022-03-21 16:12:15 disconnection: session 28 2022-03-21 16:12:16 connection authorized: 24 2022-03-21 16:12:16 disconnection: session 40 2022-03-21 16:12:17 connection authorized: 42 2022-03-21 16:12:17 disconnection: session 40 2022-03-21 16:12:18 connection authorized: 40 2022-03-21 16:12:18 disconnection: session ..... ,...... ......... 1 2022-03-21 16:14:10 connection authorized: 1 2022-03-21 16:14:10 disconnection: session 1 2022-03-21 16:15:00 connection authorized: 1 2022-03-21 16:16:00 connection authorized:有了这些信息，您可以决定您的工作负载是否可以从连接池程序中受益。要进行更详细的分析，您可以使用性能详情。
使用性能详情检测连接流失
您可以使用性能详情评估 Aurora PostgreSQL 兼容版数据库集群 上的连接流失量。在创建 Aurora PostgreSQL 数据库集群时，性能详情的设置在原定设置情况下处于开启状态。如果您在创建数据库集群时清除了此选项，请修改集群以开启该功能。有关更多信息，请参阅修改 Amazon Aurora 数据库集群。
在 Aurora PostgreSQL 数据库集群上运行性能详情后，您可以选择要监控的指标。您可以通过控制台中的导航窗格访问性能详情。还可以从 Aurora PostgreSQL 数据库集群的写入器实例的 Monitoring（监控）选项卡访问性能详情，如下图所示。
有关对您的 Aurora PostgreSQL 数据库集群使用性能详情的更多信息，请参阅在 Amazon Aurora 上使用性能详情监控数据库负载。要分析指标，请参阅使用性能详情控制面板分析指标。
演示连接池的优势
如前所述，如果您确定您的 Aurora PostgreSQL 数据库集群存在连接流失问题，则可以使用 RDS 代理来提高性能。接下来，您可以了解一个示例，该示例显示了使用和未使用连接池时处理工作负载的差异。该示例使用 pgbench 对事务工作负载进行建模。
与 psql 一样，pgbench 是一个 PostgreSQL 客户端应用程序，您可以从本地客户端计算机上安装和运行该应用程序。也可以从用于管理 Aurora PostgreSQL 数据库集群的 Amazon EC2 实例中安装和运行该应用程序。有关更多信息，请参阅 PostgreSQL 文档中的 pgbench
。 要逐步完成此示例，您首先要在数据库中创建 pgbench 环境。以下命令是在指定的数据库中初始化 pgbench 表的基本模板。此示例使用原定设置的主用户账户
postgres进行登录。根据需要，为您的 Aurora PostgreSQL 数据库集群更改此账户。您在集群的写入器实例上的数据库中创建 pgbench 环境。注意
pgbench 初始化过程删除并重新创建名为
pgbench_accounts、pgbench_branches|pgbench_history和pgbench_tellers的表。请确保在初始化 pgbench 时为选择的数据库不使用这些名称。dbnamepgbench -U postgres -hdb-cluster-instance-1.111122223333.aws-region.rds.amazonaws.com -p 5432 -d -i -s 50dbname对于 pgbench，请指定以下参数。
指定用于在表中填充行的缩放因子。原定设置的缩放因子为 1，它在
pgbench_branches表中生成 1 行、在pgbench_tellers表中生成 10 行，而在pgbench_accounts表中生成 100000 行。为 Aurora PostgreSQL 数据库集群的写入器实例指定用户账户。
设置 pgbench 环境后，可以在有或没有连接池的情况下运行基准测试。原定设置测试由每个事务的一系列五个 SELECT、UPDATE 和 INSERT 命令组成，这些命令在指定时间内重复运行。您可以指定缩放因子、客户端数量和其他详细信息来对自己的使用案例建模。
例如，以下命令使用 20 个并发连接（-c 选项）运行基准测试 60 秒（-T 选项，表示时间）。-C 选项使测试每次都使用新连接运行，而不是每个客户端会话运行一次。此设置可以为您指示连接开销。
pgbench -h docs-lab-apg-133-test-instance-1.c3zr2auzukpa.us-west-1.rds.amazonaws.com -U postgres -p 5432 -T 60 -c 20 -C labdbPassword:**********pgbench (14.3, server 13.3) starting vacuum...end. transaction type: <builtin: TPC-B (sort of)> scaling factor: 50 query mode: simple number of clients: 20 number of threads: 1 duration: 60 s number of transactions actually processed: 495 latency average = 2430.798 ms average connection time = 120.330 ms tps = 8.227750 (including reconnection times)在不重复使用连接的情况下，在 Aurora PostgreSQL 数据库集群的写入器实例上运行 pgbench 表明每秒只处理大约 8 个事务。在 1 分钟的测试中，总共有 495 个事务。
如果您重复使用连接，Aurora PostgreSQL 数据库集群对用户数量的响应速度快了将近 20 倍。通过重复使用，总共处理了 9,042 个事务。相比之下，在相同的时间和相同数量的用户连接下处理了 495 个事务。区别在于，在后一种情况中重复使用每个连接。
pgbench -h docs-lab-apg-133-test-instance-1.c3zr2auzukpa.us-west-1.rds.amazonaws.com -U postgres -p 5432 -T 60 -c 20 labdbPassword:*********pgbench (14.3, server 13.3) starting vacuum...end. transaction type: <builtin: TPC-B (sort of)> scaling factor: 50 query mode: simple number of clients: 20 number of threads: 1 duration: 60 s