LWLock:lock_manager (LWLock:lockmanager) - Amazon Relational Database Service
Versiones del motor admitidasContextoCausas probables del aumento de las esperasAcciones

LWLock:lock_manager (LWLock:lockmanager)

Este evento ocurre cuando el motor de RDS para PostgreSQL mantiene el área de memoria del bloqueo compartido para asignar, verificar y desasignar un bloqueo cuando no es posible un bloqueo de ruta rápida.

Versiones del motor admitidas

La información del evento de espera es relevante para RDS para PostgreSQL versión 9.6 y posteriores. Para las versiones de RDS para PostgreSQL anteriores a la 13, el nombre de este evento de espera es LWLock:lock_manager. Para la versión 13 de RDS para PostgreSQL y posteriores, el nombre de este evento de espera es LWLock:lockmanager.

Contexto

Cuando se emite una instrucción SQL, RDS para PostgreSQL registra bloqueos para proteger la estructura, los datos y la integridad de la base de datos durante las operaciones simultáneas. El motor puede lograr este objetivo con un bloqueo de ruta rápido o con un bloqueo de ruta que no es rápido. Un bloqueo de ruta que no es rápido es más caro y crea más sobrecarga que un bloqueo de ruta rápido.

Bloqueo rápido de la ruta

Para reducir la sobrecarga de los bloqueos que se toman y liberan con frecuencia, pero que rara vez entran en conflicto, los procesos del backend pueden utilizar el bloqueo de ruta rápido. La base de datos utiliza este mecanismo para los bloqueos que cumplen los siguientes criterios:

  • Utilizan el método de bloqueo DEFAULT.

  • Representan un bloqueo en una relación de la base de datos y no en una relación compartida.

  • Son bloqueos débiles que probablemente no entren en conflicto.

  • El motor puede verificar rápidamente que no pueden existir bloqueos conflictivos.

El motor no puede utilizar el bloqueo de ruta rápida cuando se cumple alguna de las siguientes condiciones:

  • El bloqueo no cumple los criterios anteriores.

  • No hay más ranuras disponibles para el proceso de backend.

Para ajustar las consultas para que se bloqueen rápidamente, puede utilizar la siguiente consulta.

SELECT count(*), pid, mode, fastpath
  FROM pg_locks
 WHERE fastpath IS NOT NULL
 GROUP BY 4,3,2
 ORDER BY pid, mode;
 count | pid  |      mode       | fastpath
-------+------+-----------------+----------
16 | 9185 | AccessShareLock | t
336 | 9185 | AccessShareLock | f
1 | 9185 | ExclusiveLock   | t

La siguiente consulta muestra solo el total de la base de datos.

SELECT count(*), mode, fastpath
  FROM pg_locks
 WHERE fastpath IS NOT NULL
 GROUP BY 3,2
 ORDER BY mode,1;
count |      mode       | fastpath
-------+-----------------+----------
16 | AccessShareLock | t
337 | AccessShareLock | f
1 | ExclusiveLock   | t
(3 rows)

Para más información sobre el bloqueo de ruta rápida, consulte fast path en el README del administrador de bloqueos de PostgreSQL y pg-locks en la documentación de PostgreSQL.

Ejemplo de un problema de escalado para el administrador de bloqueos

En este ejemplo, una tabla con el nombre purchases almacena cinco años de datos, particionados por día. Cada partición tiene dos índices. Se produce la siguiente secuencia de eventos:

  1. Se consultan los datos de muchos días, lo que requiere que la base de datos lea muchas particiones.

  2. La base de datos crea una entrada de bloqueo para cada partición. Si los índices de las particiones forman parte de la ruta de acceso del optimizador, la base de datos también crea una entrada de bloqueo para ellos.

  3. Cuando el número de entradas de bloqueo solicitadas para el mismo proceso backend es superior a 16, que es el valor FP_LOCK_SLOTS_PER_BACKEND, el administrador de bloqueos utiliza el método de bloqueo de ruta no rápida.

Las aplicaciones modernas pueden tener cientos de sesiones. Si las sesiones simultáneas consultan la base de datos principal sin una poda adecuada de las particiones, la base de datos puede crear cientos o incluso miles de bloqueos de ruta no rápida. Normalmente, cuando esta simultaneidad es mayor que el número de vCPU, aparece el evento de espera LWLock:lock_manager.

nota

El evento de espera LWLock:lock_manager no está relacionado con el número de particiones o índices en un esquema de base de datos. En cambio, está relacionado con el número de bloqueos de rutas no rápidas que la base de datos debe controlar.

Causas probables del aumento de las esperas

Cuando el evento de espera LWLock:lock_manager ocurre más de lo normal, lo que posiblemente indica un problema de rendimiento, las causas más probables de los picos repentinos son las siguientes:

  • Las sesiones activas simultáneas ejecutan consultas que no utilizan bloqueos de ruta rápida. Estas sesiones también exceden el máximo de vCPU.

  • Un gran número de sesiones activas simultáneas acceden a una tabla con muchas particiones. Cada partición tiene múltiples índices.

  • La base de datos está experimentando una tormenta de conexiones. De forma predeterminada, algunas aplicaciones y software de grupo de conexiones crean más conexiones cuando la base de datos es lenta. Esta práctica empeora el problema. Ajuste el software de grupo de conexiones para que no se produzcan tormentas de conexiones.

  • Un gran número de sesiones consultan una tabla principal sin borrar particiones.

  • Un lenguaje de definición de datos (DDL), un lenguaje de manipulación de datos (DML) o un comando de mantenimiento bloquea exclusivamente una relación ocupada o tuplas a las que se accede o modifica con frecuencia.

Acciones

Si se produce el evento de espera CPU, no indica necesariamente un problema de rendimiento. Responda a este evento solo cuando el rendimiento disminuya y este evento de espera domine la carga de la base de datos.

Utilizar la poda de particiones

La poda de particiones es una estrategia de optimización de consultas para tablas partidas de forma declarativa que excluye las particiones innecesarias de los escaneos de tablas, lo que mejora el rendimiento. La poda de particiones está activada de forma predeterminada. Si está desactivada, actívela de la siguiente manera.

SET enable_partition_pruning = on;

Las consultas pueden aprovechar la poda de particiones cuando la cláusula WHERE contiene la columna que se utiliza para la partición. Para más información, consulte Partition Pruningc en la documentación de PostgreSQL.

Eliminar índices innecesarios

Es posible que la base de datos contenga índices que no se utilicen o que se utilicen muy poco. Si es así, considere eliminarlos. Haga una de estas dos operaciones:

  • Aprenda a encontrar índices innecesarios al leer Índices no utilizados en el wiki de PostgreSQL.

  • Ejecute PG Collector. Este script SQL recopila información de la base de datos y la presenta en un informe HTML consolidado. Verifique la sección “Índices no utilizados”. Para más información, consulte pg-collector en el repositorio GitHub de AWS Labs.

Ajustar sus consultas para el bloqueo rápido de rutas

Para averiguar si las consultas utilizan el bloqueo de ruta rápida, consulte la columna fastpath en la tabla pg_locks. Si las consultas no utilizan el bloqueo de ruta rápida, intente reducir el número de relaciones por consulta a menos de 16.

Ajustar otros eventos de espera

Si LWLock:lock_manager es el primero o el segundo en la lista de esperas principales, verifique si los siguientes eventos de espera también aparecen en la lista:

  • Lock:Relation

  • Lock:transactionid

  • Lock:tuple

Si los eventos anteriores aparecen en primer lugar en la lista, considere la posibilidad de ajustar estos eventos de espera en primer lugar. Estos eventos pueden ser un controlador para LWLock:lock_manager.

Reducir los cuellos de botella del hardware

Es posible que tenga un cuello de botella en el hardware, como el agotamiento de la CPU o el uso máximo de su ancho de banda de Amazon EBS. En estos casos, considere la posibilidad de reducir los cuellos de botella de hardware. Considere las siguientes acciones:

  • Escalar verticalmente la clase de instancia.

  • Optimizar las consultas que consumen grandes cantidades de CPU y memoria.

  • Cambiar la lógica de su aplicación.

  • Archivar los datos.

Para más información sobre la CPU, memoria y ancho de banda de red de EBS, consulte Tipos de instancias de Amazon RDS.

Utilizar un grupo de conexiones

Si el número total de conexiones activas supera el máximo de vCPU, más procesos del sistema operativo requieren CPU de lo que su tipo de instancia puede admitir. En este caso, considere la posibilidad de utilizar o ajustar un grupo de conexiones. Para más información sobre las vCPU de su tipo de instancia, consulte Tipos de instancias de Amazon RDS.

Para más información sobre la agrupación de conexiones, consulte los siguientes recursos:

Actualización de la versión de RDS para PostgreSQL

Si la versión actual de RDS para PostgreSQL es inferior a la 12, actualice a la versión 12 o posterior. Las versiones 12 y posteriores de PostgreSQL tienen un mecanismo de partición mejorado. Para más información sobre la versión 12, consulte las Notas de la versión 12.0 de PostgreSQL. Para más información sobre la actualización de RDS para PostgreSQL, consulte Actualización del motor de base de datos de PostgreSQL para Amazon RDS.