如何對 Amazon RDS for PostgreSQL 中 DiskQueueDepth 增加的問題進行疑難排解？

簡短說明

DiskQueueDepth 是應用程式提交但尚未傳送至儲存裝置的輸入和輸出 (I/O) 請求數量。由於磁碟或儲存體正忙於處理其他請求，因此這些請求處於待處理狀態。

高 DiskQueueDepth 表示 I/O 請求增加的速度快於儲存系統可處理的速度。Amazon RDS 以一分鐘為間隔的平均值來報告此指標。最佳實務是將每 1000 個 IOPS 可用的佇列長度目標設為 1。

**注意：**若要測量 I/O 效能，請檢查執行個體的輸送量和 I/O 作業數。

解決方法

若要疑難排解 Amazon RDS for PostgreSQL 中 DiskQueueDepth 增加的問題，請完成以下事項：

識別高 DiskQueueDepth

若要識別高 DiskQueueDepth，請檢查以下項目：

• 當發生效能問題時，檢查您的 Amazon CloudWatch 指標。尋找 DiskQueueDepth 指標中高於正常的尖峰。如果 DiskQueueDepth 在較長時間內持續偏高，查詢會等待更久才執行。
• 檢查您的執行個體類型限制。確認 ReadIOPS、WriteIOPS、ReadThroughput 和 WriteThroughput 指標是否達到其執行個體類型限制。
• 檢查您的 ReadThroughput 和 WriteThroughput 指標。CloudWatch 會以每秒位元組數呈現此資料，因此為了更清楚解讀，請將這些值轉換為 MB/s 或 GB/s。若要判斷您是否已達到已配置的輸送量限制，請將相同時間範圍內的兩個指標加總。如需更多配置給執行個體輸送量的資訊，請參閱 Amazon RDS 執行個體類型文件。
• 檢查您的 EBSByteBalance% 指標。如果 EBSByteBalance% 等於或接近零，則執行個體消耗了高輸送量。此外，位元組餘額為零也表示您的頻寬受到限流。

檢查您的儲存類型和大小

若要檢查您的儲存類型和大小，請採取以下動作：

• 最佳化您的工作負載。探索可用選項，以調校並提升工作負載的效率。
• 對於一般用途 SSD (gp2)，請確認您的儲存體大小具有足夠的基準 IOPS 和輸送量。
• 若要取得更多 IOPS 或佈建 gp3、io1 和 io2，請調校您的工作負載，或擴展至具有更高 CPU、記憶體和 I/O 容量的較大執行個體。

檢查是否有流量突然增加

資料庫活動的非預期尖峰可能會導致 DiskQueueDepth 增加。若要識別連線中的尖峰，請採取以下動作：

• 檢查 Amazon CloudWatch 指標中的 DatabaseConnections 圖表。過多並行連線可能會導致大量讀取和寫入作業。
• 每 1000 個 IOPS 可用的佇列長度應達到 1。(這是一般用途 SSD 磁碟區的基準值，也是已佈建 IOPS SSD 磁碟區的佈建值。)
• 根據您的需求監控應用程式效能並進行調整。

檢查是否有微高載問題

如果您的執行個體未達到其輸送量或 IOPS 限制，但出現高延遲和高佇列長度，則執行個體可能發生微高載。若要解決此問題，請參閱如何識別我的 Amazon EBS 磁碟區是否發生微高載，然後防止這種情況發生？此外，請確認 Enhanced Monitoring 已開啟，然後將精細度設為 1 秒，以識別微高載是否為問題所在。

最佳化不良查詢

若要最佳化不良查詢，請採取以下動作：

• 若要檢查在高 DiskQueueDepth 時間區段執行的查詢類型，請使用 Performance Insights。
• 若要產生查詢執行計畫，請使用 EXPLAIN 來找出最佳化機會。如需更多資訊，請參閱 PostgreSQL 網站上的 EXPLAIN。
• 檢查是否存在完整資料表掃描、效率不佳的聯結或遺漏的索引，因為這些情況可能導致過多 I/O。