# LWLock:buffer\$1mapping
<a name="apg-waits.lwl-buffer-mapping"></a>

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**  
Este evento aparece como `LWLock:buffer_mapping` en la versión 12 de Aurora PostgreSQL e inferior, y `LWLock:BufferMapping` en la versión 13 y posterior.

**Topics**
+ [Versiones del motor admitidas](#apg-waits.lwl-buffer-mapping.context.supported)
+ [Contexto](#apg-waits.lwl-buffer-mapping.context)
+ [Causas](#apg-waits.lwl-buffer-mapping.causes)
+ [Acciones](#apg-waits.lwl-buffer-mapping.actions)

## Versiones del motor admitidas
<a name="apg-waits.lwl-buffer-mapping.context.supported"></a>

La información del evento de espera es relevante para Aurora PostgreSQL versión 9.6 y posterior.

## Contexto
<a name="apg-waits.lwl-buffer-mapping.context"></a>

El *grupo de búferes compartidos* es un área de memoria de Aurora PostgreSQL que contiene todas las páginas que se están o se estaban utilizando por 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. Para obtener más información, consulte [Búferes compartidos](AuroraPostgreSQL.Tuning.concepts.md#AuroraPostgreSQL.Tuning.concepts.buffer-pool).

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
<a name="apg-waits.lwl-buffer-mapping.causes"></a>

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
<a name="apg-waits.lwl-buffer-mapping.actions"></a>

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

**Topics**
+ [Monitorear las métricas relacionadas con el buffer](#apg-waits.lwl-buffer-mapping.actions.monitor-metrics)
+ [Evaluar la estrategia de indexación](#apg-waits.lwl-buffer-mapping.actions.indexes)
+ [Reducir el número de búferes que deben ser asignados rápidamente](#apg-waits.lwl-buffer-mapping.actions.buffers)

### Monitorear las métricas relacionadas con el buffer
<a name="apg-waits.lwl-buffer-mapping.actions.monitor-metrics"></a>

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:

`BufferCacheHitRatio`  
Esta métrica de Amazon CloudWatch mide el porcentaje de solicitudes que se atienden en la caché del búfer de una instancia de base de datos en su clúster de base de datos. Es posible que esta métrica disminuya en el periodo previo al evento de espera `LWLock:buffer_mapping`.

`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 en `blks_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 espera `LWLock:buffer_mapping`.

### Evaluar la estrategia de indexación
<a name="apg-waits.lwl-buffer-mapping.actions.indexes"></a>

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étrica `tup_fetched` muestra el número de filas devueltas al cliente. Si `tup_returned` es mucho mayor que `tup_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
<a name="apg-waits.lwl-buffer-mapping.actions.buffers"></a>

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.