IPC:parallel 대기 이벤트

다음 IPC:parallel wait events는 세션이 병렬 쿼리 실행 작업과 관련된 프로세스 간 통신을 기다리고 있음을 나타냅니다.

지원되는 엔진 버전

이 대기 이벤트 정보는 모든 Aurora PostgreSQL 버전에서 지원됩니다.

컨텍스트

PostgreSQL에서 병렬 쿼리를 실행할 때는 단일 쿼리를 처리하기 위해 여러 프로세스가 함께 작동합니다. 쿼리가 병렬화에 적합한 것으로 확인되면 리더 프로세스는 max_parallel_workers_per_gather 파라미터 설정에 따라 하나 이상의 병렬 워커 프로세스와 조정합니다. 리더 프로세스는 워커들을 대상으로 작업을 나누고, 각 워커는 각자가 맡은 데이터를 독립적으로 처리하며, 결과는 리더 프로세스로 다시 수집됩니다.

병렬 쿼리 아키텍처는 세 가지 주요 구성 요소로 구성됩니다.

병렬 실행 중에 프로세스는 프로세스 간 통신(IPC) 메커니즘을 통해 서로 통신해야 합니다. 이러한 IPC 대기 이벤트는 여러 단계에서 발생합니다.

이러한 대기 이벤트를 이해하는 것은 병렬 쿼리 실행과 관련된 성능 문제를 진단하는 데 매우 중요합니다. 특히 여러 병렬 쿼리가 동시에 실행될 수 있는 동시성이 높은 환경에서는 더욱 그렇습니다.

대기 증가의 가능한 원인

병렬 관련 IPC 대기 이벤트 증가에 여러 요인이 기여할 수 있습니다.

이러한 요인을 이해하면 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 Aurora PostgreSQL parameters 섹션을 참조하세요.

병렬 쿼리 사용량 모니터링

다음 쿼리를 사용하여 병렬 쿼리 활동 및 용량에 대한 가시성을 확보합니다.

활성 병렬 워커 프로세스를 확인합니다.

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와 메모리에 대한 수요가 증가할 수 있습니다.

병렬 쿼리 설정 검토 및 조정

다음 파라미터를 검토하여 워크로드에 적절한지 확인합니다.

OLAP 워크로드의 경우 이러한 값을 늘리면 성능이 향상될 수 있습니다. OLTP 워크로드의 경우 일반적으로 낮은 값이 선호됩니다.

SHOW max_parallel_workers;
SHOW max_parallel_workers_per_gather;
            

리소스 할당 최적화

CPU 사용률을 모니터링하고, 사용률이 지속적으로 높고 애플리케이션이 병렬 쿼리의 이점을 누릴 수 있는 경우 vCPU 수를 조정하는 것이 좋습니다. 병렬 작업에 적절한 메모리를 사용할 수 있는지 확인합니다.

병렬 쿼리는 비병렬 쿼리보다 훨씬 많은 리소스를 사용할 수 있습니다. 각 워커 프로세스는 시스템에 추가 사용자 세션과 거의 동일한 영향을 미치는 완전히 별개의 프로세스이기 때문입니다. 이 설정에 대한 값을 선택할 때, 그리고 work_mem과 같이 리소스 사용률을 제어하는 다른 설정을 구성할 때 이 점을 고려해야 합니다. 자세한 내용은 PostgreSQL 설명서를 참조하세요. work_mem과 같은 리소스 한도는 각 워커에 개별적으로 적용됩니다. 즉, 전체 사용률이 단일 프로세스보다 모든 프로세스에서 훨씬 높을 수 있습니다.

워크로드가 심하게 병렬화된 경우 vCPU를 늘리거나 메모리 파라미터를 조정하는 것이 좋습니다.

연결 관리 조사

연결 소진이 발생하는 경우 애플리케이션 연결 풀링 전략을 검토합니다. 아직 사용하지 않는 경우 애플리케이션 수준에서 연결 풀링을 구현하는 것이 좋습니다.

유지 관리 작업 검토 및 최적화

인덱스 생성 및 기타 유지 관리 작업을 조정하여 리소스 경합을 방지합니다. 이러한 작업은 사용량이 적은 시간으로 예약하는 것이 좋습니다. 사용자 쿼리 로드가 많은 기간에는 과도한 유지 관리(예: 병렬 인덱스 빌드)를 예약하지 마세요. 이러한 작업은 병렬 워커를 소비하고 정규 쿼리의 성능에 영향을 미칠 수 있습니다.

쿼리 계획 관리(QPM) 활용

Aurora PostgreSQL에서 쿼리 계획 관리(QPM) 기능은 쿼리 계획 회귀를 유발할 수 있는 데이터베이스 환경 변경과 관계없이 계획 적응성과 안정성을 보장하도록 설계되었습니다. 자세한 내용은 Aurora PostgreSQL 쿼리 계획 관리 개요 섹션을 참조하세요. QPM에서 옵티마이저에 대한 몇 가지 제어 기능을 제공합니다. QPM에서 승인된 계획을 검토하여 현재 병렬 처리 설정과 일치하는지 확인하세요. 최적화되지 않은 병렬 실행을 강제 적용할 수 있는 오래된 계획을 업데이트하거나 제거하세요.

pg_hint_plan을 사용하여 계획을 수정할 수도 있습니다. 자세한 내용은 pg_hint_plan을 사용하여 계획 수정 섹션을 참조하세요. Parallel이라는 힌트를 사용하여 병렬 실행을 강제 적용할 수 있습니다. 자세한 내용은 Hints for parallel plans을 참조하세요.