Optimizar el uso elevado de memoria en las instancias

Este documento explica cómo identificar el uso elevado de memoria para instancias de Cloud SQL y proporciona recomendaciones sobre cómo resolver problemas relacionados con la memoria.

Para saber cómo configurar el uso de memoria para una instancia de Cloud SQL, consulta Prácticas recomendadas para administrar el uso de memoria .

Identificar el alto uso de memoria

Las siguientes secciones analizan escenarios de alto uso de memoria.

Utilice el Explorador de métricas para identificar el uso de memoria

Puede revisar el uso de memoria de la instancia con la métrica database/memory/components.usage en el Explorador de métricas .

Utilice Query Insights para analizar y explicar el plan para consultas que consumen muchos recursos.

Query Insights le ayuda a detectar, diagnosticar y prevenir problemas de rendimiento de consultas en bases de datos de Cloud SQL. Le proporciona una lista de consultas de larga duración junto con su plan de explicación (documentación de PostgreSQL) . Revise el plan de explicación e identifique la parte de la consulta que utiliza un método de escaneo de alto consumo de memoria. Independientemente del tiempo de ejecución de la consulta, Query Insights le proporciona el plan de explicación para todas las consultas. Identifique las consultas complejas que tardan más tiempo para saber cuáles bloquean la memoria durante periodos más largos.

Los métodos de escaneo comunes de PostgreSQL que utilizan mucha memoria incluyen los siguientes:

  • Escaneo de montón de mapas de bits
  • Ordenación rápida
  • Unión hash o Hash

Alto uso de memoria y registros relevantes para instancias habilitadas para Gemini

Si tiene Gemini habilitado, en lugar de un fallo de memoria insuficiente (OOM) que provoque una inactividad de la base de datos, se finaliza la conexión que ejecuta una consulta con alto consumo de memoria, lo que evita la inactividad de la base de datos. Para identificar la consulta predeterminada, puede consultar los registros de la base de datos para ver las siguientes entradas:

  (...timestamp….) db=postgres, user=customer FATAL: terminating connection due to administrator command

Se muestra el siguiente registro de la base de datos de Cloud SQL para PostgreSQL, que captura la consulta de alto uso de memoria que se terminó para evitar el OOM. Esta consulta es una versión normalizada de la consulta original:

  db=postgres,user=customer LOG:  postgres process with PID 1734 for the query "SELECT COUNT(product) AS item_count FROM test_table WHERE product_type = $1 AND product LIKE $2 AND c6_2 IN ($3,$4,$5,$6,$7)" has been cancelled.

También se muestran notificaciones en la página Instancias de Cloud SQL para los siguientes eventos:

  • Utilización de memoria de la instancia durante las últimas 24 horas.
  • Listado de consultas normalizadas que han sido canceladas en las últimas 24 horas.
  • Un enlace a la documentación de Google sobre cómo optimizar el uso de la memoria.

Alto uso de memoria: recomendaciones

Las siguientes recomendaciones abordan los problemas comunes relacionados con la memoria. Si la instancia continúa utilizando mucha memoria, es muy probable que se produzca un problema out of memory . Si las demandas de memoria de PostgreSQL o de otro proceso provocan que el sistema se quede sin memoria, aparecerá un mensaje de kernel Out of Memory en los registros de PostgreSQL y la instancia de PostgreSQL se detendrá. Por ejemplo:

Out of Memory: Killed process 12345 (postgres)

El caso más común de un problema de OOM se produce cuando el valor de work_mem es alto y hay un gran número de conexiones activas. Por lo tanto, si experimenta OOM frecuentes o para evitarlos en su instancia de Cloud SQL para PostgreSQL, le recomendamos seguir estas recomendaciones:

  • Establecer work_mem

    Las consultas que utilizan ordenación rápida son más rápidas que las que utilizan ordenación por fusión externa. Sin embargo, la primera puede agotar la memoria. Para solucionar este problema, configure el valor work_mem con un valor razonable que equilibre las operaciones de ordenación en memoria y disco. También puede considerar configurar work_mem a nivel de sesión en lugar de configurarlo para toda la instancia.

  • Monitorizar las sesiones activas

    Cada conexión utiliza una cantidad determinada de memoria. Utilice la siguiente consulta para comprobar el número de conexiones activas:

      SELECT
    state,
    usename,
    count(1)
  FROM
    pg_stat_activity
  WHERE
    pid <> pg_backend_pid()
  GROUP BY
    state,
    usename
  ORDER BY
    1;

    Si tiene una gran cantidad de sesiones activas, analice la causa raíz de esa gran cantidad de sesiones activas; por ejemplo, bloqueos de transacciones.

  • Establecer shared_buffers

    Si shared_buffers se establece en un valor más alto, considere disminuir el valor de shared_buffers para que la memoria pueda usarse para otras operaciones, como work_mem , o para establecer nuevas conexiones.

    Tasa de aciertos de caché

    PostgreSQL generalmente intenta mantener en caché los datos a los que accede con mayor frecuencia. Cuando un cliente solicita los datos, si ya están almacenados en caché en búferes compartidos, se le entregan directamente. Esto se denomina acierto de caché . Si los datos no están presentes en los búferes compartidos, primero se recuperan en los búferes compartidos desde un disco y luego se entregan al cliente. Esto se denomina error de caché . La tasa de aciertos de caché mide cuántas solicitudes de contenido ha gestionado la caché en comparación con las solicitudes recibidas. Ejecute la siguiente consulta para comprobar la tasa de aciertos de caché de las solicitudes de tabla en la instancia de PostgreSQL:

    SELECT
  sum(heap_blks_read) as heap_read,
  sum(heap_blks_hit)  as heap_hit,
  sum(heap_blks_hit) / (sum(heap_blks_hit) + sum(heap_blks_read)) as ratio
FROM
  pg_statio_user_tables;

    Ejecute la siguiente consulta para comprobar la tasa de aciertos de caché para las solicitudes de índice en la instancia de PostgreSQL:

      SELECT
    sum(idx_blks_read) as idx_read,
    sum(idx_blks_hit)  as idx_hit,
    (sum(idx_blks_hit) - sum(idx_blks_read)) / sum(idx_blks_hit) as ratio
  FROM
    pg_statio_user_indexes;

    En general, se considera que un índice de acierto de caché del 95 al 99 % es un buen valor.

  • Habilitar páginas enormes. Cloud SQL para PostgreSQL tiene habilitada huge_pages por defecto para una mejor gestión de la memoria. Recomendamos habilitarla. Para obtener más información sobre huge_pages , consulte la documentación de PostgreSQL .

  • Establecer max_locks_per_transaction

    El valor max_locks_per_transaction indica la cantidad de objetos de base de datos que se pueden bloquear simultáneamente. En la mayoría de los casos, el valor predeterminado de 64 es suficiente. Sin embargo, si trabaja con un conjunto de datos grande, podría experimentar bloqueos de objetos (OOM). Considere aumentar el valor de max_locks_per_transaction lo suficiente para evitar bloqueos de objetos (OOM).

    El valor de max_locks_per_transaction debe ser max_locks_per_transaction * ( max_connections + max_prepared_transactions ) objetos. Esto significa que si tiene 300 mil objetos y el valor de max_connections es 200, entonces max_locks_per_transaction debe ser 1500.

  • Establecer max_pred_locks_per_transaction

    La transacción podría fallar si tiene clientes que acceden a varias tablas diferentes en una sola transacción serializable. En ese caso, considere aumentar max_pred_locks_per_transaction a un valor razonablemente alto. Al igual que max_locks_per_transaction , max_pred_locks_per_transaction también usa memoria compartida, así que no establezca un valor excesivamente alto.

  • Si el uso de memoria sigue siendo alto y considera que esas consultas son tráfico legítimo, considere aumentar la cantidad de recursos de memoria en su instancia para evitar fallas o tiempos de inactividad de la base de datos.

¿Qué sigue?