La actualización desde /admin/upgrade tarda *mucho*

Al actualizar un único plugin desde admin/upgrade tarda mucho tiempo.

Normalmente, una reconstrucción completa se realiza en unos 7 minutos.

Se ha estado actualizando desde 2023-03-02T20:07:00Z, el estado ahora es:

Salida de HTOP:

EDITAR: 2023-03-02T20:44:00Z - todavía en la misma línea de registro. CPU sigue igual. Iniciada reconstrucción CLI en este punto.

EDITAR2: Para referenciar el tiempo exacto que tarda una reconstrucción en mi máquina, marca de tiempo de finalización de la reconstrucción: 2023-03-02T20:51:00Z

4 Me gusta

Sí, he estado experimentando lo mismo desde al menos ayer.

Ahora es más o menos imposible actualizar desde la pantalla de actualización en un tiempo razonable, por lo que te ves obligado a actualizar desde la línea de comandos.

La reconstrucción de la CLI se ha completado.

La actualización de administrador todavía está atascada y no parece que el plugin se haya actualizado.

Hice clic en RESET UPGRADE e inicié otra reconstrucción de la CLI.

1 me gusta

Yo también, tengo exactamente lo mismo. Muy irritante al actualizar plugins, lleva muchísimo tiempo - extremadamente inconveniente.

2 Me gusta

¿Hay alguna solución alternativa para esto? Cada vez que actualizo para mantenerme al día con los cambios en Discourse Chatbot :robot: (Soporta ChatGPT) - plugin - Discourse Meta, me lleva muchísimo tiempo.

Esto sigue siendo un problema.

Sin embargo, ¿parece afectar solo a los servidores de especificaciones inferiores?

1 me gusta

Solo para añadir una voz más en lugar de respuestas… :slight_smile:

Tengo un pequeño sitio de prueba DO de 1 GB con muchos complementos, por lo que normalmente no es el más rápido. Sin embargo, creo que últimamente también ha estado tardando mucho más, y el mío se quedó atrapado en una rareza el otro día como @MarcP y tuve que reiniciarlo.

Nunca lo había cronometrado antes, pero hoy lo configuré en ‘Actualizar todo’ y anoté cuándo hice clic en el botón. Hasta ahora tenemos un comienzo a las 9:30 a. m. y todavía está en marcha a las 10:15. Actualmente está empaquetando algunos activos. Puedo decir con cierta confianza que normalmente no tarda más de 45 minutos y contando en hacer lo suyo.

Aunque parece que tuvo algunos problemas de permisos al purgar archivos temporales. No estoy seguro de si eso es relevante.

4 Me gusta

@david y yo encontramos la causa raíz. (similar a lo que @Falco encontró en el pasado)

Usamos indicadores especiales de Ruby para intentar limitar la memoria durante las actualizaciones y esto ya no funciona en Ruby 3.2.

Deberíamos tener una PR en breve para solucionar el problema.

7 Me gusta
7 Me gusta

Nota… para que la corrección surta efecto, hay una pequeña situación de huevo o gallina. El código antiguo todavía se carga cuando ejecutas la actualización.

Es posible que necesites un ./launcher rebuild por primera vez, y las veces subsiguientes el actualizador web funcionará bien.

No hay una manera fácil de evitar esto. @cvx es un problema complicado… técnicamente deberíamos hacer que DockerManager::Upgrader.new(user_id, repo, repo_version).upgrade se conecte y ejecute el nuevo código del actualizador cuando actualiza… pero es una caja de Pandora.

Solución rápida

  1. Inicia la actualización del gestor de docker
  2. Cancela cuando se quede atascado
  3. Ejecuta ./launcher restart app desde la shell
  4. La actualización desde la web funcionará.

Solución fácil

  1. Ejecuta ./launcher rebuild app

Todo está bien después de esto.

EDITAR

Cerrando esto de forma preventiva porque quiero que esta sea la última publicación sobre este tema. Esto facilitará que las personas encuentren las soluciones. Marca para abrir si sigue siendo un problema después de una reconstrucción.

8 Me gusta