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.
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
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 buscar las siguientes entradas en los registros de la base de datos:
(...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
- Es un vínculo a la documentación de Google sobre cómo optimizar el uso de la 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 configurarwork_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 valorshared_buffers
para que la memoria se pueda usar en otras operaciones, comowork_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 sobrehuge_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 demax_locks_per_transaction
lo suficientemente alto como para evitar OOM.El valor
max_locks_per_transaction
debe sermax_locks_per_transaction
* (max_connections
+max_prepared_transactions
) objetos. Esto significa que, si tienes 300,000 objetos y el valor demax_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 quemax_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.