Toda la máquina se cuelga durante la actualización

Desde que probé los plugins de IA (y luego los volví a eliminar), mi máquina se cuelga por completo durante /admin/upgrade.

No siempre, pero aproximadamente el 80% de las veces.

Por lo general, toda mi instancia de EC2 se congela y tengo que hacer un reinicio forzado a través de la interfaz web de AWS EC2.

Hoy se cuelga de nuevo. Para mi sorpresa, no se congela por completo. Al abrir la URL raíz, ahora muestra:

Oops

El software que impulsa este foro de discusión encontró un problema inesperado. Lamentamos las molestias.

Se registró información detallada sobre el error y se generó una notificación automática. Le echaremos un vistazo.

No es necesaria ninguna otra acción. Sin embargo, si la condición de error persiste, puede proporcionar detalles adicionales, incluidos los pasos para reproducir el error, publicando un tema de discusión en la categoría de comentarios del sitio.

Ahora intentaré reiniciarlo de nuevo y haré lo habitual de sudo ./launcher rebuild app, que lo ha solucionado hasta ahora. Crucemos los dedos para que lo haga hoy de nuevo.

Mi pregunta

¿Alguien puede darme alguna pista sobre dónde podría mirar en los archivos de registro o cosas similares para obtener al menos un mensaje de error de por qué ocurren las congelaciones?

¿El plugin de IA oficial?

Ejecutaría esto desde la consola y vería dónde se atasca, comparte los registros.

Sí, el plugin oficial.

Lo desinstalé eliminando los plugins de app.yml nuevamente y luego reconstruyendo. ¿Quizás esto no es suficiente?

¿A qué se refiere con “esto”? ¿El sudo ./launcher rebuild app?

¿Cuál es la configuración de tu servidor?

Las actualizaciones en línea, en mi opinión, requieren un servidor de 4 GB + 2 GB de intercambio hoy en día como mínimo.

Estoy usando una instancia EC2 de AWS “t2.medium” con 2 vCPUs y 4 GiB de RAM.

El HDD es de 100 GiB con 60 GiB de espacio libre.

Si ayuda, puedo actualizar “t2.medium” a un tipo de instancia más grande.

Solo estoy confundido porque esta configuración funcionó de manera sólida (durante años) antes de probar el plugin oficial de IA y solo desde entonces, después de eliminarlo, ocurren estas interrupciones durante la actualización.

Otra cosa ha cambiado: la versión del software al que se está actualizando. Se ha vuelto más hambrienta de memoria últimamente. Así que creo que podría ser una de las dos.

Una actualización temporal y reversible a una instancia con más RAM es probablemente la forma más fácil de probar si la escasez de memoria es el problema, aunque cuesta un par de reinicios. La otra forma es agregar intercambio (swap), que también es reversible.

Intentaría añadir swap.

Gracias, chicos, buscaré en Google cómo hacer esto y luego lo haré .

Actualización 1

Ahora he añadido 8 GiB de swap:

$ free -h
               total        used        free      shared  buff/cache   available
Mem:           3.8Gi       290Mi       2.9Gi       1.0Mi       677Mi       3.3Gi
Swap:          8.0Gi          0B       8.0Gi

Publicaré una actualización aquí después de algunas próximas actualizaciones para ver si esto ayudó.

Actualización 2

Acabo de hacer una /admin/upgrade y he monitorizado el uso de RAM:

$ free -h
               total        used        free      shared  buff/cache   available
Mem:           3.8Gi       1.4Gi       1.5Gi        50Mi       891Mi       2.0Gi
Swap:          8.0Gi       200Mi       7.8Gi

Y la actualización se completó con éxito. Espero que se mantenga así.

Actualización 3

Varios días y actualizaciones después, nunca volví a experimentar un cuelgue.

Así que creo que el swap fue la solución. Gracias de nuevo a cualquiera que me haya ayudado con este problema.

Esto está un poco fuera de tema, pero realmente me gustaría entender. ¿Por qué el intercambio, que usó 200 MB, ayudó cuando había 2 GB de RAM libre?

(Entiendo que en el mundo de las pulgadas, el sistema SI puede ser confuso porque usa una escala de 10, pero ¿por qué demonios Mi? Puedo entender Gi si es una abreviatura de giga, pero ¿debería mega ser Me?)

Supongo que Mi por Mebibytes y Gi por Gibibytes.

Gracias. No lo sabía, obvio. Pero es mebibyte

Y para otros que tampoco lo sabían

Creo que el problema original probablemente fue que un proceso fue eliminado porque la máquina se quedó sin memoria (cuidado con el asesino OOM). Agregar swap significó que la memoria no se agotó. Esas dos salidas de free podrían no contar toda la historia, a menos que se tomaran con mucho cuidado en el momento de mayor estrés de la máquina. Creo que lo interesante es el uso máximo del swap.

Pero también está la cuestión de la configuración del kernel como se menciona en
MKJ’s Opinionated Discourse Deployment Configuration
que tengo configurada correctamente, pero que quizás mucha gente no tiene configurada correctamente.

Vale la pena señalar que la sobreasignación de memoria no tiene mucho que ver con Redis. Es solo que Redis es lo suficientemente amable como para indicar que debe configurarse correctamente.

Acabo de iniciar otro /admin/upgrade y abrí una shell para llamar manualmente a tree -h cada segundo más o menos.

Los valores más altos de uso de memoria que pude encontrar fueron estos:

$ free -h
              total        used        free      shared  buff/cache   available
Mem:           3.8Gi       3.2Gi       120Mi        80Mi       542Mi       266Mi
Swap:          8.0Gi       276Mi       7.7Gi

La actualización se realizó correctamente.

Así que 4 GB está justo en el límite en el momento de la compilación, si suponemos que la última captura de pantalla muestra el momento más estresante.

Y esa es otra cosa que no entiendo: ¿por qué otros tienen poca memoria y yo, que uso muchos complementos y componentes, no tuve ningún problema qué marca esa diferencia?

Y usé tuve porque hoy en día tengo 8 GB debido a la IA (y para mí la diferencia de precio no era tan importante, pero esa es otra historia).

¿Debería este hilo moverse a otro lugar o estamos viendo esto como una explicación de por qué usar swap ayudó?

De todos modos. Para otros principiantes, este es un ejemplo donde se habla un poco sobre la poca memoria y las razones de ello:

Esa es una pregunta muy frecuente cuando la actualización falla. Pero la razón rara vez se explica.

@Jagster @uwe_keim ¿podrían informar la salida de estos comandos?

cat /proc/sys/vm/overcommit_memory
cat /sys/kernel/mm/transparent_hugepage/enabled

En mis sistemas tengo

# cat /proc/sys/vm/overcommit_memory
1
# cat /sys/kernel/mm/transparent_hugepage/enabled
always madvise [never]

$ cat /proc/sys/vm/overcommit_memory
0

y

$ cat /sys/kernel/mm/transparent_hugepage/enabled
always [madvise] never

Gracias @uwe_keim. Supongo que esos ajustables del kernel son la razón por la que necesitaste añadir swap, aunque no pareciera estar en uso. (Lo mismo aplicaría si hubieras necesitado añadir mucha RAM, porque la memoria total disponible es RAM + swap).

Puedo cambiar la configuración del servidor en cualquier momento si me recomiendas hacerlo.

root@foorumi-hel:/var/discourse# cat /proc/sys/vm/overcommit_memory
0
root@foorumi-hel:/var/discourse# cat /sys/kernel/mm/transparent_hugepage/enabled
always [madvise] never

¡Lo recomiendo!

Esto lo solucionará para futuros reinicios (ten en cuenta que sobrescribe archivos sin comprobar el estado actual):

echo 'sys.kernel.mm.transparent_hugepage.enabled=never' > /etc/sysctl.d/10-huge-pages.conf
echo 'vm.overcommit_memory=1' > /etc/sysctl.d/90-vm_overcommit_memory.conf
sysctl --system