Share Your AWS re:Post Experience - Quick 3 Question Survey
Help us improve AWS re:Post! We're interested in understanding how you use re:Post and its impact on your AWS journey. Please take a moment to complete our brief 3-question survey.
如何對 Amazon RDS 執行個體中 IOPS 瓶頸導致的 Amazon EBS 磁碟區延遲進行疑難排解?
我有一個 Amazon Relational Database Service (Amazon RDS) 資料庫執行個體。我想要針對 Amazon RDS 執行個體中的 Amazon Elastic Block Store (Amazon EBS) 磁碟區延遲問題進行疑難排解。
解決方案
針對由 IOPS 或輸送量瓶頸所造成的 Amazon RDS 執行個體延遲問題,最常見的原因包括以下幾項:
- 執行個體層級的 IOPS 瓶頸
- 磁碟區層級的 IOPS 瓶頸
- 執行個體層級的輸送量瓶頸
- 磁碟區層級的輸送量瓶頸
- 微型爆量
請根據您的使用案例使用下列疑難排解步驟。
使用一般用途 SSD (gp2) 的 RDS 執行個體
請執行下列檢查:
- 檢查 Amazon RDS 執行個體的組態資訊,例如資料庫執行個體類別和儲存大小。此資訊可協助您追蹤 IOPS 和輸送量限制。在針對造成 IOPS 或輸送量瓶頸的問題進行疑難排解時,必須知道這些值。
- 使用 Amazon CloudWatch 圖表來檢查 DiskQueueDepth、ReadLatency 和 WriteLatency 的值是否有任何峰值。在一般情況下,最佳實務是每分鐘、每 1000 IOPS 使用值為 1 的 DiskQueueDepth。ReadLatency 和 WriteLatency 應該會小於 10 毫秒。如果您發現峰值,則請識別出現峰值的時間。
- 使用 CloudWatch 圖表來檢視 ReadIOPS 和 WriteIOPS 指標。檢查在 DiskQueueDepth、ReadLatency 和 WriteLatency 出現峰值期間,是否有超過磁碟區層級的 IOPS 限制情形。
- 使用 CloudWatch 圖表來檢查 BurstBalance 的值是否有下滑情形。此檢查僅適用於不到 1 TB 大小的磁碟區。BurstBalance 的值若有下滑,便可確認峰值發生期間有出現 IOPS 瓶頸。
- 使用 CloudWatch 圖表來檢視 ReadThroughput 和 WriteThroughput 指標。檢查在 ReadThroughput 和 WriteThroughput 出現峰值期間,是否有超過磁碟區層級的輸送量限制情形。
- 如果您使用 EBS 最佳化 RDS 執行個體類別,則請使用 CloudWatch 圖表來檢查 IOPS 或輸送量是否發生節流。例如,具有高載容量的類別,請檢視 CloudWatch 圖表中的 EBSIOBalance% 和 EBSByteBalance% 指標。如果 EBSIOBalance% 或 EBSByteBalance% 的值一直很低,就表示 IOPS 或輸送量在執行個體層級遇到瓶頸。
如果 IOPS 和/或輸送量發生節流情形,就表示 IOPS 或輸送量不足以應付儲存層級的工作負載。若要修正此問題,請執行下列動作:
- 找出在資料庫上造成較多負載的 SQL 查詢,然後將這些查詢最佳化。如果工作負載很正常,或已無空間可供調整 SQL 查詢,則可能需要增加儲存大小以獲得更高的 IOPS 容量。
**注意:**增加 RDS 執行個體的儲存大小之後,就無法將大小縮減為之前的值。 - 請考慮將磁碟區從一般用途 (gp2) 切換為佈建 IOPS (io1)。如果資料庫執行個體是單一可用區,且您使用的是自訂參數群組,則在 gp2 和 io1 之間進行切換可能會造成短暫停機時間。如果您的執行個體是多可用區域,則不會遇到任何停機時間。
- 如果您發現 IOPS 或輸送量在執行個體層級有節流情形,則必須擴充執行個體類別規模,以獲得更高的 IOPS 或輸送量容量。
使用佈建 IOPS (io1) 的 RDS 執行個體
- 檢查 Amazon RDS 執行個體的組態資訊,例如資料庫執行個體類別和所定義的佈建 IOPS,以確定資料庫執行個體類別的 IOPS 限制或輸送量限制。
- 使用 CloudWatch 圖表來檢查 DiskQueueDepth、ReadLatency 和 WriteLatency 的值是否有任何峰值。在一般情況下,最佳實務是每分鐘、每 1000 IOPS 使用值為 1 的 DiskQueueDepth。ReadLatency 或 WriteLatency 應該會在 10 毫秒內。如果您發現峰值,則請識別出現峰值的時間。
- 使用 CloudWatch 圖表來檢視 ReadIOPS 和 WriteIOPS 指標。檢查在 DiskQueueDepth、ReadLatency 和 WriteLatency 出現峰值期間,是否有超過 IOPS 限制的情形。
- 使用 CloudWatch 圖表來檢視 ReadThroughput 和 WriteThroughput 指標。檢查在 ReadThroughput 和 WriteThroughput 出現峰值期間,是否有超過輸送量限制的情形。
- 如果您使用 EBS 最佳化 RDS 執行個體類別,則請使用 CloudWatch 圖表來檢查 IOPS 或輸送量是否發生節流。例如,具有高載容量的類別,請檢視 CloudWatch 圖表中的 EBSIOBalance% 和 EBSByteBalance% 指標。如果 EBSIOBalance% 或 EBSByteBalance% 的百分比值一直很低,就分別表示 IOPS 或輸送量在執行個體層級遇到瓶頸。
如果 IOPS 或輸送量發生節流情形,就表示 IOPS 或輸送量不足以應付儲存層級的工作負載。若要修正此問題,請執行下列動作:
- 找出在資料庫上造成較多負載的 SQL 查詢,然後將這些查詢最佳化。如果工作負載很正常,或已無空間可供調整 SQL 查詢,則可能需要增加所佈建的 IOPS。
- 如果您發現 IOPS 或輸送量在執行個體層級有節流情形,則必須擴充執行個體類別規模,以獲得更高的輸送量或 IOPS 容量。
微型爆量
當 EBS 磁碟區在比收集期間短很多的期間內「爆增」高 IOPS 或輸送量時,便會發生微型爆量。系統會以 60 秒的間隔收集 CloudWatch 指標。由於磁碟區爆增高 IOPS 或輸送量的時間比收集期間短,因此 CloudWatch 不會反映爆增情形。您可以使用增強型監控來識別造成延遲的原因是否為微型爆量。開啟 1 秒粒度的增強型監控。您可以使用讀取 IO/秒和寫入 IO/秒指標來判斷實際的 IOPS 使用率。您可以使用讀取 KB/秒和寫入 KB/秒來判斷每秒的實際輸送量使用率。如需詳細資訊,請參閱增強型監控指標描述。
相關資訊
了解 Amazon RDS 和 GP2 的高載效能與基準效能

相關內容
- 已提問 1 年前lg...
- 已提問 2 年前lg...
- 已提問 2 年前lg...
- AWS 官方已更新 3 年前
- AWS 官方已更新 3 年前
- AWS 官方已更新 2 年前