Otro misterio de Discourse

Recibo una alerta de AWS CloudWatch a las 9:09 p. m. ET, junto con algunos amigos que me envían un mensaje de texto: “¿Está Discourse caído?”.

No puedo conectarme por SSH a la instancia de AWS Lightsail y todas las métricas están congeladas/no informan.

Finalmente, me rindo y detengo/reinicio la instancia de Lightsail.
El servicio se recuperó.

Reviso los registros después de la recuperación del servicio, buscando aprender.

Ejecuto Discourse como una instancia única, por lo que el error a las 9:05 sobre la conexión de red de Redis me desconcierta.

No puedo entender qué sucedió, aparte de que “algo” se colgó/falló por “alguna razón”.

Cualquiera que pueda explicar o dejar algunas pistas será apreciado.

¡Gracias!

¿Cuáles son las especificaciones del servidor? ¿Suena como si se estuviera quedando sin recursos? Lo más probable es que sea la CPU. ¿Quizás hay alguna tarea diaria ejecutándose en ese momento?

Es una instancia lightsail de 1 vCPU, 1 GB de RAM y 40 GB de SSD.

El almacenamiento está consumido en un 60% aproximadamente, y cuando hago limpiezas, baja bastante.

AWS muestra que me he quedado sin créditos de CPU de ráfaga, lo cual es extraño porque las otras métricas no lo respaldan.

Es una comunidad bastante pequeña (20-30 participantes activos), así que me sorprendería si hubiera una limitación real de CPU o RAM.

No hay ninguna tarea diaria de la que tenga conocimiento, aparte de algo que discourse pueda programar por defecto.

1 GB con swap es el mínimo absoluto para ejecutar Discourse.

¿Cuánto tiempo lleva activa esta instancia? ¿Qué tamaño tiene la base de datos?

3 Me gusta

Revisaré el tamaño de la base de datos, no espero que sea grande (las copias de seguridad son de unos 57 MB).

El tiempo de actividad de la instancia no llega a las diez horas desde que la recuperación requirió detener y reiniciar el servidor virtual; no pude obtener una conexión de shell o consola.

Ha estado funcionando bien en este tipo de instancia desde que la construí (febrero de 2021, como suposición).

Esto suena a lo que sucede cuando AWS mueve tu VM de un host a otro y la deja en un estado extraño debido a ello. Normalmente, un reinicio lo soluciona.

5 Me gusta

El tamaño total de la base de datos es de 423 MB.

Las tablas más grandes son
Posts 66 MB
Post_timings 60 MB

Se produjo una segunda falla similar de “alta carga”.

Supongo que es una contención de recursos.

¿Alguien ha intentado usar la instantánea de Lightsail para hacer una instantánea de la instancia y restaurarla en una instancia más grande como método de actualización?

Puedes intentar reiniciar la instancia de AWS, eso puede solucionar muchos problemas.

Me he mudado usando una instantánea de Lightsail de 1 CPU, 1 GB de RAM y 40 GB de SSD a 2 CPU, 4 GB de RAM y 80 GB de SSD.

Aparte de tener que desvincular la IP pública y volver a vincularla, lo cual fue bastante sencillo, mi preocupación restante es “¿qué me he perdido?”.

¿Hay algo (copias de seguridad, correo electrónico, configuración del bucket S3, etc.) que deba verificar o necesito volver a ejecutar algún parámetro de instalación inicial para aprovechar los recursos mejorados?

Creo que, basándome en este enlace, podría aumentar el db_shared_buffer a al menos 1 GB.
La app.yml actual dice 128 MB, también indica ajuste automático al arrancar.

1 GB está bien para un sistema de 4 GB. Asegúrate de actualizar también unicorn_workers a 4.

La recomendación habitual si estuvieras moviéndote entre servidores sería volver a ejecutar discourse-setup, lo que se encargaría de lo anterior automáticamente.

1 me gusta

Gracias. Ahora me estoy adentrando en el mundo de Prometheus.

Buen material.