Picchi CPU per aggiornamenti/ricompilazioni

Ho appena avuto l’esperienza più strana facendo un semplice riavvio della mia istanza Amazon Lightsail.

  1. Ho eseguito il riavvio… ho atteso il riavvio.
  2. Ho ottenuto la schermata con il messaggio di errore “502 Gateway Error - Nginx” su alcune pagine (presumo non cache). Ho aspettato un po’…
  3. Ho eseguito un rebuild di Discourse tramite shell.
  4. Ho ottenuto un messaggio di errore che indicava che il rebuild era fallito.
  5. Ho usato ./discourse-doctor - Anche questo è fallito.
  6. Ho disabilitato i plugin non ufficiali e ho eseguito di nuovo il rebuild - Anche questo è fallito.

Pensavo di essere nei guai. Mentre facevo ulteriori ricerche, ho ricontrollato il forum solo per scoprire che funzionava regolarmente. Il che non ha assolutamente senso, considerando che la risposta immediata della documentazione di Discourse era: ATTENZIONE! L’applicazione non è nemmeno in esecuzione! :slight_smile:

La mia teoria è che questo possa essere dovuto più ai limiti burst di Amazon che a qualcos’altro. Dato che il riavvio potrebbe aver sollecitato il server, causando alcuni problemi iniziali con gli errori 502, ma certamente il rebuild ha portato il server al 70-80% dei limiti burst e forse non c’erano risorse di sistema sufficienti per eseguire gli script di rebuild?

Quindi la mia domanda finale è (visto che questo è un problema che affligge il processo di rebuild durante gli aggiornamenti), c’è un modo per limitare il carico degli script di aggiornamento sul server ed evitare che vada in tilt? Voglio dire, si tratta di un’istanza da 8 GB di RAM, quindi non è così debole, ecc.

Grazie… e ora ho preso due Ativan senza motivo. :smiley:

È difficile dirlo dalla tua descrizione. Quali errori ricevi quando ricompili?

Proverò un altro aggiornamento presto e aggiornerò questa voce. Non ho salvato il file di log e l’esecuzione degli aggiornamenti fa schizzare la mia zona di burst in modo piuttosto significativo (specialmente dopo averlo eseguito 3 volte), quindi ho dovuto aspettare un giorno o due per recuperare i miei livelli di burst.

Sembra che questo sia il colpevole.

Seeding default
*** Bundling assets. This will take a while *** 
$ RUBY_GC_MALLOC_LIMIT_MAX=20971520 RUBY_GC_OLDMALLOC_LIMIT_MAX=20971520 RUBY_GC_HEAP_GROWTH_MAX_SLOTS=50000 RUBY_GC_HEAP_OLDOBJECT_LIMIT_FACTOR=0.9  bundle exec rake themes:update assets:precompile
Updating Dark...
Failed to update Dark
about.json contains invalid values: Maximum discourse version is invalid

E ora il mio forum è completamente fuori servizio e restituisce un errore 500. :frowning:

Perché dovrebbe succedere? Pensavo che l’aggiornamento sostituisse il forum funzionante corrente solo una volta completato il processo e non causasse problemi?

Non so quale fosse il tuo problema originale, ma questo è il problema attuale: Failed to Bootstrap, due to discourse-alt-logo theme component

Dovresti poter

 ./launcher start app

e poi eliminare il componente del tema difettoso.

Ma il tema scuro non è un componente del tema di sistema? Come potrebbe un componente del tema di sistema causare un problema del genere?

Grazie comunque, ora che so cosa sta succedendo, probabilmente riuscirò a risolvere il problema.

Il componente tema è deprecato e Discourse si rifiuta di utilizzarlo.

Tuttavia, se esegui ./launcher rebuild app, il container viene arrestato per costruire quello nuovo (poiché utilizza gli stessi file del database). Se la compilazione fallisce, dovrai riavviare il container per riportarlo in funzione.

Sì, ho notato che l’aggiornamento era effettivamente completato su tutti gli altri elementi: una volta eliminati i componenti Dark e Alternate Logos, tutto è stato aggiornato nella schermata di aggiornamento.