Sto cercando di avviare un forum su Compute Engine di GCP, eseguendolo su un e2-micro. Penso che sia stato creato un file di swap da 2 GB quando ho provato ad eseguirlo per la prima volta.
10 GB non ha funzionato perché era troppo poco, se ricordo bene, quindi l’ho aumentato a 20 GB.
Dopo aver eseguito ./launcher rebuild app, ha iniziato a fare il suo dovere. Mentre stava facendo ...[@embroider/webpack, ci è voluto così tanto tempo che sono andato via e sono tornato più tardi (~2 ore dopo).
Ho scoperto che aveva finito, ma non riuscivo ad accedere al mio forum, anche se avevo collegato il mio record A di Namecheap con l’IP esterno della VM.
Ho riprovato e questi sono i log completi (i log sono troppo lunghi):
GCP e2-micro discourse logs.txt (176,7 KB)
Eppure, il mio sito Discourse non funziona. Ottengo:

502 Bad Gateway

nginx

Ora ricevo:

504 Gateway Time-out

nginx

Ho risolto! Non preoccuparti. Si è risolto da solo.

Ridurre i worker di Unicorn a 1 in containers/app.yml per conservare memoria, e poi ricostruire l’app con ./launcher rebuild app funziona per caso?

Oppure puoi temporaneamente aggiornare la tua istanza a e2-small o superiore, completare la ricostruzione, e poi ridimensionare nuovamente a e2-micro.

La ricostruzione ha già richiesto circa 2 ore. Non credo di voler aspettare così tanto per la terza volta.
A parte questo, la mia email ora non funziona.

L’email ora funziona, ma ho paura di installare plugin, dato che la ricompilazione richiederà circa 2 ore. So che non è normale, quindi c’è un modo per velocizzarla senza cambiare le risorse della VM?

È un’installazione fresca? O un’installazione fresca con il trasferimento del vecchio sito sul nuovo server?

2 ore sembrano molto lunghe nella mia esperienza.

Installazione pulita. Forse è perché il server ha 0,25 vCPU..?

Potrebbe essere. Se non le dispiace chiedergli quali sono le specifiche del sistema del VP?

Molto tempo fa. Uno dei server che gestisco come volontario era su un VP di base da 20g. E anche con quanto era grande il db su di esso, di solito ci volevano solo circa 15 minuti.

Alla fine il cliente è stato costretto a migrare su un server più grande dopo che si è bloccato duramente. Poiché all’epoca non hanno ascoltato il mio il server si sarebbe bloccato poiché non era più in grado di ricostruire tramite cmdline.

Quindi hanno pagato un membro qui per spostarlo su un nuovo server con un piano da 256g. È costato loro molto tempo di inattività, circa 2,5 settimane per aver ignorato il problema.

Dal lato positivo, per la maggior parte ora ascoltano meglio i quando vengono dati.

Credo che siano 0,25 vCPU e 1 GB di RAM. La configurazione ha creato un file di swap da 2 GB. Il server originale era dotato di 10 GB di spazio di archiviazione. Ma l’installazione ha indicato che era necessario più spazio per continuare, poiché ne rimanevano circa 1,7 GB. Quindi l’ho aumentato a 20 GB e non ho ancora visto alcun avviso relativo allo spazio di archiviazione.