Eventos de espera IPC:parallel - Amazon Aurora
Versiones del motor admitidasContextoCausas probables del aumento del tiempo de esperaAcciones

Eventos de espera IPC:parallel

Los siguientes IPC:parallel wait events indican que una sesión está esperando una comunicación entre procesos relacionada con operaciones de ejecución de consultas en paralelo.

  • IPC:BgWorkerStartup: un proceso está esperando a que un proceso de trabajo paralelo complete la secuencia de inicio. Esto sucede al inicializar los procesos de trabajo para la ejecución de consultas en paralelo.

  • IPC:BgWorkerShutdown: un proceso está esperando a que un proceso de trabajo paralelo complete la secuencia de apagado. Esto sucede durante la fase de limpieza de la ejecución de consultas en paralelo.

  • IPC:ExecuteGather: un proceso está esperando recibir datos de procesos de trabajo paralelos durante la ejecución de consultas. Esto ocurre cuando el proceso líder necesita recopilar resultados de los procesos de trabajo.

  • IPC:ParallelFinish: un proceso está esperando a que los procesos de trabajo paralelos finalicen la ejecución y comuniquen los resultados finales. Esto sucede durante la fase de finalización de la ejecución de consultas en paralelo.

Versiones del motor admitidas

Esta información de eventos de espera es compatible con todas las versiones de Aurora PostgreSQL.

Contexto

La ejecución de consultas en paralelo en PostgreSQL implica que varios procesos trabajan juntos para procesar una sola consulta. Cuando se determina que una consulta es adecuada para la paralelización, un proceso líder coordina uno o varios procesos de trabajo paralelos en función de la configuración del parámetro max_parallel_workers_per_gather. El proceso líder divide el trabajo entre los procesos de trabajo, cada proceso de trabajo procesa la parte de los datos de forma independiente y los resultados se recopilan de nuevo en el proceso líder.

nota

Cada proceso de trabajo paralelo funciona como un proceso independiente con requisitos de recursos similares a los de una sesión de usuario completa. Esto significa que una consulta en paralelo con cuatro procesos de trabajo puede consumir hasta cinco veces más recursos (CPU, memoria y ancho de banda de E/S) que una consulta que no sea en paralelo, ya que tanto el proceso líder como cada proceso de trabajo mantienen las asignaciones de recursos propias. Por ejemplo, la configuración como work_mem se aplica individualmente a cada proceso de trabajo, lo que puede multiplicar el uso total de memoria en todos los procesos.

La arquitectura de consulta en paralelo consta de tres componentes principales:

  • Proceso líder: el proceso principal que inicia la operación paralela, divide la carga de trabajo y coordina los procesos de trabajo.

  • Procesos de trabajo: procesos en segundo plano que ejecutan partes de la consulta en paralelo.

  • Recopilación/combinación de recopilaciones: operaciones que combinan los resultados de varios procesos de trabajo y los devuelven al líder

Durante la ejecución en paralelo, los procesos deben comunicarse entre sí a través de mecanismos de comunicación entre procesos (IPC). Estos eventos de espera IPC se producen durante diferentes fases:

  • Inicio de procesos de trabajo: cuando se inicializan los procesos de trabajo paralelos

  • Intercambio de datos: cuando los procesos de trabajo procesan datos y envían los resultados al líder

  • Cierre de procesos de trabajo: cuando finaliza la ejecución paralela y se terminan los procesos de trabajo

  • Puntos de sincronización: cuando los procesos necesitan coordinarse o esperar a que otros procesos completen las tareas

Comprender estos eventos de espera es fundamental para diagnosticar problemas de rendimiento relacionados con la ejecución de consultas en paralelo, sobre todo en entornos de alta simultaneidad en los que pueden ejecutarse varias consultas en paralelo al mismo tiempo.

Causas probables del aumento del tiempo de espera

Hay varios factores que pueden contribuir a un aumento de los eventos de espera IPC relacionados con la ejecución en paralelo:

Alta simultaneidad de consultas en paralelo

Cuando se ejecutan muchas consultas en paralelo al mismo tiempo, puede producirse un conflicto de recursos y un aumento de los tiempos de espera para las operaciones IPC. Esto es muy habitual en sistemas con grandes volúmenes de transacciones o cargas de trabajo de análisis.

Planes de consultas en paralelo poco óptimos

Si el planificador de consultas elige planes paralelos ineficientes, puede dar lugar a una paralelización innecesaria o a una distribución deficiente del trabajo entre los procesos de trabajo. Esto puede provocar un aumento de las esperas de IPC, sobre todo para los eventos IPC:ExecuteGather e IPC:ParallelFinish. Estos problemas de planificación suelen deberse a estadísticas obsoletas y a la saturación de tablas e índices.

Inicio y apagado frecuentes de procesos de trabajo paralelos

Las consultas de corta duración que inician y terminan con frecuencia procesos de trabajo paralelos pueden provocar un aumento de los eventos IPC:BgWorkerStartup y IPC:BgWorkerShutdown. Esto se observa a menudo en cargas de trabajo OLTP con muchas consultas pequeñas y paralelizables.

Limitaciones de recursos

La capacidad limitada de CPU, memoria o E/S puede provocar cuellos de botella en la ejecución paralela, lo que aumenta los tiempos de espera en todos los eventos IPC. Por ejemplo, si la CPU está saturada, los procesos de trabajo pueden tardar más en iniciarse o en procesar la parte del trabajo.

Estructuras de consultas complejas

Las consultas con varios niveles de paralelismo (por ejemplo, uniones paralelas seguidas de agregaciones paralelas) pueden dar lugar a patrones IPC más complejos y a un aumento de los tiempos de espera, sobre todo para eventos IPC:ExecuteGather.

Grandes conjuntos de resultados

Las consultas que producen conjuntos de resultados grandes pueden provocar un aumento de los tiempos de espera de IPC:ExecuteGather, ya que el proceso líder dedica más tiempo a recopilar y procesar los resultados de los procesos de trabajo.

Comprender estos factores puede ayudar a diagnosticar y resolver problemas de rendimiento relacionados con la ejecución de consultas paralelas en Aurora PostgreSQL.

Acciones

Cuando ve esperas relacionadas con consultas en paralelo, normalmente significa que un proceso backend está coordinando o esperando procesos de trabajo paralelos. Estas esperas son comunes durante la ejecución de planes paralelos. Puede investigar y mitigar el impacto de estas esperas mediante la supervisión del uso de procesos de trabajo paralelos, la revisión de la configuración de los parámetros y el ajuste de la ejecución de las consultas y asignación de recursos.

Análisis de los planes de consulta en busca de paralelismo ineficiente

La ejecución de consultas en paralelo a menudo puede provocar inestabilidad del sistema, picos de CPU y variaciones impredecibles en el rendimiento de las consultas. Es fundamental analizar a fondo si el paralelismo mejora realmente la carga de trabajo específica. Utilice EXPLAIN ANALYZE para revisar los planes de ejecución de consultas en paralelo.

Deshabilite temporalmente el paralelismo de la sesión para comparar la eficiencia del plan:


SET max_parallel_workers_per_gather = 0;
EXPLAIN ANALYZE <your_query>;

Vuelva a habilitar el paralelismo y compare:


RESET max_parallel_workers_per_gather;
EXPLAIN ANALYZE <your_query>;

Si al deshabilitar el paralelismo se obtienen resultados mejores o más coherentes, considere la posibilidad de deshabilitarlo para consultas específicas de sesión mediante comandos SET. Para lograr un impacto más amplio, es posible que desee deshabilitar el paralelismo de instancia mediante el ajuste de los parámetros pertinentes en el clúster o el grupo de parámetros de instancia. Para obtener más información, consulte Parámetros de Amazon Aurora PostgreSQL..

Supervisión del uso de consultas en paralelo

Utilice las siguientes consultas para obtener visibilidad de la actividad y la capacidad de las consultas en paralelo:

Compruebe los procesos de trabajo paralelos activos:


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

Esta consulta muestra el número de procesos de trabajo paralelos activos. Un valor alto puede indicar que “max_parallel_workers” se ha configurado con un valor alto y es recomendable que considere la posibilidad de reducirlo.

Compruebe las consultas en paralelo simultáneas:


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

Esta consulta devuelve el número de procesos líderes distintos que han iniciado consultas en paralelo. Un número alto indica que varias sesiones están ejecutando consultas en paralelo simultáneamente, lo que puede aumentar la demanda de CPU y memoria.

Revisión y ajuste de la configuración de consultas en paralelo

Revise los siguientes parámetros para asegurarse de que se ajustan a la carga de trabajo:

  • max_parallel_workers: número total de procesos de trabajo paralelos en todas las sesiones.

  • max_parallel_workers_per_gather: número máximo de procesos de trabajo por consulta.

Para cargas de trabajo OLAP, aumentar estos valores puede mejorar el rendimiento. Para cargas de trabajo OLTP, por lo general, se prefieren valores más bajos.


SHOW max_parallel_workers;
SHOW max_parallel_workers_per_gather;

Optimización de la asignación de recursos

Supervise la utilización de la CPU y considere la posibilidad de ajustar el número de vCPU si es coherentemente alto y si la aplicación se beneficia de las consultas en paralelo. Asegúrese de que haya memoria suficiente para las operaciones paralelas.

  • Utilice las métricas de Información de rendimiento para determinar si el sistema está limitado por la CPU.

  • Cada proceso de trabajo paralelo utiliza un work_mem propio. Asegúrese de que el uso total de memoria se encuentra dentro de los límites de la instancia.

Las consultas en paralelo pueden consumir muchos más recursos que las consultas que no son en paralelo, ya que cada proceso de trabajo es un proceso completamente independiente que tiene aproximadamente el mismo impacto en el sistema que una sesión de usuario adicional. Esto debe tenerse en cuenta al elegir un valor para esta configuración, así como al configurar otras opciones que controlan la utilización de recursos, como work_mem. Para obtener más información, consulte la documentación de PostgreSQL. Los límites de recursos, como work_mem, se aplican individualmente a cada proceso de trabajo, lo que significa que la utilización total puede ser mucho mayor en todos los procesos de lo que sería normalmente para un solo proceso.

Considere la posibilidad de aumentar las vCPU o ajustar los parámetros de memoria si la carga de trabajo está muy paralelizada.

Investigación de la administración de conexiones

Si se agota la conexión, revise las estrategias de agrupación de conexiones de la aplicación. Considere la posibilidad de implementar la agrupación de conexiones de aplicación si aún no se utiliza.

Revisión y optimización de las operaciones de mantenimiento

Coordine la creación de índices y otras tareas de mantenimiento para evitar la contienda por los recursos. Considere la posibilidad de programar estas operaciones durante las horas de menor actividad. Evite programar tareas de mantenimiento intensas (por ejemplo, creaciones de índices en paralelo) durante periodos de alta carga de consultas de los usuarios. Estas operaciones pueden consumir procesos de trabajo paralelos y afectar al rendimiento de las consultas habituales.

Uso de la administración de planes de consulta (QPM)

En Aurora PostgreSQL, la característica de administración de planes de consulta (QPM) está diseñada para garantizar la adaptabilidad y la estabilidad de los planes, independientemente de los cambios en el entorno de la base de datos que puedan causar la regresión del plan de consulta. Para obtener más información, consulte Descripción general de la administración de planes de consultas en Aurora PostgreSQL. QPM proporciona cierto control sobre el optimizador. Revise los planes aprobados en QPM para asegurarse de que se ajustan a la configuración de paralelismo actual. Actualice o elimine los planes obsoletos que puedan estar forzando una ejecución paralela poco óptima.

También puede corregir los planes con pg_hint_plan. Para obtener más información, consulte Corrección de planes mediante pg_hint_plan. Puede utilizar la sugerencia denominada Parallel para forzar la ejecución paralela. Para obtener más información, consulte Sugerencias para planes paralelos.