LWLock:BufferMapping (LWLock:buffer_mapping)
Este evento se produce cuando una sesión espera asociar un bloque de datos con un búfer en el grupo de búferes compartidos.
nota
Para la versión 13 y posteriores de RDS para PostgreSQL, el nombre de este evento es LWLock:BufferMapping
. Para la versión 12 y posteriores de RDS para PostgreSQL, el nombre de este evento es LWLock:buffer_mapping
.
Versiones del motor admitidas
La información del evento de espera es relevante para RDS para PostgreSQL versión 9.6 y posteriores.
Contexto
El grupo de búferes compartidos es un área de memoria de PostgreSQL que contiene todas las páginas que utilizan o utilizaban los procesos. Cuando un proceso necesita una página, lee la página en el grupo de búferes compartidos. El parámetro shared_buffers
establece el tamaño del búfer compartido y reserva un área de memoria para almacenar las páginas de tablas e índices. Si cambia este parámetro, asegúrese de reiniciar la base de datos.
El evento de espera LWLock:buffer_mapping
ocurre en los siguientes escenarios:
-
Un proceso busca una página en la tabla de búferes y adquiere un bloqueo de asignación de búferes compartidos.
-
Un proceso carga una página en el grupo de búferes y adquiere un bloqueo de asignación de búferes exclusivo.
-
Un proceso elimina una página del grupo y adquiere un bloqueo de asignación de búferes exclusivo.
Causas
Cuando este evento aparece más de lo normal, lo que puede indicar un problema de rendimiento, la base de datos entra y sale del grupo de búferes compartidos. Las causas típicas son las siguientes:
-
Consultas grandes
-
Índices y tablas sobrecargados
-
Escaneos completos de tablas
-
Un tamaño del grupo compartido menor que el conjunto de trabajo
Acciones
Recomendamos diferentes acciones en función de las causas del evento de espera.
Temas
Monitorear las métricas relacionadas con el buffer
Cuando las esperas de LWLock:buffer_mapping
se disparan, hay que investigar la tasa de aciertos del búfer. Puede utilizar estas métricas para comprender mejor lo que ocurre en la caché del búfer. Examina las siguientes métricas:
blks_hit
-
Esta métrica del contador de Información sobre rendimiento indica el número de bloques que se recuperaron del grupo de búferes compartidos. Después de que aparezca el evento de espera
LWLock:buffer_mapping
, se puede observar un pico enblks_hit
. blks_read
-
Esta métrica del contador de Información sobre rendimiento indica el número de bloques que requirieron E/S para leerse en el grupo de búferes compartidos. Puede observar un pico en
blks_read
en el periodo previo al evento de esperaLWLock:buffer_mapping
.
Evaluar la estrategia de indexación
Para confirmar que la estrategia de indexación no disminuye el rendimiento, verifique lo siguiente:
- Sobrecarga del índice
-
Asegúrese de que el índice y la sobrecarga de la tabla no provocan la lectura de páginas innecesarias en el búfer compartido. Si las tablas contienen filas que no se utilizan, considere la posibilidad de archivar los datos y eliminar las filas de las tablas. A continuación, puede reconstruir los índices para las tablas redimensionadas.
- Índices para consultas de uso frecuente
-
Para determinar si cuenta con los índices óptimos, monitoree las métricas del motor de base de datos en Información sobre rendimiento. La métrica
tup_returned
muestra el número de filas leídas. La métricatup_fetched
muestra el número de filas devueltas al cliente. Situp_returned
es mucho mayor quetup_fetched
, es posible que los datos no estén bien indexados. Además, es posible que las estadísticas de la tabla no se encuentren actualizadas.
Reducir el número de búferes que deben ser asignados rápidamente
Para reducir los eventos de espera de LWLock:buffer_mapping
, intente reducir el número de búferes que se deben asignar de forma rápida. Una estrategia es hacer operaciones por lotes más pequeños. Se pueden conseguir lotes más pequeños por medio de la partición de las tablas.