Estamos ejecutando una prueba de carga en una aplicación que llega a una base de datos de Postgres.
Durante la prueba, de repente obtenemos un aumento en la tasa de error. Después de analizar el comportamiento de la plataforma y la aplicación, notamos que:
- La CPU de Postgres RDS es 100%
- La memoria liberable cae en este mismo servidor
Y en los registros de Postgres, vemos:
2018-08-21 08:19:48 UTC::@:[XXXXX]:LOG: el proceso del servidor (PID XXXX) finalizó con la señal 9: finalizado
Después de investigar y leer la documentación, parece que una posibilidad es que Linux oomkiller se esté ejecutando y haya finalizado el proceso.
Pero como estamos en RDS, no podemos acceder a los registros del sistema /var/log mensajes para confirmar.
Entonces alguien puede:
- confirme que oom killer realmente se ejecuta en AWS RDS para Postgres
- ¿Danos una forma de comprobar esto?
- ¿Nos da una forma de calcular la memoria máxima utilizada por Postgres en función del número de conexiones?
No encontré la respuesta aquí:
Respuesta1
Incluso si el asesino de OOM no actuó (probablemente lo hizo), mantener una CPU del 100% y una memoria libre muy baja es malo para el rendimiento.
Utilice un tamaño de instancia mayor y vea si el problema desaparece. Pruebe un tamaño más pequeño en un Postgres que no sea RDS que controle y vea si el asesino de OOM se enoja.
El número de conexiones no es necesariamente el factor dominante en el consumo de memoria: la memoria compartida se utiliza para otras cosas y no todas las consultas utilizan una gran cantidad de memoria. Vea también esta conversación:PostgreSql asigna memoria para cada conexión.
Consejos adicionales deMejores prácticas para Amazon RDS
Recomendaciones de RAM para instancias de base de datos
Una práctica recomendada de rendimiento de Amazon RDS es asignar suficiente RAM para que su conjunto de trabajo resida casi por completo en la memoria. Para saber si casi todo su conjunto de trabajo está en la memoria, verifique la métrica ReadIOPS (usando Amazon CloudWatch) mientras la instancia de base de datos está bajo carga. El valor de ReadIOPS debe ser pequeño y estable. Si escalar la clase de instancia de base de datos (a una clase con más RAM) resulta en una caída dramática en ReadIOPS, su conjunto de trabajo no estaba casi completamente en la memoria. Continúe ampliando hasta que ReadIOPS ya no disminuya drásticamente después de una operación de escalado, o ReadIOPS se reduzca a una cantidad muy pequeña.
Evaluación de métricas de rendimiento
Memoria liberable: cuánta RAM está disponible en la instancia de base de datos, en megabytes. La línea roja en las métricas de la pestaña Monitoreo está marcada en 75% para las métricas de CPU, memoria y almacenamiento. Si el consumo de memoria de la instancia cruza con frecuencia esa línea, esto indica que debe verificar su carga de trabajo o actualizar su instancia.
Respuesta2
No tengo mucha experiencia con Postgres, pero en la misma situación descubro que una instancia RDS MySql es propensa a reiniciarse por completo. Incluso si no tiene acceso a los sistemas subyacentes, debería poder obtener registros de Postgres a través de la consola web. Busque un reinicio, el demonio debería indicar que se está cerrando e iniciando.
De todos modos, si estás trabajando en una zona de peligro. no hay mucho que puedas hacer. Deberías pasar a una instancia con más RAM/CPU disponible.