Optimiza el uso elevado de memoria en las instancias

Vista previa

Esta función está sujeta a las "Condiciones de las Ofertas de Fase Previa a la DG" de la sección Condiciones Generales del Servicio de las Condiciones Específicas del Servicio. Las funciones de fase previa a la DG están disponibles “tal cual” y podrían tener asistencia limitada. Para obtener más información, consulta las descripciones de la etapa de lanzamiento.

En este documento, se explica cómo identificar el uso elevado de memoria para las instancias de Cloud SQL y se proporcionan recomendaciones sobre cómo resolver problemas relacionados con la memoria.

Si deseas obtener información sobre cómo configurar el uso de memoria para una instancia de Cloud SQL, consulta Prácticas recomendadas para administrar el uso de memoria.

Identifica el uso elevado de memoria

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

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

Nota: Si tienes menos del 10% de memoria en database/memory/components.cache y database/memory/components.free combinadas, el riesgo de un evento de OOM es alto. Para supervisar el uso de memoria y evitar los eventos de OOM, te recomendamos que configures una política de alertas con una condición de límite de métrica del 90% en database/memory/components.usage.

Usa Estadísticas de consultas para analizar el plan de explicación de las consultas que consumen muchos recursos

Estadísticas de consultas te ayuda a detectar, diagnosticar y prevenir problemas de rendimiento de las consultas para las bases de datos de Cloud SQL. Estadísticas de consultas te proporciona una lista de consultas de larga duración junto con su plan de explicación (documentación de PostgreSQL). Revisa el plan de explicación e identifica la parte de la consulta que tiene un método de análisis del uso elevado de memoria. Sin importar el tiempo de ejecución de la consulta, esta herramienta te brinda el plan de explicación para todas las consultas. Identifica las consultas complejas que tardan más tiempo en saber qué consultas bloquean la memoria durante más tiempo.

Los métodos de análisis comunes de PostgreSQL que usan una memoria elevada incluyen los siguientes:

• Análisis de montón de mapas de bits
• Orden rápido
• Hash o unión hash

Uso de memoria alto y registros relevantes para instancias habilitadas para Gemini

Vista previa — Gemini in Databases

Esta función está sujeta a las "Condiciones de las Ofertas de Fase Previa a la DG" de la sección Condiciones Generales del Servicio de las Condiciones Específicas del Servicio. Puedes procesar los datos personales para esta función como se describe en el Anexo de Procesamiento de Datos de Cloud, sujeto a las obligaciones y restricciones que se describen en el acuerdo en virtud del cual accedes a Google Cloud. Las funciones de fase previa a la DG están disponibles “tal cual” y podrían tener asistencia limitada. Para obtener más información, consulta las descripciones de la etapa de lanzamiento.

Si tienes Gemini habilitado, en lugar de una falla de memoria insuficiente (OOM) que genera un tiempo de inactividad de la base de datos, se finaliza una conexión que ejecuta una consulta con uso de memoria alto, lo que evita el tiempo de inactividad de la base de datos. Para identificar la consulta predeterminada, puedes verificar los registros de la base de datos en busca de 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 uso de memoria alto que se finalizó para evitar el OOM. La 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.

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

• Uso de memoria de la instancia durante las últimas 24 horas.
• Lista de consultas normalizadas que se cancelaron en las últimas 24 horas
• Vínculo a la documentación de Google sobre cómo optimizar el uso de memoria.

Recomendaciones sobre el uso elevado de memoria

Las siguientes recomendaciones abordan los problemas comunes relacionados con la memoria. Si la instancia sigue usando una gran cantidad de memoria, es probable que tenga un problema de tipo out of memory. Si las demandas de memoria de PostgreSQL o de otro proceso hacen que el sistema se quede sin memoria, verás un mensaje Out of Memory de kernel en los registros de PostgreSQL y la instancia de PostgreSQL se detendrá. Por ejemplo:

Out of Memory: Killed process 12345 (postgres)

La instancia más común en la que ves un problema de tipo OOM es con un valor más alto de work_mem con una gran cantidad de conexiones activas. Por lo tanto, si recibes mensajes OOM frecuentes o deseas evitar los eventos de OOM en tu instancia de Cloud SQL para PostgreSQL, debes considerar estas recomendaciones:

• Configura work_mem

  Las consultas que usan el orden rápido son más rápidas que las que usan el orden de combinación externo. Sin embargo, lo primero puede provocar que se agote el tiempo de memoria. Para resolver este problema, configura work_mem con un valor lo suficientemente razonable como para que balancee las operaciones de clasificación que ocurren en la memoria y en el disco. También puedes configurar work_mem a nivel de sesión en lugar de establecerlo para una instancia completa.

• Supervisa las sesiones activas

  Cada conexión usa una cantidad determinada de memoria. Usa la siguiente consulta para verificar la cantidad 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 tienes una gran cantidad de sesiones activas, analiza su causa raíz. Por ejemplo, los bloqueos de transacciones.

• Configura shared_buffers

  Si shared_buffers se establece en un valor más alto, considera reducir el valor shared_buffers para que la memoria se pueda usar en otras operaciones, como work_mem, o para establecer conexiones nuevas.

  Tasa de aciertos de caché

  Por lo general, PostgreSQL intenta conservar en la caché los datos a los que accedes con mayor frecuencia. Cuando un cliente solicita los datos, si ya están almacenados en caché en búferes compartidos, se le proporcionan directamente al cliente. Esto se conoce como 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 envían al cliente. Esto se denomina error de caché. La tasa de aciertos de caché mide cuántas solicitudes de contenido ha manejado la caché en comparación con las solicitudes recibidas. Ejecuta la siguiente consulta a fin de verificar la tasa de aciertos de caché para 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;
  
  

  Ejecuta la siguiente consulta a fin de verificar 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 una tasa de aciertos de caché del 95% al 99% es un buen valor.

• Habilita páginas grandes Cloud SQL para PostgreSQL tiene habilitado huge_pages de forma predeterminada para una mejor administración de la memoria. Te recomendamos habilitarlo. Para obtener más información sobre huge_pages, consulta la documentación de PostreSQL.

• Configura max_locks_per_transaction

  El valor de max_locks_per_transaction indica la cantidad de objetos de base de datos que se pueden bloquear de forma simultánea. En la mayoría de los casos, el valor predeterminado de 64 es suficiente. Sin embargo, si trabajas con un conjunto de datos grande, puedes tener OOM. Considera aumentar el valor de max_locks_per_transaction lo suficientemente alto como para evitar OOM.

  Nota: El bloqueo a nivel de objeto se produce en la memoria en una transacción en curso. Asignar un valor excesivamente alto para max_prepared_transactions puede hacer que la instancia de base de datos solicite más memoria compartida.

  El valor max_locks_per_transaction debe ser max_locks_per_transaction * (max_connections + max_prepared_transactions) objetos. Esto significa que, si tienes 300,000 objetos y el valor de max_connections es 200, max_locks_per_transaction debería ser 1,500.

• Configura max_pred_locks_per_transaction

  La transacción puede fallar si tienes clientes que toquen muchas tablas diferentes en una sola transacción serializable. En ese caso, considera 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, por lo que no debes establecer un valor alto no razonable.

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