Prácticas recomendadas para gestionar el uso de la memoria

En esta página se describe cómo configurar el uso de memoria de una instancia de Cloud SQL.

Introducción

Cuando creas una instancia de Cloud SQL, seleccionas una cantidad de memoria para la instancia. A medida que aumenta la carga de trabajo de una base de datos PostgreSQL, también lo hace el uso de memoria de la instancia. Las instancias que consumen mucha memoria pueden crear un cuello de botella en el rendimiento que, en ocasiones, puede provocar problemas de falta de memoria.

Si una instancia de Cloud SQL se queda sin memoria debido a un aumento de la demanda, puede provocar un tiempo de inactividad de la base de datos. Por lo tanto, es importante configurar correctamente la memoria de la instancia y las marcas de la base de datos relacionadas con la memoria, así como monitorizar 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: es la memoria dedicada asignada a cada conexión, como work_mem, maintenance_work_mem y temp_buffers.

Para ver otras consideraciones sobre la configuración, consulta las prácticas recomendadas generales y las directrices operativas.

Uso de memoria y marcas

Cuando las instancias de Cloud SQL usan mucha memoria, pueden surgir las siguientes preguntas:

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

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

  • Búfer compartido: es la memoria compartida que PostgreSQL asigna para contener datos de tablas para las operaciones read y write. En el caso de la operación read, los datos que se solicitan del disco se obtienen primero en la RAM y, a continuación, se proporcionan al cliente. Del mismo modo, en PostgreSQL, cuando se solicitan los datos (por ejemplo, SELECT * from emp), primero se obtienen del disco a shared_buffers para almacenarlos en caché y, a continuación, se proporcionan al cliente. Lo mismo ocurre con la operación write.

    El búfer compartido también es el área de memoria compartida de todos los procesos y conexiones de las actividades de la base de datos, como el almacenamiento en caché de datos, el almacenamiento en caché de conexiones y las operaciones del lenguaje de manipulación de datos (DML). El máximo que puede asignar esta área se especifica en la marca 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é en la memoria es alto.

  • Memoria de trabajo de las consultas: cuando se ejecuta una consulta, PostgreSQL asigna memoria local a cada operación, como la ordenación y el cifrado hash. La cantidad máxima que puede asignar para cada operación de una consulta antes de escribir en archivos de disco temporales se configura con la marca 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 es alta.
  • Memoria de trabajo de mantenimiento: algunas operaciones de mantenimiento, como VACUUM, CREATE INDEX, ALTER TABLE y ADD FOREIGN KEY, requieren una memoria local independiente que asigna PostgreSQL. La cantidad máxima del proceso backend que usan estas operaciones se puede configurar con la marca maintenance_work_mem y el valor predeterminado es 64 MB. Ten en cuenta que los trabajadores de autovacuum también usan memoria de trabajo de mantenimiento y que el máximo se puede anular con la marca autovacuum_work_mem. Si el valor de maintenance_work_mem es alto, la velocidad de rendimiento de la operación VACUUM es alta.
  • Búferes temporales: cuando se usa una tabla temporal en una sesión de base de datos, PostgreSQL asigna búferes temporales para contener la tabla temporal local de la sesión. La cantidad máxima se puede especificar con la marca temp_buffers. El valor predeterminado es 8 MB.
  • Conexión de base de datos: cuando un cliente se conecta a la base de datos, PostgreSQL crea un proceso de 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 la base de datos se puede configurar con la marca max_connections. Cada conexión inactiva usa aproximadamente entre 2 y 3 MB de memoria compartida. Si el valor de max_connections es alto, la instancia puede establecer más conexiones, pero a costa de la memoria.

Para ver la lista completa de componentes de memoria de PostgreSQL, consulta la documentación de PostgreSQL. Para cambiar o modificar las marcas que se indican en esta sección, consulta Configurar marcas de bases de datos.

Monitorizar el uso de memoria

Monitoriza la memoria de tu instancia en Cloud Monitoring con regularidad y mantenla por debajo del límite de memoria. Una buena práctica es configurar una alerta en Cloud Monitoring para que se active cuando el uso supere el 90% del límite durante 6 horas. Esta alerta puede avisarte constantemente cuando el uso de memoria se acerque al límite.

Además, monitoriza los incidentes de falta de memoria. Para ello, configura una métrica basada en registros para el mensaje server process .* was terminated by signal 9: Killed en Cloud Monitoring para contar los eventos de falta de memoria y, a continuación, envía una alerta cada vez que se produzca un evento de este tipo.

Si tu instancia funciona constantemente por encima del 90% del límite de memoria o se produce un evento de falta de memoria, puedes aumentar la memoria de la instancia. También puedes reducir el uso de memoria limitando el número de conexiones de la base de datos o disminuyendo las marcas de la base de datos, como shared_buffers, work_mem o max_connections. Si reduces estos flags, puedes limitar el rendimiento de tu instancia.

Sin memoria

Cuando no hay suficiente memoria para gestionar la carga de trabajo de la base de datos, el sistema operativo Linux subyacente utiliza el out-of-memory (OOM) killer como último recurso para finalizar un proceso y liberar memoria. Cloud SQL está configurado de forma que OOM killer solo se dirige a los procesos de trabajo de PostgreSQL. El proceso postmaster se conserva en esta situación para que solo tenga que finalizar todas las conexiones de base de datos existentes y ejecutar una recuperación para proteger la integridad de la base de datos. Si esto ocurre, habrá momentos de interrupción del servicio y de inactividad de 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

Siguientes pasos