Le build impiegano molto tempo

Installazione
21

Le mie ricompilazioni richiedono circa 10 minuti. Penso che prima fossero più simili a 5. Quindi nessun problema. Cosa significa però il messaggio di errore? Ricevo qualcosa di simile a quello nel post originale sopra:

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".
22

Aggiungerò altro a questo, sto eseguendo un sistema snello (1 GB di RAM) e un sito piccolo. Ha 2 worker unicorn e tra di loro ciascuno occupava il 30% della memoria, il che causava un sacco di memory thrashing, quindi ho deciso di ridurre il numero da 2 a 1 (che credo possa gestire circa 10 connessioni simultanee ciascuno). Ciò ha fatto un’ENORME differenza e ha reso i caricamenti delle pagine quasi istantanei e ha ridotto lo swapping di un fattore da 5 a 10 (a seconda di cosa veniva caricato).

Lo svantaggio che vedo ora è che non posso più utilizzare gli aggiornamenti tramite browser per aggiornare discourse. Quando provo ad aggiornare tramite browser ottengo

ABORTING, you do not have enough unicorn workers running
Docker Manager: FAILED TO UPGRADE
#<RuntimeError: Not enough workers>

Quindi solo qualcosa da notare, non sono sicuro se questo sia qualcosa che il team Discourse possa risolvere/affrontare: eseguire aggiornamenti tramite browser con un singolo worker unicorn.

2 Mi Piace
23

Questo sembra un bug, soprattutto perché il sistema si riduce temporaneamente a un singolo unicorn poco dopo.

Il numero 2 è codificato in modo fisso, così come il numero 1 per la riduzione.

Modifica: sembra che questa modifica abbia introdotto l’incoerenza

Penso che il tuo post (e questa risposta) dovrebbero essere in un nuovo thread, nella categoria dei bug.

4 Mi Piace
25

Come funziona?

Un Unicorn per gestire il processo di aggiornamento, mentre i restanti gestiscono le chiamate in corso?

E quindi sono necessari almeno 2 Unicorn Worker per eseguire aggiornamenti online…?

26

Questo è sbagliato. Un singolo unicorn può gestire solo una richiesta alla volta, quindi, sebbene utilizzabile per piccoli gruppi, non è qualcosa che raccomanderemmo per la maggior parte dei siti.

1 Mi Piace
27

@Falco Ho esaminato i dati di altri amministratori. La mia comprensione è che ogni Unicorn crea un nuovo processo per ogni connessione in entrata. Quindi, mentre si tratta tecnicamente di una connessione alla volta, ogni unicorn può gestire più utenti contemporaneamente.

Basandomi sull’esperienza condivisa di seguito, circa 8 Unicorn possono gestire circa 400 utenti contemporaneamente.

Sulla base di ciò, sembra che ogni unicorn possa gestire circa 50 utenti contemporaneamente. Ora so che la RAM e le risorse di sistema fanno la differenza nel numero di fork che possono essere eseguiti, ecc., da qui la mia ipotesi che 1 worker unicorn possa gestire 10 utenti contemporaneamente su un sistema con poca RAM (1 GB) al livello più basso.

Le mie ipotesi e conclusioni sono completamente fuori strada? Se sì, quale sarebbe un intervallo di utenti contemporanei che ogni Unicorn può gestire a seconda delle risorse di sistema (assumendo 1 GB al livello più basso e qualsiasi cosa tu ritenga appropriata come livello più alto)?

1 Mi Piace
28

C’è una differenza tra sessioni utente concorrenti e connessioni concorrenti. Una sessione è un utente online e ognuno di essi effettua una richiesta (connessione) ogni volta che interagisce.

Non lo fa. Unicorn crea un numero fisso di processi worker all’avvio.

1 Mi Piace
29

E, credo che abbiamo visto, ogni processo worker esegue 10 thread.