Discourse docker va giù automaticamente

Ciao a tutti, i miei problemi vengono automaticamente chiusi sul forum Discourse.
A volte ricevo anche l’errore 502 Bad Gateway.
unicorn.stderr.log

D, [2020-07-15T16:29:57.037389 #32767] DEBUG -- : in attesa di 16,0s dopo sospensione/ibernazione
E, [2020-07-15T18:49:48.649399 #32767] ERROR -- : worker=0 PID:8593 timeout (31s > 30s), terminazione
E, [2020-07-15T18:49:50.220209 #32767] ERROR -- : raccolto #<Process::Status: pid 8593 SIGKILL (segnale 9)> worker=0
E, [2020-07-15T18:50:25.881312 #32767] ERROR -- : worker=2 PID:13929 timeout (31s > 30s), terminazione
E, [2020-07-15T18:50:25.881493 #32767] ERROR -- : worker=1 PID:32508 timeout (31s > 30s), terminazione
E, [2020-07-15T18:50:25.949739 #32767] ERROR -- : raccolto #<Process::Status: pid 13929 SIGKILL (segnale 9)> worker=2
E, [2020-07-15T18:50:25.949869 #32767] ERROR -- : raccolto #<Process::Status: pid 32508 SIGKILL (segnale 9)> worker=1
I, [2020-07-15T18:51:00.385865 #19149]  INFO -- : worker=0 pronto
I, [2020-07-15T18:51:00.385899 #19193]  INFO -- : worker=2 pronto
I, [2020-07-15T18:51:00.385899 #19189]  INFO -- : worker=1 pronto
E, [2020-07-15T18:51:44.033303 #32767] ERROR -- : worker=2 PID:19193 timeout (31s > 30s), terminazione
E, [2020-07-15T18:51:44.051941 #32767] ERROR -- : raccolto #<Process::Status: pid 19193 SIGKILL (segnale 9)> worker=2
I, [2020-07-15T18:51:49.476608 #19302]  INFO -- : worker=2 pronto
E, [2020-07-15T18:51:55.064179 #32767] ERROR -- : worker=1 PID:19189 timeout (31s > 30s), terminazione
E, [2020-07-15T18:51:55.085863 #32767] ERROR -- : raccolto #<Process::Status: pid 19189 SIGKILL (segnale 9)> worker=1
I, [2020-07-15T18:52:00.812373 #19324]  INFO -- : worker=1 pronto

Ciò significa che il tuo processo web impiega oltre 30 secondi per rispondere. Puoi rimuovere tutti i plugin personalizzati e ricostruire?

avviato ./launcher rebuild app
solo un plugin del gestore docker

Qual è il tuo server? È molto lento? Quanta RAM ha? Hai un SSD o dischi meccanici? Quanto è grande il tuo database?

Il sistema sta funzionando normalmente
informazioni
CPU: 50% i3 4 core
Utilizzo del disco di /: 7.9% di 1.79TB
Utilizzo della memoria: 61% 8g
Utilizzo dello swap: 19% 4g

Ho completato la ricostruzione dell’app

 new_subscriber_thread'"] 
I, [2020-07-15T19:56:10.094624 #72]  INFO -- : Aggiornamento dell'elenco dei Gem
I, [2020-07-15T19:56:41.824138 #72]  INFO -- : in ascolto su addr=127.0.0.1:3000 fd=9
I, [2020-07-15T19:57:06.077895 #72]  INFO -- : processo master pronto
I, [2020-07-15T19:57:17.979526 #229]  INFO -- : worker=2 pronto
I, [2020-07-15T19:57:17.979509 #218]  INFO -- : worker=1 pronto
I, [2020-07-15T19:57:17.979637 #241]  INFO -- : worker=3 pronto
I, [2020-07-15T19:57:17.979868 #211]  INFO -- : worker=0 pronto

Il mio problema continua

tail -100 unicorn.stderr.log

    I, [2020-07-16T07:51:49.785061 #72] INFO -- : master done reopening logs

    I, [2020-07-16T07:52:05.423701 #18420] INFO -- : worker=3 done reopening logs

    I, [2020-07-16T07:52:05.439574 #10177] INFO -- : worker=2 done reopening logs

    I, [2020-07-16T07:52:06.614121 #11282] INFO -- : worker=1 done reopening logs

    I, [2020-07-16T07:52:06.626403 #30350] INFO -- : worker=0 done reopening logs

    E, [2020-07-16T13:43:49.118620 #72] ERROR -- : worker=1 PID:11282 timeout (31s > 30s), killing

    E, [2020-07-16T13:43:49.325644 #72] ERROR -- : reaped #<Process::Status: pid 11282 SIGKILL (signal 9)> worker=1

    D, [2020-07-16T13:44:19.448200 #72] DEBUG -- : waiting 16.0s after suspend/hibernation

    I, [2020-07-16T13:44:31.441735 #10639] INFO -- : worker=1 ready

    E, [2020-07-16T14:24:40.454209 #72] ERROR -- : worker=1 PID:10639 timeout (31s > 30s), killing

    E, [2020-07-16T14:24:40.611580 #72] ERROR -- : reaped #<Process::Status: pid 10639 SIGKILL (signal 9)> worker=1

    D, [2020-07-16T14:25:10.744135 #72] DEBUG -- : waiting 16.0s after suspend/hibernation

    I, [2020-07-16T14:25:14.973408 #13472] INFO -- : worker=1 ready

    E, [2020-07-16T16:03:01.918109 #72] ERROR -- : worker=2 PID:10177 timeout (31s > 30s), killing

    E, [2020-07-16T16:03:02.200133 #72] ERROR -- : reaped #<Process::Status: pid 10177 SIGKILL (signal 9)> worker=2

    I, [2020-07-16T16:03:51.690756 #20266] INFO -- : worker=2 ready

    E, [2020-07-16T18:29:27.607372 #72] ERROR -- : worker=1 PID:13472 timeout (31s > 30s), killing

    E, [2020-07-16T18:29:27.831050 #72] ERROR -- : reaped #<Process::Status: pid 13472 SIGKILL (signal 9)> worker=1

    I, [2020-07-16T18:29:59.339086 #30397] INFO -- : worker=1 ready

    E, [2020-07-16T18:51:56.470192 #72] ERROR -- : worker=0 PID:30350 timeout (31s > 30s), killing

    E, [2020-07-16T18:51:57.004078 #72] ERROR -- : reaped #<Process::Status: pid 30350 SIGKILL (signal 9)> worker=0

    I, [2020-07-16T18:52:43.150079 #31968] INFO -- : worker=0 ready
D, [2020-07-16T19:13:52.263197 #72] DEBUG -- : waiting 16.0s after suspend/hibernation

Potresti rispondere alle restanti domande di Jay?

È su SSD? 2TB suggerisce che potrebbe essere un disco SATA meccanico tradizionale, che sarà troppo lento da utilizzare con Discourse.

Sì, un disco SATA da 2 TB funziona normalmente in modo veloce, ma ora è inattivo.

https://forum.wishl.net/

L’SSD è il requisito minimo ed è documentato nei requisiti di Discourse. Avrai bisogno di un SSD; non possiamo aiutarti se utilizzi un disco meccanico.

Puoi accedere al contenitore e seguire altri log?

La mia scommessa è che PostgreSQL non riesca ad avviarsi; inizia a indagare su questo.

ciao, quale file di log dovrei guardare?

Se può essere d’aiuto, il server Discourse che aiuto a gestire sta ricevendo messaggi di errore 502 Bad Gateway da circa un mese. Sia il server che io siamo situati in Germania. Non può trattarsi di un recente regresso di Discourse, dato che non abbiamo effettuato aggiornamenti da mesi. Utilizziamo un piano di hosting molto basilare. Il server è anche diventato molto lento quando riesce a connettersi con successo. Non ho una spiegazione soddisfacente per questo servizio degradato, ma pensavo fosse semplicemente dovuto al nostro piano economico. Leggendo questo thread, forse ci potrebbero essere altre spiegazioni? R.

Grazie per la risposta.
Il server ha trasferito l’SSD, il problema è stato risolto.

Ciao! Puoi dirmi che l’uso di dischi rigidi di tipo ‘life’ può migliorare le prestazioni? Grazie.

L’SSD è molto più veloce dei dischi magnetici rotanti. È ampiamente riconosciuto che l’SSD è necessario, anche se sono a conoscenza di un sito abbastanza grande che ha utilizzato dischi magnetici. Ciò ha portato ad almeno una modifica al core per supportarli. La configurazione ha richiesto settimane. Se si utilizzano dischi magnetici, sarà necessaria più RAM per fornire più cache. Non è davvero raccomandato.