Lock:Relation
El evento Lock:Relation ocurre cuando una consulta espera adquirir un bloqueo en una tabla o vista (relación) que se encuentra bloqueada por otra transacción.
Versiones del motor admitidas
Esta información de eventos de espera es compatible con todas las versiones de RDS para PostgreSQL.
Contexto
La mayoría de los comandos de PostgreSQL utilizan implícitamente bloqueos para controlar el acceso concurrente a los datos de las tablas. También puede utilizar estos bloqueos explícitamente en su código de aplicación con el comando LOCK. Muchos modos de bloqueo no son compatibles entre sí, y pueden bloquear las transacciones cuando intentan acceder al mismo objeto. Cuando esto sucede, RDS para PostgreSQL genera un evento Lock:Relation. Algunos ejemplos comunes son los siguientes:
Los bloqueos exclusivos como
ACCESS EXCLUSIVEpueden bloquear todos los accesos concurrentes. Las operaciones del lenguaje de definición de datos (DDL) comoDROP TABLE,TRUNCATE,VACUUM FULLyCLUSTERadquieren bloqueosACCESS EXCLUSIVEimplícitamente.ACCESS EXCLUSIVEes también el modo de bloqueo por defecto para las instruccionesLOCK TABLEque no especifican un modo explícitamente.El uso de
CREATE INDEX (without CONCURRENT)en una tabla entra en conflicto con las instrucciones de lenguaje de manipulación de datos (DML)UPDATE,DELETEeINSERT, que adquieren bloqueosROW EXCLUSIVE.
Para más información sobre los bloqueos a nivel de tabla y los modos de bloqueo conflictivos, consulte Explicit Locking
Las consultas y transacciones que se bloquean normalmente se desbloquean de una de las siguientes maneras:
Consulta de bloqueo: la aplicación puede cancelar la consulta o el usuario puede terminar el proceso. El motor también puede forzar la finalización de la consulta debido al tiempo de espera de una sesión o a un mecanismo de detección de bloqueos.
Transacción bloqueada: una transacción deja de bloquearse cuando se ejecuta una instrucción
ROLLBACKoCOMMIT. Las restauraciones también ocurren de forma automática cuando las sesiones se desconectan por un cliente o por problemas de red, o se terminan. Las sesiones se pueden terminar cuando el motor de base de datos se apaga, cuando el sistema se queda sin memoria, etc.
Causas probables del aumento de las esperas
Cuando el evento Lock:Relation se produce con más frecuencia de lo normal, puede indicar un problema de rendimiento. Las causas típicas son las siguientes:
- Aumento de las sesiones concurrentes con bloqueos de tablas en conflicto
-
Puede haber un aumento en el número de sesiones concurrentes con consultas que bloquean la misma tabla con modos de bloqueo conflictivos.
- Operaciones de mantenimiento
-
Las operaciones de mantenimiento de estado como
VACUUMyANALYZEpueden aumentar significativamente el número de bloqueos conflictivos.VACUUM FULLadquiere un bloqueoACCESS EXCLUSIVE, yANALYSEadquiere un bloqueoSHARE UPDATE EXCLUSIVE. Ambos tipos de bloqueos pueden causar un evento de esperaLock:Relation. Las operaciones de mantenimiento de datos de la aplicación, como la actualización de una vista materializada, también pueden aumentar las consultas y transacciones bloqueadas. - Bloqueos en instancias de lectura
-
Puede haber un conflicto entre los bloqueos de relaciones que mantienen el escritor y los lectores. En la actualidad, solo los bloqueos de relaciones de
ACCESS EXCLUSIVEse replican en instancias de lector. Sin embargo, el bloqueo de relacionesACCESS EXCLUSIVEentrará en conflicto con cualquier bloqueo de relacionesACCESS SHAREque mantenga el lector. Esto puede provocar un aumento de los eventos de espera de las relaciones de bloqueo en el lector.
Acciones
Recomendamos diferentes acciones en función de las causas del evento de espera.
Temas
Reducir el impacto de las instrucciones SQL que se bloquean
Para reducir el impacto de las instrucciones SQL que se bloquean, modifique el código de su aplicación cuando sea posible. A continuación se presentan dos técnicas comunes para reducir los bloqueos:
Utilizar la opción
NOWAIT: algunos comandos SQL, como las instruccionesSELECTyLOCK, admiten esta opción. La directivaNOWAITcancela la consulta que solicita el bloqueo si éste no puede adquirirse inmediatamente. Esta técnica puede ayudar a evitar que una sesión bloqueada provoque una acumulación de sesiones bloqueadas detrás de ella.Por ejemplo: Supongamos que la transacción A espera un bloqueo que tiene la transacción B. Ahora, si B solicita un bloqueo en una tabla que está bloqueada por la transacción C, la transacción A podría quedar bloqueada hasta que la transacción C finalice. Pero si la transacción B utiliza un
NOWAITcuando solicita el bloqueo en C, puede fallar rápido y asegurar que la transacción A no tenga que esperar de forma indefinida.Utilice
SET lock_timeout: establezca un valor delock_timeoutpara limitar el tiempo que una sentencia SQL espera para adquirir un bloqueo en una relación. Si el bloqueo no se adquiere dentro del tiempo de espera especificado, la transacción que solicita el bloqueo se cancela. Establezca este valor en la sesión.
Minimizar el efecto de las operaciones de mantenimiento
Las operaciones de mantenimiento como VACUUM y ANALYZE son importantes. Le recomendamos que no las desactive ya que encontrará eventos de espera Lock:Relation relacionados con estas operaciones de mantenimiento. Los siguientes enfoques pueden minimizar el efecto de estas operaciones:
Ejecute las operaciones de mantenimiento de forma manual durante las horas de menor actividad.
Para reducir las esperas de
Lock:Relationcausadas por las tareas de autovacuum, realice los ajustes de autovacuum necesarios. Para obtener información sobre el ajuste de autovacuum, consulte Trabajo con Autovacuum de PostgreSQL en Amazon RDS en la Guía del usuario de Amazon RDS.
