本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# PostgreSQL 端点故障排除
本节包含特定于 PostgreSQL 的复制场景。
**Topics**
+ [源上长时间运行的事务](#CHAP_Troubleshooting_Latency_Source_PostgreSQL_Longrunning)
+ [源端工作负载过高](#CHAP_Troubleshooting_Latency_Source_PostgreSQL_Highworkload)
+ [高网络吞吐量](#CHAP_Troubleshooting_Latency_Source_PostgreSQL_Highnetwork)
+ [Aurora PostgreSQL 中的溢出文件](#CHAP_Troubleshooting_Latency_Source_PostgreSQL_Spill)
## 源上长时间运行的事务
当源数据库中有长时间运行的事务（例如单个事务中有几千次插入）时，在事务完成之前，DMS CDC 事件和事务计数器不会增加。这种延迟可能会导致延迟问题，您可以使用 `CDCLatencyTarget` 指标来衡量。
要查看长期运行的事务，请执行以下操作之一：
+ 使用 `pg_replication_slots` 视图。如果该`restart_lsn`值未更新，PostgreSQL 很可能因为长期处于活动状态的事务而无法发布 Write Ahead Logs WALs ()。有关 `pg_replication_slots` 视图的信息，请参阅 [PostgreSQL 15.4 文档](https://www.postgresql.org/docs/15/)中的 [pg\$1replication\$1slots](https://www.postgresql.org/docs/15/view-pg-replication-slots.html)。
+ 使用以下查询返回数据库中所有活动查询的列表以及相关信息：
```
SELECT pid, age(clock_timestamp(), query_start), usename, query
FROM pg_stat_activity WHERE query != ''
AND query NOT ILIKE '%pg_stat_activity%'
ORDER BY query_start desc;
```
在查询结果中，`age` 字段显示每个查询的活动时长，您可以使用该时长来确定长时间运行的查询。
## 源端工作负载过高
如果您的源 PostgreSQL 的工作负载很高，请检查以下事项以减少延迟：
+ 使用 `test_decoding` 插件，从具有高每秒事务数（TPS）值的源数据库迁移表的子集时，您可能会遇到高延迟。这是因为 `test_decoding` 插件会将所有数据库更改发送到复制实例，然后 DMS 会根据任务的表映射对这些更改进行筛选。不属于任务表映射的表中的事件可能会增加源延迟。
+ 使用以下方法之一检查 TPS 吞吐量。
+ 对于 Aurora PostgreSQL 来源，请使用该指标。`CommitThroughput` CloudWatch
+ 对于在 Amazon RDS 或本地运行的 PostgreSQL，请通过 PSQL 客户端版本 11 或更高版本使用以下查询（在查询期间按 **enter** 可显示结果进度）：
```
SELECT SUM(xact_commit)::numeric as temp_num_tx_ini FROM pg_stat_database; \gset
select pg_sleep(60);
SELECT SUM(xact_commit)::numeric as temp_num_tx_final FROM pg_stat_database; \gset
select (:temp_num_tx_final - :temp_num_tx_ini)/ 60.0 as "Transactions Per Second";
```
+ 为了减少使用 `test_decoding` 插件时的延迟，请考虑改为使用 `pglogical` 插件。与 `test_decoding` 插件不同，`pglogical` 插件会筛选源端的预写日志（WAL）更改，并且仅将相关更改发送到复制实例。有关将`pglogical`插件与一起使用的信息 AWS DMS，请参阅[配置 pglogical 插件](CHAP_Source.PostgreSQL.md#CHAP_Source.PostgreSQL.Security.Pglogical)。
## 高网络吞吐量
使用 `test_decoding` 插件时，您的复制可能会占用大量的网络带宽，尤其是在有大量事务期间。这是因为 `test_decoding` 插件会处理更改，并将它们转换为人类可读格式，这比原始二进制格式更大。
为了提高性能，请考虑改用 `pglogical` 插件，它是一个二进制插件。与 `test_decoding` 插件不同，`pglogical` 插件生成二进制格式的输出，从而导致压缩的预写日志（WAL）流更改。
## Aurora PostgreSQL 中的溢出文件
在 PostgreSQL 版本 13 及更高版本中，`logical_decoding_work_mem` 参数决定了用于解码和流式传输的内存分配。有关 `logical_decoding_work_mem` 参数的更多信息，请参阅 [PostgreSQL 13.13 文档](https://www.postgresql.org/docs/13/)中的 [PostgreSQL 中的资源消耗量](https://www.postgresql.org/docs/13/runtime-config-resource.html#GUC-LOGICAL-DECODING-WORK-MEM)。
逻辑复制会累积内存中所有事务的更改，直到这些事务提交为止。如果所有事务中存储的数据量超过数据库参数 `logical_decoding_work_mem` 指定的量，则 DMS 会将事务数据溢出到磁盘，以便为新的解码数据腾出内存空间。
长时间运行的事务或许多子事务可能会导致 DMS 占用更多的逻辑解码内存。内存使用量的增加会导致 DMS 在磁盘上创建溢出文件，从而导致复制期间源延迟很高。
要减少源工作负载增加所带来的影响，请执行以下操作：
+ 减少长时间运行的事务。
+ 减少子事务数。
+ 避免执行会生成大量日志记录的操作，例如在单个事务中删除或更新整个表。改为以较小的批量执行操作。
您可以使用以下 CloudWatch 指标来监控源上的工作负载：
+ `TransactionLogsDiskUsage`：逻辑 WAL 当前占用的字节数。如果逻辑复制槽无法跟上新写入数据的步伐，或者如果任何长时间运行的事务阻碍对旧文件进行垃圾回收，则此值会单调增加。
+ `ReplicationSlotDiskUsage`：逻辑复制插槽当前使用的磁盘空间量。
您可以通过调整 `logical_decoding_work_mem` 参数来减少源延迟。此参数的默认值为 64 MB。此参数限制每个逻辑流复制连接使用的内存量。建议将 `logical_decoding_work_mem` 值设置为显著高于 `work_mem` 值，以减少 DMS 写入磁盘的解码更改量。
建议定期检查溢出文件，尤其是在迁移活动繁忙或延迟期间。如果 DMS 正在创建大量溢出文件，则意味着逻辑解码的运行效率低下，可能会增加延迟。要缓解这种情况，请增加 `logical_decoding_work_mem` 参数值。
您可以使用 `aurora_stat_file` 函数检查当前事务溢出量。有关更多信息，请参阅《Amazon Relational Database Service 开发人员指南》**中的[调整工作内存以进行逻辑解码](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.BestPractices.Tuning-memory-parameters.html#AuroraPostgreSQL.BestPractices.Tuning-memory-parameters.logical-decoding-work-mem)。