本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 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 可能無法釋出預先寫入日誌 (WAL)。如需 `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 文件中的 PostgreSQL 中的資源使用](https://www.postgresql.org/docs/13/runtime-config-resource.html#GUC-LOGICAL-DECODING-WORK-MEM)。 [ PostgreSQL ](https://www.postgresql.org/docs/13/)
邏輯複寫會累積記憶體中所有交易的變更，直到這些交易遞交為止。如果跨所有交易存放的資料量超過資料庫參數 指定的量`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)。