La actualización 2.6.0 beta 3 falló en disco y/o espacio de memoria

Me pregunto si, además de los problemas de espacio en disco, el proceso de actualización superó la memoria disponible (1 GB) asignada al droplet. En la captura de pantalla de mi consola anterior se puede ver una referencia a ‘Out of memory’ como el primer elemento registrado después de ejecutar ./launcher rebuild app.

Lo que no mencioné es que, tras ese intento, la consola dejó de responder (aunque en ese momento estaba usando la consola basada en web en el panel de control de Digital Ocean, que siempre es inestable) y luego reinicié el droplet. (Desde entonces he usado PuTTY).

En cualquier caso, no es nada bueno que la actualización se haya reportado como exitosa en la página de actualización de Discourse, presumiblemente después de haber encontrado el mismo problema de memoria y/o disco.

Ah, el matador OOM se ejecutó. Eso definitivamente no es bueno. Normalmente recomendaría aumentar el espacio de intercambio. Puedes ver el uso actual con swapon; en mi caso:

# swapon 
NAME      TYPE SIZE USED PRIO
/swapfile file   2G   3M   -2

También free:

# free
              total        used        free      shared  buff/cache   available
Mem:        1992060      792904       80148       34696     1119008     1004956
Swap:       2097148        3084     2094064

Sería grave si tu archivo de intercambio de 2G no estuviera activo. Es problemático que no puedas agregar intercambio sin usar espacio en disco.

Una forma de liberar espacio en disco para una actualización es copiar todos los archivos de respaldo a un sitio externo, verificar su integridad y luego eliminarlos de tu servidor. Definitivamente necesitas una copia de seguridad reciente y confiable en un lugar seguro durante la actualización, por si acaso, pero no tiene que estar en el propio servidor. Me sentiría cómodo eliminando todas menos la más reciente, pero sin duda haría una copia offline.

Sería bueno ver nuevamente los resultados de du, ahora que has realizado todas las limpiezas.

Me pregunto: ¿es el 1G tu asignación de RAM y el 25G tu asignación de disco? Son dos cosas muy diferentes.

Edición: creo que la historia estándar soportada es tener bastante más de 1G de RAM.
Edición: no, al parecer 1G sigue siendo el mínimo absoluto recomendado.

Acabo de volver a conectarme y la información del sistema reportada al iniciar la ventana de la consola es:

Carga del sistema:  0.01               Procesos:              136
Uso de /:   59.4% de 24.06GB   Usuarios conectados:        0
Uso de memoria: 73%                Dirección IP de eth0:    159.65.140.176
Uso de swap:   17%                Dirección IP de docker0: 172.17.0.1

¿Entonces el espacio de swap del 17% equivale a 4 GB?
Sin nadie conectado al foro y solo con la conexión actual de PuTTY al droplet activa, la RAM está llena en un 73%. Por lo tanto, no parece que se necesite mucha actividad para que el foro comience a usar el espacio de swap. Y si esto consume parte de los 24 GB, quizás se cree la tormenta perfecta durante una actualización, dado que el uso del espacio en disco ya es alto.

du -kx / | sort -n | tail -33 ahora me muestra:

root@nz:~# du -kx / | sort -n | tail -33
505512  /usr/bin
528784  /var/lib/docker/overlay2/3b68a713bd8e9a7f3b2a69ba8084a770b796e555e887ce4f66698d3894430c35/diff/var/www/discourse/vendor/bundle/ruby/2.6.0
528788  /var/lib/docker/overlay2/3b68a713bd8e9a7f3b2a69ba8084a770b796e555e887ce4f66698d3894430c35/diff/var/www/discourse/vendor/bundle/ruby
528792  /var/lib/docker/overlay2/3b68a713bd8e9a7f3b2a69ba8084a770b796e555e887ce4f66698d3894430c35/diff/var/www/discourse/vendor/bundle
536848  /var/lib/docker/overlay2/3b68a713bd8e9a7f3b2a69ba8084a770b796e555e887ce4f66698d3894430c35/diff/var/www/discourse/vendor
548952  /var/lib/docker/overlay2/c126267f944d8d7f12415ac4f5908eba8a6a686b093cad3e0115eded8edfd6ba/diff
548968  /var/lib/docker/overlay2/c126267f944d8d7f12415ac4f5908eba8a6a686b093cad3e0115eded8edfd6ba
817700  /var/lib/docker/overlay2/3b68a713bd8e9a7f3b2a69ba8084a770b796e555e887ce4f66698d3894430c35/diff/usr/lib
827812  /var/log/journal/8bebc832e1a692c83690ffe65e1256e3
868792  /var/log/journal
1069356 /var/lib/docker/overlay2/3b68a713bd8e9a7f3b2a69ba8084a770b796e555e887ce4f66698d3894430c35/diff/var/www/discourse
1069368 /var/lib/docker/overlay2/3b68a713bd8e9a7f3b2a69ba8084a770b796e555e887ce4f66698d3894430c35/diff/var/www
1069396 /var/log
1142352 /var/lib/docker/overlay2/3b68a713bd8e9a7f3b2a69ba8084a770b796e555e887ce4f66698d3894430c35/diff/var
1202004 /var/discourse/shared/standalone/import/data
1307816 /var/discourse/shared/standalone/import
1362804 /var/lib/docker/overlay2/3b68a713bd8e9a7f3b2a69ba8084a770b796e555e887ce4f66698d3894430c35/diff/usr
1399332 /var/discourse/shared/standalone/backups/default
1399336 /var/discourse/shared/standalone/backups
1709408 /usr
2438224 /var/discourse/shared/standalone/postgres_data/base/16583
2462944 /var/discourse/shared/standalone/postgres_data/base
2481288 /var/discourse/shared/standalone/postgres_data
2540188 /var/lib/docker/overlay2/3b68a713bd8e9a7f3b2a69ba8084a770b796e555e887ce4f66698d3894430c35/diff
2540204 /var/lib/docker/overlay2/3b68a713bd8e9a7f3b2a69ba8084a770b796e555e887ce4f66698d3894430c35
3387776 /var/lib/docker/overlay2
3460136 /var/lib/docker
3830584 /var/lib
5629420 /var/discourse/shared/standalone
5629504 /var/discourse/shared
5632224 /var/discourse
10747244        /var
14961492        /
root@nz:~#

Creo que puedes mejorar esto con journalctl, quizás con:

# journalctl --vacuum-size=50M

(lo cual podrías hacer inmediatamente antes de intentar una actualización).

Es interesante que el uso de PostgreSQL no haya disminuido.

free te mostrará el uso de la memoria de intercambio: está al 17% de un cierto tamaño, probablemente 2 GB.

Está claro que tu máquina es un poco incómodamente pequeña: necesitas más RAM o más memoria de intercambio, y no puedes tener mucha más memoria de intercambio de manera práctica sin obtener más espacio en disco.

Disculpas: tienes toda la razón. El 1GB era RAM, no espacio en disco utilizado.

Tienes razón de nuevo

root@nz:~# free
              total        used        free      shared  buff/cache   available
Mem:        1008828      655660       61716      102288      291452       96576
Swap:       2097148      459776     1637372

Me pregunto si el proceso de actualización debería evaluar la capacidad del sistema host para implementar la actualización justo antes de que comience.

¡Creo que esto cae en cierta medida en la categoría de predecir el futuro! La verificación de 5 GB de espacio en disco es claramente útil, pero no será infalible. La RAM libre es más difícil de determinar; es bastante escurridizo saber cuánto se necesitará. Creo que dependerá de lo grande que se haya vuelto el foro y, quizás también, de qué elementos deben modificarse durante cada actualización.

Soy cuidadoso al minimizar los costos, por lo que dedicaré tiempo a intentar ajustarme a un servidor económico. Pero, con el tiempo, a medida que el foro crezca, sin duda valdrá la pena pasar al siguiente nivel. Y eso costará dinero, pero ahorrará tiempo y esfuerzo.

Por desgracia, me encuentro en el extremo de ‘minimizar costos’ de la escala: el foro es un esfuerzo puramente voluntario que no genera ingresos y, con la adición de la publicación por correo electrónico (a través de MailGun) exigida por los usuarios, me cuesta un poco cada mes mantenerlo en funcionamiento.

Como pasatiempo, supongo que es más barato que beber en discotecas.