Un altro mistero di discourse

Ricevo un avviso AWS CloudWatch alle 21:09 ET, insieme ad alcuni amici che mi scrivono “ehi, Discourse è giù?”

Non riesco ad accedere all’istanza AWS Lightsail tramite SSH e tutte le metriche sono bloccate/non segnalano.

Alla fine mi arrendo e interrompo/riavvio l’istanza Lightsail.
Il servizio è stato ripristinato.

Controllo i log dopo il ripristino del servizio, cercando di capire.

Eseguo Discourse come singola istanza, quindi l’errore alle 21:05 riguardo la connessione di rete Redis mi lascia perplesso.

Non riesco a capire cosa sia successo, se non che “qualcosa” si è bloccato/fallito per “qualche motivo”.

Chiunque possa spiegare o lasciare qualche indizio è apprezzato.

Grazie!

Quali sono le specifiche del server? Sembra che stia esaurendo le risorse? Molto probabilmente la CPU. Forse c’è qualche attività giornaliera in esecuzione in quel momento?

È un’istanza lightsail da 1 vCPU, 1 GB di RAM, 40 GB SSD.

Lo spazio di archiviazione è consumato per circa il 60% e quando eseguo delle pulizie diminuisce parecchio.

AWS mostra che ho esaurito i crediti CPU “burstable”, il che è strano solo perché le altre metriche non lo supportano.

È una community piuttosto piccola (20-30 partecipanti attivi), quindi sarei sorpreso se ci fosse un reale vincolo di CPU o RAM.

Nessun’attività giornaliera di cui sono a conoscenza, a parte qualcosa che discourse potrebbe pianificare per impostazione predefinita.

1GB con swap è il minimo assoluto per eseguire discourse.

Da quanto tempo è attiva questa istanza? Quanto è grande il database?

3 Mi Piace

Controllerò la dimensione del database, non mi aspetto che sia grande (i backup sono tutti di circa 57 MB).

L’uptime dell’istanza è di poco meno di dieci ore da quando il ripristino ha richiesto l’arresto e il riavvio del server virtuale: non sono riuscito a ottenere una connessione shell o console.

Funziona bene su questo tipo di istanza da quando l’ho costruita (febbraio 2021, a grandi linee).

Sembra quello che succede quando AWS sposta la tua VM da un host all’altro e la lascia in uno stato strano a causa di ciò. Di solito un riavvio risolve il problema.

5 Mi Piace

La dimensione complessiva del database è 423 MB.

Le tabelle più grandi sono
Posts 66 MB
Post_timings 60 MB

Si è verificato un secondo guasto simile per “carico elevato”.

Suppongo che sia dovuto a contesa di risorse.

Qualcuno ha provato a utilizzare lo snapshot di Lightsail per creare uno snapshot dell’istanza e ripristinarlo su un’istanza più grande come metodo di aggiornamento?

Puoi provare a riavviare l’istanza AWS, questo può risolvere molti problemi.

Mi sono spostato usando uno snapshot di Lightsail da 1 CPU, 1 GB di RAM, 40 GB SSD a 2 CPU, 4 GB di RAM, 80 GB di SSD.

A parte dover scollegare l’IP pubblico e ricollegarlo, cosa che è stata abbastanza semplice, le mie preoccupazioni rimanenti sono “cosa mi sono perso”?

C’è qualcosa (backup, email, configurazione del bucket S3, ecc.) che dovrei controllare o devo rieseguire alcuni parametri di installazione iniziali per sfruttare le risorse aggiornate?

Sto pensando che, in base a questo link, potrei aumentare il db_shared_buffer ad almeno 1 GB.
L’attuale app.yml dice 128 MB, indica anche l’aggiustamento automatico all’avvio.

1 GB va bene per un sistema da 4 GB. Assicurati di aggiornare anche unicorn_workers a 4.

La raccomandazione usuale se stessi passando da un server all’altro sarebbe di rieseguire discourse-setup che si occuperebbe automaticamente di quanto sopra.

1 Mi Piace

Grazie. Ora mi sto addentrando nel mondo di Prometheus.

Ottimo materiale.