Las compilaciones tardan mucho tiempo

Mis reconstrucciones tardan unos 10 minutos. Creo que antes eran más como 5. Así que no es gran cosa. ¿Qué significa el mensaje de error? Me sale algo parecido al de la publicación original de arriba:

I, [2022-06-20T21:41:47.107238 #1]  INFO -- : cd /var/www/discourse && [ ! -d 'node_modules' ] || su discourse -c 'yarn install --production && yarn cache clean'
warning "eslint-config-discourse > eslint-plugin-lodash@7.1.0" has unmet peer dependency "lodash@>=4".
warning " > @mixer/parallel-prettier@2.0.1" has unmet peer dependency "prettier@^2.0.0".

También voy a añadir más a esto, estoy ejecutando un sistema liviano (1 GB de RAM) y un sitio pequeño. Tiene 2 trabajadores unicorn y entre ellos cada uno consumía el 30% de la memoria, lo que estaba causando mucha fragmentación de memoria, así que decidí reducir el número de 2 a 1 (que creo que puede manejar aproximadamente 10 conexiones concurrentes cada uno). Esto marcó una GRAN diferencia e hizo que las cargas de página fueran casi instantáneas y redujo el swapping en un factor de 5 a 10 (dependiendo de lo que se estuviera cargando).

La desventaja que veo ahora es que ya no puedo usar las actualizaciones del navegador para actualizar Discourse. Cuando intento actualizar a través del navegador, obtengo:

ABORTANDO, no tienes suficientes trabajadores unicorn en ejecución
Docker Manager: FALLÓ LA ACTUALIZACIÓN
#<RuntimeError: No hay suficientes trabajadores>

Así que solo algo a tener en cuenta, no estoy seguro de si esto es algo que el equipo de Discourse pueda resolver/abordar: realizar actualizaciones del navegador con un solo trabajador unicorn.

2 Me gusta

Esto parece un error, especialmente porque el sistema se reduce temporalmente a un solo unicorn poco después.

El número 2 está codificado, al igual que el número 1 para la reducción.

Editar: parece que este cambio introdujo la inconsistencia

Creo que tu publicación (y esta respuesta) deberían estar en un nuevo hilo, en la categoría de errores.

4 Me gusta

¿Cómo funciona esto?

¿Un Unicorn para gestionar el proceso de actualización, mientras que los restantes atienden las llamadas en curso?

¿Y por lo tanto se requieren un mínimo de 2 Unicorn Workers para realizar actualizaciones en línea…?

Esto es incorrecto. Un solo unicornio solo puede manejar una solicitud a la vez, por lo que, si bien es utilizable para grupos pequeños, no es algo que recomendaríamos para la mayoría de los sitios.

1 me gusta

@Falco Miré los datos de otros administradores. Entiendo que cada Unicorn crea un nuevo proceso por cada conexión entrante. Por lo tanto, aunque técnicamente es una conexión a la vez, cada unicornio puede manejar múltiples usuarios simultáneos.

Según la experiencia compartida a continuación, aproximadamente 8 Unicornios pueden manejar unos 400 usuarios simultáneos.

Según eso, parece que cada unicornio puede manejar unos 50 usuarios simultáneos. Ahora bien, sé que la RAM y los recursos del sistema marcan la diferencia en el número de forks que se pueden hacer, etc., de ahí mi suposición de que 1 trabajador unicornio puede manejar 10 usuarios simultáneos en un sistema con poca RAM (1 GB) en el extremo inferior.

¿Mis suposiciones + conclusiones están completamente equivocadas? Si es así, ¿cuál sería un rango de usuarios simultáneos que cada unicornio puede manejar dependiendo de los recursos del sistema (asumiendo 1 GB en el extremo inferior y cualquier cosa que consideres apropiada como extremo superior)?

1 me gusta

Hay una diferencia entre sesiones de usuario simultáneas y conexiones simultáneas. Una sesión es un usuario en línea, y cada uno de ellos realiza una solicitud (conexión) cada vez que interactúa.

No lo hace. Unicorn se divide en un número determinado de procesos de trabajo al iniciarse.

1 me gusta

Y, creo que vimos, cada proceso de trabajo ejecuta 10 hilos.