Lock:extend - Amazon Relational Database Service
Versiones del motor admitidasContextoCausas probables del aumento de las esperasAcciones

Lock:extend

El evento Lock:extend se produce cuando un proceso del backend espera bloquear una relación para extenderla mientras otro proceso tiene un bloqueo en esa relación con el mismo propósito.

Versiones del motor admitidas

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

Contexto

El evento Lock:extend indica que un proceso backend se encuentra a la espera de extender una relación sobre la que otro proceso backend tiene un bloqueo mientras está extendiendo esa relación. Debido a que solo un proceso a la vez puede extender una relación, el sistema genera un evento de espera Lock:extend. Las operaciones INSERT, COPY y UPDATE pueden generar este evento.

Causas probables del aumento de las esperas

Cuando el evento Lock:extend aparece más de lo normal, lo que posiblemente indica un problema de rendimiento, las causas típicas son las siguientes:

Aumento de las inserciones o actualizaciones concurrentes en la misma tabla

Puede haber un aumento en el número de sesiones concurrentes con consultas que insertan o actualizan la misma tabla.

Ancho de banda de red insuficiente

El ancho de banda de la red en la instancia de base de datos puede ser insuficiente para las necesidades de comunicación del almacenamiento de la carga de trabajo actual. Esto puede contribuir a la latencia del almacenamiento que provoca un aumento de los eventos Lock:extend.

Acciones

Recomendamos diferentes acciones en función de las causas del evento de espera.

Reducir las inserciones y actualizaciones concurrentes en la misma relación

En primer lugar, determine si hay un aumento de las métricas tup_inserted y tup_updated y un aumento de este evento de espera. Si es así, verifique qué relaciones están en alta contención para las operaciones de inserción y actualización. Para determinar esto, consulte la vista pg_stat_all_tables para los valores de los campos n_tup_ins y n_tup_upd. Para obtener información sobre la vista pg_stat_all_tables, consulte pg_stat_all_tables en la documentación de PostgreSQL.

Para obtener más información acerca de las consultas bloqueadas y no bloqueadas, consulte pg_stat_activity como en el siguiente ejemplo:

SELECT
    blocked.pid,
    blocked.usename,
    blocked.query,
    blocking.pid AS blocking_id,
    blocking.query AS blocking_query,
    blocking.wait_event AS blocking_wait_event,
    blocking.wait_event_type AS blocking_wait_event_type
FROM pg_stat_activity AS blocked
JOIN pg_stat_activity AS blocking ON blocking.pid = ANY(pg_blocking_pids(blocked.pid))
where
blocked.wait_event = 'extend'
and blocked.wait_event_type = 'Lock';
 
   pid  | usename  |            query             | blocking_id |                         blocking_query                           | blocking_wait_event | blocking_wait_event_type
  ------+----------+------------------------------+-------------+------------------------------------------------------------------+---------------------+--------------------------
   7143 |  myuser  | insert into tab1 values (1); |        4600 | INSERT INTO tab1 (a) SELECT s FROM generate_series(1,1000000) s; | DataFileExtend      | IO

Después de identificar las relaciones que contribuyen a aumentar los eventos Lock:extend, utilice las siguientes técnicas para reducir la contención:

  • Compruebe si puede utilizar el particionamiento para reducir la contención para la misma tabla. Separar las tuplas insertadas o actualizadas en diferentes particiones puede reducir la contención. Para obtener información sobre las particiones, consulte Administración de las particiones de PostgreSQL con la extensión pg_partman.

  • Si el evento de espera se debe principalmente a la actividad de actualización, considere reducir el valor de fillfactor de la relación. Esto puede reducir las solicitudes de nuevos bloques durante la actualización. El fillfactor es un parámetro de almacenamiento para una tabla que determina la cantidad máxima de espacio para empaquetar una página de la tabla. Se expresa como un porcentaje del espacio total de una página. Para más información sobre el parámetro fillfactor, consulte CREATE TABLE en la documentación de PostgreSQL.

    importante

    Recomendamos ampliamente que pruebe su sistema si cambia el fillfactor porque cambiar este valor puede impactar negativamente en el rendimiento, de acuerdo a su carga de trabajo.

Aumentar el ancho de banda de la red

Para ver si hay un aumento en la latencia de escritura, verifique la métrica WriteLatency en CloudWatch. Si lo hay, utilice las métricas WriteThroughput y ReadThroughput de Amazon CloudWatch para monitorear el tráfico relacionado con el almacenamiento en la instancia de base de datos. Estas métricas pueden ayudarle a determinar si el ancho de banda de la red es suficiente para la actividad de almacenamiento de su carga de trabajo.

Si el ancho de banda de su red no es suficiente, auméntelo. Si la instancia de base de datos alcanza los límites del ancho de banda de la red, la única forma de aumentar el ancho de banda es aumentar el tamaño de la instancia de base de datos.

Para obtener más información acerca de las métricas de CloudWatch, consulte Métricas de nivel de instancia de Amazon CloudWatch para Amazon RDS. Para obtener información sobre el rendimiento de la red para cada clase de instancia de base de datos, consulte Métricas de nivel de instancia de Amazon CloudWatch para Amazon RDS.