'bundle exec rake db:migrate' tarda mucho debido a la migración del calendario

Instalación
1

Hola a todos, ¡espero que me ayuden!

¿Alguien ha experimentado esto antes?

./launcher rebuild app se está ejecutando, llega a este punto y simplemente se queda colgado aquí.

image
image1062×854 21.8 KB

Ahora está haciendo algo, pero lo está haciendo extremadamente lento. He estado ejecutando el foro a través de una instancia auto-instalada de Digital Ocean durante 3 años, pero esto es nuevo y está causando mucho tiempo de inactividad. ¿Hay alguna manera de suavizar esto? ¿Tiene que ver con las imágenes en el foro o algo así?

2

¿Puedes abrir otra sesión SSH e intentar encontrar qué migración está causando problemas?

Algo como ps aux | grep postgres debería mostrar el inicio.

1 me gusta
3

No soy un experto en Linux (o, francamente, ni siquiera un aficionado), pero lo intentaré.

1 me gusta
4

Me imagino que te estás quedando sin memoria. Puedes probar

free -h

Quizás también

du -hs /var/discourse/shared/standalone/*
1 me gusta
5

¿Memoria (RAM) o espacio en disco?

Creo que debería haber mucho de ambos: el Droplet es: 8 GB de memoria / 4 vCPUs Intel / 160 GB de disco + 200 GB / Ubuntu 18.04.3 (LTS) x64

¿Es “seguro” abrir otra sesión SSH y ejecutar eso mientras db:migrate todavía se está ejecutando?

6

Si fuera tú, empezaría por conseguir un nuevo VPS con un sistema operativo que todavía tenga soporte activo.

Sí.

7

De acuerdo. Por favor, entiende que NO soy un experto en Linux. ¿Tu publicación insinúa que la compilación actual de Ubuntu está muy desactualizada, etc.?

8

Sí, el sistema operativo data de abril de 2018 y tuvo soporte durante 5 años, por lo que finalizó hace más de 6 meses.

2 Me gusta
9

Agradezco la información.

Como alguien que admite libremente que soy un aficionado haciendo lo mejor que puedo, ¿alguna recomendación sobre qué debería hacer a continuación?

db:migrate falló - el mensaje fue:

client_loop: send disconnect: Connection reset

Al volver a iniciar sesión, tiene usted toda la razón:

Nueva versión ‘20.04.6 LTS’ disponible.
Ejecute ‘do-release-upgrade’ para actualizar a ella.

Considerando que mi foro está actualmente caído, ¿puedo realizar la actualización de forma segura y luego preocuparme por arreglar el foro? ¿o debería intentar ponerlo en línea primero?

10

:thinking: Ese es un error de SSH…

¿Hiciste una copia de seguridad antes de actualizar? Si es así, lo más fácil sería conseguir un servidor nuevo con Ubuntu 22, instalar Discourse y restaurar la copia de seguridad.

1 me gusta
11

Lamentablemente, uno de mis administradores presionó el botón de actualización en el sitio, y parece que falló y luego lo rompió todo. :smiley:

La última copia de seguridad se realizó ayer, así que no está tan mal.

Supongo que una actualización del servidor existente borraría la instalación actual, ¿verdad?

(Gracias por tu paciencia @RGJ, por cierto)

12

Difícil de decir, pero como las cosas están fallando, no me arriesgaría. Al menos no antes de asegurarme de que la copia de seguridad se almacene en un lugar seguro.

13

Es muy probable que puedas iniciar una nueva VM, detener el contenedor (parece que de todos modos no se está ejecutando) y luego usar rsync para transferir todo al nuevo servidor e intentarlo de nuevo allí. Esto probablemente te permitirá volver a poner todo en funcionamiento sin perder datos.

14

Todo suena tan simple, pero hombre, me siento fuera de mi elemento aquí. Actualmente se está ejecutando en una instancia de DigitalOcean. Entonces, ¿iniciar una nueva VM, esa es una oración cargada? ¿En la misma instancia? ¿En una nueva? :woozy_face:

15

Una VM es el término común para lo que DigitalOcean llama una droplet.

Parece que quizás quieras echar un vistazo a mi perfil y considerar el hosting administrado :wink:

1 me gusta
16 
ystemd+  7660  0.0  0.3 352060 28284 ?        S    22:31   0:00 /usr/lib/postgresql/13/bin/postmaster -D /etc/postgresql/13/main
systemd+  7667  0.0  0.1 352588  9628 ?        Ss   22:31   0:00 postgres: 13/main: checkpointer 
systemd+  7668  0.3  0.9 352060 78796 ?        Ss   22:31   0:03 postgres: 13/main: background writer 
systemd+  7669  0.0  0.1 352060 13696 ?        Ss   22:31   0:00 postgres: 13/main: walwriter 
systemd+  7670  0.0  0.1 352728 11892 ?        Ss   22:31   0:00 postgres: 13/main: autovacuum launcher 
systemd+  7671  0.0  0.0  67996  5320 ?        Ss   22:31   0:00 postgres: 13/main: stats collector 
systemd+  7672  0.0  0.0 352612  6640 ?        Ss   22:31   0:00 postgres: 13/main: logical replication launcher 
systemd+ 10900 82.0  3.8 487164 317728 ?       Rs   22:33  10:42 postgres: 13/main: discourse discourse [local] DELETE
systemd+ 10901  0.0  0.1 353432 13804 ?        Ss   22:33   0:00 postgres: 13/main: discourse discourse [local] idle

htop muestra que el discourse [local] delete es lo que está consumiendo el 100% de la CPU. El droplet tiene 8 GB de RAM y ahora mismo se usa <1 GB (sin contar los búferes).

El sistema operativo está desactualizado, pero esto me parece muy extraño. Hay mucha RAM y disco, y esa tarea de eliminación de postgres ha estado ejecutándose durante >12 minutos. Hay menos de 600K publicaciones y <4K usuarios, por lo que la base de datos no es enorme. Oh. Espera. el directorio postgres_data tiene 28 GB.

Ejecuté un VACUUM VERBOSE ANALYZE;.

Hice esto:

discourse=# SELECT checkpoints_timed, checkpoints_req FROM pg_stat_bgwriter; 
 checkpoints_timed | checkpoints_req 
-------------------+-----------------
                 6 |              20

Ahora estoy intentando reindexar concurrentemente. Quizás el vacuum y el reindex ayuden.

17

Gracias Jay. Hazme saber si necesitas algo de mi parte.

18

Por favor, comparte todo el SQL de la consulta de larga duración.

19

¿Dónde encuentro eso?

La migración no está imprimiendo ningún registro. La última línea en la reconstrucción es

I, [2023-12-04T22:33:33.759401 #1]  INFO -- : cd /var/www/discourse & su discourse -c 'bundle exec rake db:migrate'

Estoy trabajando en un registro completo para el que acabo de reiniciar.

20

Entra en el contenedor, cambia al usuario postgres, entra en psql y ejecuta

SELECT pid, age(clock_timestamp(), query_start), usename, query
FROM pg_stat_activity
WHERE query != '<IDLE>' AND query NOT ILIKE '%pg_stat_activity%'
ORDER BY query_start desc;