IPC:ProcArrayGroupUpdate
El evento IPC:ProcArrayGroupUpdate se produce cuando una sesión está esperando a que líder de grupo actualice el estado de la transacción al final de esa operación. Mientras PostgreSQL generalmente asocia los eventos de espera de tipo IPC con las operaciones de consulta paralelas, este evento de espera en particular no es específico de las consultas paralelas.
Versiones del motor admitidas
Esta información de eventos de espera es compatible con todas las versiones de Aurora PostgreSQL.
Contexto
Descripción de la matriz de procesos: la matriz de procesos (proc) es una estructura de memoria compartida en PostgreSQL. Contiene información sobre todos los procesos en ejecución, incluidos los detalles de las transacciones. Al finalizar la transacción (COMMIT o ROLLBACK), el ProcArray debe actualizarse para reflejar el cambio y borrar el ID de transacción de la matriz. La sesión que intente finalizar su transacción debe adquirir un bloqueo exclusivo en el ProcArray. Esto evita que otros procesos obtengan bloqueos compartidos o exclusivos sobre ella.
Mecanismo de actualización grupal: al realizar un COMMIT o ROLLBACK, si un proceso de backend no puede obtener un ProcArrayLock en modo exclusivo, actualiza un campo especial llamado ProcArrayGroupMember. Esto agrega la transacción a la lista de sesiones que pretenden finalizar. A continuación, este proceso de backend se suspende y el tiempo que duerme se configura como el evento de espera ProcArrayGroupUpdate. El primer proceso de ProcArray con ProcArrayGroupMember, denominado proceso de líder, adquiere el ProcArrayLock en modo exclusivo. A continuación, borra la lista de procesos en espera de ser liquidados por el ID de transacción del grupo. Una vez finalizada esta operación, el líder libera el ProcArrayLock y activa todos los procesos de la lista y les notifica que la transacción se ha completado.
Causas probables del aumento de las esperas
Cuantos más procesos estén en ejecución, más tiempo conservará el líder un ProcArrayLock en modo exclusivo. En consecuencia, cuantas más transacciones de escritura acaben en un escenario de actualización grupal, más se provocará una posible acumulación de procesos en espera en el evento de espera ProcArrayGroupUpdate. En la vista de SQL principal de información de base de datos, verá que COMMIT es la instrucción que contiene la mayor parte del tiempo de espera. Esto es de esperar, pero requerirá una investigación más profunda del SQL de escritura específico que se está ejecutando para determinar qué medidas se deben tomar.
Acciones
Recomendamos diferentes acciones en función de las causas del evento de espera. Identifique eventos de IPC:ProcArrayGroupUpdate mediante Información de rendimiento de Amazon RDS o la consulta de la vista del sistema PostgreSQL pg_stat_activity.
Temas
Supervisión de las operaciones de confirmación y reversión de transacciones
Supervise las confirmaciones y las reversiones: un mayor número de confirmaciones y reversiones puede aumentar la presión sobre ProcArray. Por ejemplo, si una instrucción SQL comienza a producir errores debido al aumento de las infracciones de claves duplicadas, es posible que se produzca un aumento de las reversiones, lo que puede aumentar la contención de ProcArray y la sobrecarga de tablas.
La información de base de datos de Amazon RDS proporciona las métricas de PostgreSQL xact_commit y xact_rollback para informar del número de confirmaciones y reversiones por segundo.
Reducción de la simultaneidad
Transacciones por lotes: siempre que sea posible, agrupe las operaciones en transacciones individuales para reducir las operaciones de confirmación o reversión.
Limite la simultaneidad: reduzca la cantidad de transacciones activas simultáneamente para evitar la contención de bloqueos en ProcArray. Si bien requerirá algunas pruebas, reducir el número total de conexiones simultáneas puede reducir la contención y mantener el rendimiento.
Implementación de la agrupación de conexiones
Soluciones de agrupación de conexiones: utilice la agrupación de conexiones para administrar las conexiones de bases de datos de manera eficiente, lo que reduce la cantidad total de backends y, por lo tanto, la carga de trabajo de ProcArray. Si bien requerirá algunas pruebas, reducir el número total de conexiones simultáneas puede reducir la contención y mantener el rendimiento.
Para obtener más información, consulte Agrupación de conexiones para Aurora PostgreSQL.
Reduzca las tormentas de conexiones: del mismo modo, un patrón de creación y terminación frecuentes de conexiones genera una presión adicional sobre ProcArray. Al reducir este patrón, se reduce la contención general.
