LWLock:buffer_content (BufferContent) - Amazon Aurora
Versiones del motor admitidasContextoCausas probables del aumento de las esperasAcciones

LWLock:buffer_content (BufferContent)

El evento LWLock:buffer_content ocurre cuando una sesión espera para leer o escribir una página de datos en memoria mientras otra sesión tiene esa página bloqueada para escribir. En Aurora PostgreSQL 13 y versiones posteriores, este evento de espera se llama BufferContent.

Versiones del motor admitidas

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

Contexto

Para leer o manipular datos, PostgreSQL accede a ellos a través de búferes de memoria compartida. Para leer del búfer, un proceso obtiene un bloqueo ligero (LWLock) sobre el contenido del búfer en modo compartido. Para escribir en el búfer, obtiene ese bloqueo en modo exclusivo. Los bloqueos compartidos permiten a otros procesos adquirir simultáneamente bloqueos compartidos sobre ese contenido. Los bloqueos exclusivos impiden que otros procesos obtengan cualquier tipo de bloqueo sobre él.

El evento LWLock:buffer_content (BufferContent) indica que varios procesos intentan obtener bloqueos ligeros (LWLocks) sobre el contenido de un búfer específico.

Causas probables del aumento de las esperas

Cuando el evento LWLock:buffer_content (BufferContent) aparece más de lo normal, lo que posiblemente indica un problema de rendimiento, las causas típicas son las siguientes:

Aumento de las actualizaciones simultáneas de los mismos datos

Puede haber un aumento en el número de sesiones concurrentes con consultas que actualizan el mismo contenido del búfer. Esta contención puede ser más pronunciada en tablas con muchos índices.

Los datos de carga de trabajo no están en la memoria

Cuando los datos que la carga de trabajo activa está procesando no están en memoria, estos eventos de espera pueden aumentar. Este efecto se debe a que los procesos que mantienen bloqueos pueden mantenerlos durante más tiempo mientras hacen operaciones de E/S en disco.

Uso excesivo de restricciones de clave externa

Las restricciones de clave externa pueden aumentar el tiempo que un proceso mantiene un bloqueo de contenido de búfer. Este efecto se debe a que las operaciones de lectura requieren un bloqueo de contenido de búfer compartido en la clave referenciada mientras se actualiza dicha clave.

Acciones

Recomendamos diferentes acciones en función de las causas del evento de espera. Puede identificar los eventos LWLock:buffer_content (BufferContent) mediante Información sobre rendimiento de Amazon RDS o consultar la vista pg_stat_activity.

Mejorar la eficiencia en memoria

Para aumentar la posibilidad de que los datos de la carga de trabajo activa estén en memoria, particione las tablas o escale verticalmente su clase de instancia. Para obtener información acerca de las clases de instancia de base de datos, consulte Clases de instancia de base de datos de Amazon Aurora.

Supervise la métrica BufferCacheHitRatio, que mide el porcentaje de solicitudes servidas por la caché del búfer de una instancia de base de datos en el clúster de base de datos. Esta métrica proporciona información sobre la cantidad de datos que se está sirviendo desde la memoria. Una proporción de aciertos alta indica que la instancia de base de datos tiene suficiente memoria disponible para el conjunto de datos de trabajo, mientras que una proporción baja sugiere que las consultas acceden con frecuencia a los datos del almacenamiento.

Los aciertos de lectura de caché por tabla y los aciertos de lectura de caché por índice de la sección de configuración de memoria del informe de PG Collector pueden proporcionar información sobre la proporción de aciertos de caché de tablas e índices.

Reducir el uso de restricciones de clave externa

Examine las cargas de trabajo que experimentan un elevado número de eventos de espera LWLock:buffer_content (BufferContent) para comprobar el uso de las restricciones de clave externa. Elimine las restricciones de clave externa innecesarias.

Eliminar los índices que no se utilizan

Para las cargas de trabajo que experimentan un gran número de eventos de espera LWLock:buffer_content (BufferContent), identifique los índices que no se utilizan y elimínelos.

La sección de índices no utilizados del informe de PG Collector puede proporcionar información sobre los índices no utilizados de la base de datos.

Eliminación de índices duplicados

Identifique los índices duplicados y elimínelos.

La sección de índices duplicados del informe de PG Collector puede proporcionar información sobre los índices duplicados de la base de datos.

Eliminación o reindexación de los índices no válidos

Los índices no válidos suelen aparecer cuando se utiliza CREATE INDEX CONCURRENTLY o REINDEX CONCURRENTLY y el comando produce un error o se anula.

Los índices no válidos no se pueden usar para las consultas, aunque seguirán actualizándose y ocupando espacio en disco.

La sección de índices no válidos del informe de PG Collector puede proporcionar información sobre los índices no válidos de la base de datos.

Uso de índices parciales

Los índices parciales se pueden aprovechar para mejorar el rendimiento de las consultas y reducir el tamaño del índice. Un índice parcial es un índice creado a partir de un subconjunto de una tabla, con el subconjunto definido por una expresión condicional. Como se detalla en la documentación del índice parcial, los índices parciales pueden reducir la sobrecarga de mantenimiento de los índices, ya que PostgreSQL no necesita actualizar el índice en todos los casos.

Eliminación de sobrecarga de tablas e índices

La sobrecarga excesiva de tablas e índices puede afectar negativamente al rendimiento de la base de datos. Las tablas e índices sobrecargados aumentan el tamaño del conjunto de trabajo activo, lo que reduce la eficiencia de la memoria. Además, la sobrecarga aumenta los costes de almacenamiento y ralentiza la ejecución de las consultas. Para diagnosticar la sobrecarga, consulte Diagnóstico de sobrecarga de tablas e índices. Además, la sección de fragmentación (sobrecarga) del informe de PG Collector puede proporcionar información sobre la sobrecarga de tablas e índices.

Para solucionar el problema de la sobrecarga de tablas e índices, hay varias opciones:

VACUUM FULL

VACUUM FULL crea una nueva copia de la tabla, copiando solo las tuplas activas y, a continuación, reemplaza la tabla antigua por la nueva mientras mantiene un bloqueo de ACCESS EXCLUSIVE. Esto impide leer o escribir en la tabla, lo que puede provocar una interrupción. Además, VACUUM FULL tardará más si la tabla es grande.

pg_repack

Este pg_repack es útil en situaciones en las que es posible que VACUUM FULL no sea adecuado. Crea una tabla nueva que contiene los datos de la tabla sobrecargada, realiza un seguimiento de los cambios con respecto a la tabla original y, a continuación, reemplaza la tabla original por la nueva. No bloquea la tabla original para operaciones de lectura o escritura mientras crea la nueva tabla. Para obtener más información sobre cómo utilizar pg_repack, consulte Removing bloat with pg_repack y pg_repack.

REINDEX

El comando REINDEX se puede utilizar para solucionar el problema de la sobrecarga de los índices. REINDEX escribe una nueva versión del índice sin las páginas muertas o vacías o casi vacías, lo que reduce el consumo de espacio del índice. Para obtener información detallada sobre el comando REINDEX, consulte la documentación de REINDEX.

Tras eliminar la sobrecarga de las tablas e índices, puede que sea necesario aumentar la frecuencia de la limpieza automática en esas tablas. La implementación de ajustes agresivos de limpieza automática en la tabla puede ayudar a evitar que se produzca sobrecarga en el futuro. Para obtener más información, consulte la documentación en Vacuuming and analyzing tables automatically.