Mejores prácticas para gestionar el uso de la memoria

Esta página describe cómo configurar el uso de memoria para una instancia de Cloud SQL.

Introducción

Al crear una instancia de Cloud SQL, se selecciona una cantidad de memoria. A medida que aumenta la carga de trabajo de una base de datos PostgreSQL, aumenta el uso de memoria. Las instancias que consumen mucha memoria pueden generar un cuello de botella en el rendimiento que, en ocasiones, puede provocar problemas de memoria insuficiente.

Cuando una instancia de Cloud SQL se queda sin memoria debido a un aumento de la demanda, puede causar tiempo de inactividad en la base de datos. Por lo tanto, es importante configurar correctamente la memoria de la instancia y los indicadores de la base de datos relacionados con ella, así como supervisar el uso de la memoria para que la instancia funcione correctamente.

Los componentes de memoria de PostgreSQL se dividen en dos secciones:

  • Memoria global: se comparte entre todos los procesos para ejecutar consultas; por ejemplo, shared_buffers y max_connections .
  • Memoria local: esta es una memoria dedicada asignada a cada conexión; por ejemplo, work_mem , maintenance_work_mem y temp_buffers .

Para otras consideraciones de configuración, consulte Mejores prácticas generales y Pautas operativas .

Uso de memoria y banderas

Siempre que haya un alto uso de memoria por parte de las instancias de Cloud SQL, pueden surgir las siguientes preguntas:

  • ¿Qué consulta o proceso está utilizando mucha memoria?
  • ¿La configuración de memoria es adecuada para la actividad de la base de datos?
  • ¿Cómo cambiar la configuración de la memoria?

Cuando funciona una base de datos PostgreSQL, la mayor parte del uso de memoria se produce en unas pocas áreas:

  • Búfer compartido: Esta es la memoria compartida que PostgreSQL asigna para almacenar datos de tablas en operaciones read y write . Para la operación read , cualquier dato solicitado desde el disco se obtiene primero en la RAM y luego se entrega al cliente. De forma similar, en PostgreSQL, cuando se solicitan datos (por ejemplo, SELECT * from emp ), primero se obtienen del disco a shared_buffers para su almacenamiento en caché y luego se entregan al cliente. Lo mismo ocurre con la operación write .

    El búfer compartido también es el área de memoria compartida para todos los procesos y conexiones de actividades de la base de datos, como el almacenamiento en caché de datos, el almacenamiento en caché de conexiones y las operaciones de lenguaje de manipulación de datos (DML). La asignación máxima de esta área se especifica mediante el indicador shared_buffers y el valor predeterminado es el 33 % de la memoria de la instancia. Si el valor de shared_buffers es alto, el tamaño de los datos almacenados en caché es alto.

  • Memoria de trabajo de consulta: al ejecutar una consulta, PostgreSQL asigna memoria local para cada operación, como la ordenación y el hash. El límite máximo que puede asignar para cada operación de una consulta antes de escribir en archivos temporales del disco se configura mediante el indicador work_mem , y el valor predeterminado es 4 MB. Si el valor de work_mem es alto, la cantidad de datos que se pueden ordenar en la memoria también lo es.
  • Memoria de trabajo de mantenimiento: algunas operaciones de mantenimiento, como VACUUM , CREATE INDEX , ALTER TABLE y ADD FOREIGN KEY requieren memoria local independiente que PostgreSQL asigna. La cantidad máxima que estas operaciones utilizan para el proceso backend se puede configurar con el indicador maintenance_work_mem , y el valor predeterminado es 64 MB. Tenga en cuenta que los trabajadores de autovacuum también utilizan memoria de trabajo de mantenimiento, y el máximo se puede sobrescribir con el indicador autovacuum_work_mem . Si el valor de maintenance_work_mem es alto, la operación VACUUM también ofrece un alto rendimiento.
  • Búferes temporales: cuando se utiliza una tabla temporal en una sesión de base de datos, PostgreSQL asigna búferes temporales para almacenar la tabla temporal local de la sesión. La cantidad máxima se puede especificar mediante el indicador temp_buffers y el valor predeterminado es 8 MB.
  • Conexión a la base de datos: cuando un cliente se conecta a la base de datos, PostgreSQL crea un proceso backend para atender la sesión del cliente. Además de la memoria para ejecutar la consulta, PostgreSQL asigna memoria adicional para mantener información como la caché del catálogo del sistema y los planes de consulta preparados. El número máximo de conexiones simultáneas permitidas al servidor de base de datos se puede configurar mediante el indicador max_connections . Cada conexión inactiva utiliza aproximadamente de 2 a 3 MB de memoria compartida. Si el valor de max_connections es alto, la instancia puede realizar más conexiones, pero a costa de la memoria.

Para obtener la lista completa de componentes de memoria en PostgreSQL, consulte la documentación de PostgreSQL . Para cambiar o modificar los indicadores de esta sección, consulte Configurar indicadores de base de datos .

Monitorizar el uso de la memoria

Monitorea la memoria de tu instancia en Cloud Monitoring regularmente y mantenla por debajo del límite. Una buena práctica es configurar una alerta en Cloud Monitoring para que te avise cuando el uso supere el 90 % del límite durante 6 horas. Esta alerta puede avisarte cuando el uso de memoria esté cerca del límite constantemente.

Además, monitoree los incidentes de falta de memoria. Para ello, configure una métrica basada en registros para el server process .* was terminated by signal 9: Killed " en Cloud Monitoring para contabilizar los eventos de falta de memoria y generar una alerta cada vez que ocurra.

Si su instancia opera constantemente por encima del 90% del límite de memoria o se produce un evento de memoria insuficiente, puede aumentar la memoria de la instancia. Como alternativa, puede reducir el uso de memoria limitando el número de conexiones a la base de datos o reduciendo indicadores de la base de datos como shared_buffers , work_mem o max_connections . Reducir estos indicadores puede limitar el rendimiento de su instancia.

Sin memoria

Cuando no hay memoria suficiente para gestionar la carga de trabajo de la base de datos, como último recurso, el sistema operativo Linux subyacente utiliza el out-of-memory (OOM) killer para finalizar un proceso y liberar memoria. Cloud SQL está configurado para que el OOM killer solo afecte a los procesos de trabajo de PostgreSQL. El proceso postmaster se conserva en esta situación, de modo que solo tiene que finalizar todas las conexiones existentes a la base de datos y ejecutar una recuperación para proteger su integridad. Si esto ocurre, se producen interrupciones del servicio y tiempos de inactividad en la base de datos. En el registro de la base de datos de PostgreSQL, aparecen mensajes como los siguientes:

2021-10-24 23:34:22.265 UTC [7]: [663-1] db=,user= LOG: server process (PID 1255039) was terminated by signal 9: Killed
2021-10-24 23:34:22.265 UTC [7]: [664-1] db=,user= DETAIL: Failed process was running: SELECT * FROM tab ORDER BY col
2021-10-24 23:34:22.277 UTC [7]: [665-1] db=,user= LOG: terminating any other active server processes
2021-10-24 23:34:22.278 UTC [1255458]: [1-1] db=postgres,user=postgres WARNING: terminating connection because of crash of another server process
2021-10-24 23:34:22.278 UTC [1255458]: [2-1] db=postgres,user=postgres DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.
2021-10-24 23:34:22.278 UTC [1255458]: [3-1] db=postgres,user=postgres HINT: In a moment you should be able to reconnect to the database and repeat your command.
2021-10-24 23:34:22.278 UTC [1255458]: [4-1] db=postgres,user=postgres CONTEXT: while updating tuple (27,18) in relation "tab"
...
2021-10-24 23:34:22.558 UTC [1255477]: [1-1] db=postgres,user=postgres FATAL: the database system is in recovery mode
...
2021-10-24 23:34:25.579 UTC [7]: [666-1] db=,user= LOG: all server processes terminated; reinitializing
...
2021-10-24 23:34:25.691 UTC [1255482]: [1-1] db=,user= LOG: database system was interrupted; last known up at 2021-10-24 23:31:53 UTC
2021-10-24 23:34:25.776 UTC [1255482]: [2-1] db=,user= LOG: database system was not properly shut down; automatic recovery in progress
2021-10-24 23:34:25.789 UTC [1255482]: [3-1] db=,user= LOG: redo starts at 227/AB359400
2021-10-24 23:34:38.957 UTC [1255482]: [4-1] db=,user= LOG: redo done at 229/4621F508
2021-10-24 23:34:38.959 UTC [1255482]: [5-1] db=,user= LOG: last completed transaction was at log time 2021-10-24 23:34:18.5535+00
2021-10-24 23:34:39.290 UTC [7]: [667-1] db=,user= LOG: database system is ready to accept connections

¿Qué sigue?