為什麼在將 Amazon RDS for PostgreSQL 執行個體升級至版本 11 或更高版本後,每五分鐘就會出現一次寫入延遲峰值?

上次更新日期:2021 年 9 月 23 日

我已將執行 PostgreSQL 的 Amazon Relational Database Service (Amazon RDS) 執行個體升級為版本 11 或更高版本。為何我會每五分鐘看到 Amazon CloudWatch 的寫入延遲峰值?

解決方案

使用 Amazon Relational Database Service (Amazon RDS) for PostgreSQL 執行個體時,您可能會注意到 Amazon CloudWatch 指標每五分鐘的寫入延遲峰值。這個峰值與升級至 PostgreSQL 版本 11 或更新版本之後,增強型監控指標寫入總計大約 64 MB 的峰值相關。升級之後,wal_segment_size 參數的值會變成 64 MB。這些峰值在版本 10 或更早版本中可能不明顯,因為 wal_segment_size 的值是 16 MB。如需詳細資訊,請參閱 Amazon RDS - 文件歷程記錄中 2018 年 9 月 7 日的更新。

RDS for PostgreSQL 中的 archive_timeout 組態設定為 5 分鐘。此設定表示存檔程序會每五分鐘複製要存檔到 Amazon Simple Storage Service (Amazon S3) 的預寫記錄 (WAL) 區段。在閒置系統中,這個複製程序通常是唯一的 I/O 操作,因此這項操作在 CloudWatch 圖表中可能會顯著佔據主導地位。不過,您可能不會在忙碌的系統中看到此模式。例如,假設您在 db.t3.small 執行個體上執行下列工作負載 30 分鐘,以模擬具有 20 GB Amazon Elastic Block Store (Amazon EBS) 磁碟區的 RDS for PostgreSQL 執行個體上的忙碌系統:

#pgbench --host=$HOST --username=$USER --port=$PORT --protocol=simple  --progress=2  --client=1 --jobs=1 $DB -T 1800
#pgbench --initialize --fillfactor=90 --scale=100  --port=$PORT --host=$HOST --username=$USER $DB

有了此工作負載,您就不會看到 CloudWatch 寫入延遲指標的峰值。

但是假設你有以下使用案例:

  • 您有一個 I/O 請求,需要 10 毫秒才能完成,以及其他 9 個 I/O 請求,各個都需要 1 毫秒才能完成。這些請求的平均延遲計算方式如下:
    平均延遲 = (10 + (9 * 1)) / 10 = 1.9 毫秒
  • 您有一個 I/O 請求,需要 10 毫秒才能完成,且沒有任何其他 I/O 請求。此案例中的平均延遲計算方式如下:
    平均延遲 = 10 / 1 = 10 毫秒

這兩個使用案例都包含相同的 I/O 請求,需要 10 毫秒才能完成。不過,當您計算平均延遲時,緩慢請求在第二個使用案例中非常顯著,您在其中有較少的 I/O 請求與緩慢請求一起執行。如果閒置系統因為區塊大小較高而有一個緩慢的 I/O 請求,則只會從此請求計算延遲。在具有多個 I/O 請求的忙碌系統中,大部分具有較小的區塊大小,平均延遲是從這些請求計算的。

在這些情況下,您可能會在閒置的 RDS for PostgreSQL 系統中看到每五分鐘一次寫入延遲峰值。如果您的資料庫執行個體執行繁忙的工作負載,您可能不會看到這些峰值。

範例:假設您有兩個 t2.small Amazon Elastic Compute Cloud (Amazon EC2) 執行個體,每個具有 8 個 gp2 磁碟區。

在 crontab 上執行下列命令,在第一個 Amazon EC2 執行個體中每五分鐘建立一個區塊大小為 64 MB 的 64 MB 檔案:

*/5 * * * * dd if=/dev/zero of=/tmp/big_file.txt bs=64MB count=1 oflag=dsync ; rm -rf /tmp/big_file.txt

注意:務必將命令中的 big_file.txt 取代為您的檔案的名稱。

此外,在 crontab 上執行下列命令,在第二個 Amazon EC2 執行個體中每一分鐘建立區塊大小均為 8 KB 的 100 個檔案:

* * * * * for i in {1..100} ; do dd if=/dev/zero of=/tmp/small_file.txt bs=8k count=100 oflag=dsync ; rm -rf /tmp/small_file.txt ; done

注意:務必將命令中的 small_file.txt 取代為您的檔案的名稱。

您可能會注意到第二個 EC2 執行個體在 CloudWatch 中顯示比第一個 EC2 執行個體更高的寫入器延遲峰值。


此文章是否有幫助?


您是否需要帳單或技術支援?