IPC：平行等待事件 - Amazon Relational Database Service
支援的引擎版本Context等待時間增加的可能原因動作

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

IPC：平行等待事件

以下IPC:parallel wait events指出工作階段正在等待與平行查詢執行操作相關的程序間通訊。

  • IPC:BgWorkerStartup - 程序正在等待平行工作者程序完成其啟動序列。初始化工作者以進行平行查詢執行時會發生這種情況。

  • IPC:BgWorkerShutdown - 程序正在等待平行工作者程序完成其關機順序。這會在平行查詢執行的清除階段期間發生。

  • IPC:ExecuteGather - 程序正在等待在查詢執行期間從平行工作者程序接收資料。當領導程序需要從工作者收集結果時，就會發生這種情況。

  • IPC:ParallelFinish - 程序正在等待平行工作者完成其執行並報告其最終結果。這會在平行查詢執行的完成階段發生。

支援的引擎版本

所有版本的 Aurora PostgreSQL 都支援此等待事件資訊。

Context

PostgreSQL 中的平行查詢執行涉及多個程序共同處理單一查詢。當查詢判斷為適合平行處理時，領導者程序會根據max_parallel_workers_per_gather參數設定，與一或多個平行工作者程序協調。領導程序會將工作分割給工作者，每個工作者都會獨立處理其部分的資料，並將結果收集回領導程序。

注意

每個平行工作者會以單獨的程序運作，其資源需求類似於完整的使用者工作階段。這表示與非平行查詢相比，具有 4 個工作者的平行查詢最多可耗用 5 倍的資源 (CPU、記憶體、I/O 頻寬），因為領導程序和每個工作者程序都會維持自己的資源配置。例如， 等設定work_mem會個別套用至每個工作者，可能會將總記憶體用量乘以所有程序。

平行查詢架構包含三個主要元件：

  • 領導者程序：啟動平行操作、分割工作負載並與工作者程序協調的主要程序。

  • 工作者程序：平行執行部分查詢的背景程序。

  • 收集/收集合併：將多個工作者程序的結果合併回領導者的操作

在平行執行期間，程序需要透過程序間通訊 (IPC) 機制彼此通訊。這些 IPC 等待事件會在不同階段發生：

  • 工作者啟動：正在初始化平行工作者時

  • 資料交換：工作者處理資料並將結果傳送給領導者時

  • 工作者關閉：平行執行完成且工作者終止時

  • 同步點：當程序需要協調或等待其他程序完成其任務時

了解這些等待事件對於診斷與平行查詢執行相關的效能問題至關重要，尤其是在可能同時執行多個平行查詢的高並行環境中。

等待時間增加的可能原因

有幾個因素可能會導致平行相關的 IPC 等待事件增加：

平行查詢的高並行

當許多平行查詢同時執行時，可能會導致資源爭用並增加 IPC 操作的等待時間。這在具有高交易量或分析工作負載的系統中特別常見。

次佳的平行查詢計畫

如果查詢規劃器選擇效率不佳的平行計畫，可能會導致工作者之間不必要的平行化或工作分佈不佳。這可能會導致 IPC 等待增加，特別是 IPC:ExecuteGather和 IPC:ParallelFinish事件。這些規劃問題通常來自過時的統計資料和資料表/索引膨脹。

頻繁啟動和關閉平行工作者

經常啟動和終止平行工作者的短期查詢可能會導致 IPC:BgWorkerStartup和 IPC:BgWorkerShutdown事件增加。這通常在具有許多小型、可平行化查詢的 OLTP 工作負載中出現。

資源限制

有限的 CPU、記憶體或 I/O 容量可能會導致平行執行的瓶頸，進而增加所有 IPC 事件的等待時間。例如，如果 CPU 飽和，工作者程序可能需要更長的時間才能啟動或處理其工作部分。

複雜的查詢結構

具有多層平行處理的查詢 （例如，平行聯結後接平行彙總） 可能會導致更複雜的 IPC 模式，並可能增加等待時間，尤其是IPC:ExecuteGather事件。

大型結果集

產生大型結果集的查詢可能會導致IPC:ExecuteGather等待時間增加，因為領導者程序花費更多時間收集和處理工作者程序的結果。

了解這些因素有助於診斷和解決與 Aurora PostgreSQL 中平行查詢執行相關的效能問題。

動作

當您看到與平行查詢相關的等待時，通常表示後端程序正在協調或等待平行工作者程序。這些等待在平行計劃執行期間很常見。您可以透過監控平行工作者用量、檢閱參數設定，以及調校查詢執行和資源配置，來調查和減輕這些等待的影響。

分析無效率平行處理的查詢計劃

平行查詢執行通常會導致系統不穩定、CPU 峰值和無法預測的查詢效能差異。徹底分析平行處理是否實際改善您的特定工作負載至關重要。使用 EXPLAIN ANALYZE 檢閱平行查詢執行計畫。

在工作階段層級暫時停用平行處理，以比較計劃效率：


SET max_parallel_workers_per_gather = 0;
EXPLAIN ANALYZE <your_query>;

重新啟用平行處理並比較：


RESET max_parallel_workers_per_gather;
EXPLAIN ANALYZE <your_query>;

如果停用平行處理會產生更好或更一致的結果，請考慮使用 SET 命令在工作階段層級停用特定查詢。為了獲得更廣泛的影響，您可能想要透過調整資料庫參數群組中的相關參數，在執行個體層級停用平行處理。如需詳細資訊，請參閱修改 Amazon RDS 中資料庫參數群組中的參數。

監控平行查詢用量

使用下列查詢來取得平行查詢活動和容量的可見性：

檢查作用中的平行工作者程序：


SELECT
    COUNT(*)
FROM
    pg_stat_activity
WHERE
    backend_type = 'parallel worker';

此查詢顯示作用中平行工作者程序的數量。高值可能表示您的 `max_parallel_workers` 已設定高值，建議您考慮減少該值。

檢查並行平行查詢：


SELECT
    COUNT(DISTINCT leader_pid)
FROM
    pg_stat_activity
WHERE
    leader_pid IS NOT NULL;

此查詢會傳回已啟動平行查詢的不同領導程序數目。此處的高數字表示多個工作階段同時執行平行查詢，這可能會增加對 CPU 和記憶體的需求。

檢閱和調整平行查詢設定

檢閱下列參數，以確保它們與您的工作負載一致：

  • max_parallel_workers：所有工作階段的平行工作者總數。

  • max_parallel_workers_per_gather：每個查詢的工作者上限。

對於 OLAP 工作負載，增加這些值可以改善效能。對於 OLTP 工作負載，通常偏好較低的值。


SHOW max_parallel_workers;
SHOW max_parallel_workers_per_gather;

最佳化資源配置

監控 CPU 使用率，如果持續很高，且您的應用程式受益於平行查詢，請考慮調整 vCPUs 數量。確保有充足的記憶體可供平行操作使用。

  • 使用績效詳情指標來判斷系統是否受限於 CPU。

  • 每個平行工作者都會使用自己的 work_mem。確保總記憶體用量在執行個體限制內。

平行查詢可能會耗用比非平行查詢更多的資源，因為每個工作者程序都是完全獨立的程序，對系統的影響與額外的使用者工作階段大致相同。選擇此設定的值時，以及設定控制資源使用率的其他設定時，應考慮這一點，例如 work_mem。如需詳細資訊，請參閱 PostgreSQL 文件。等資源限制work_mem會個別套用至每個工作者，這表示所有程序的總使用率可能遠高於任何單一程序。

如果您的工作負載高度平行化，請考慮增加 vCPUs 或調校記憶體參數。

調查連線管理

如果連線耗盡，請檢閱應用程式連線集區策略。如果尚未使用，請考慮在應用程式層級實作連線集區。

檢閱和最佳化維護操作

協調索引建立和其他維護任務，以防止資源爭用。請考慮在離峰時間排程這些操作。避免在高使用者查詢負載期間排程大量維護 （例如平行索引組建）。這些操作可能會耗用平行工作者，並影響定期查詢的效能。