Discourse docker caído automáticamente

Hola a todos, mis problemas aparecen automáticamente en el foro de Discourse
Y a veces también recibo un error 502 Bad Gateway
unicorn.stderr.log

D, [2020-07-15T16:29:57.037389 #32767] DEBUG -- : esperando 16.0s después de suspender/hibernar
E, [2020-07-15T18:49:48.649399 #32767] ERROR -- : worker=0 PID:8593 tiempo agotado (31s > 30s), matando
E, [2020-07-15T18:49:50.220209 #32767] ERROR -- : recogido #<Process::Status: pid 8593 SIGKILL (signal 9)> worker=0
E, [2020-07-15T18:50:25.881312 #32767] ERROR -- : worker=2 PID:13929 tiempo agotado (31s > 30s), matando
E, [2020-07-15T18:50:25.881493 #32767] ERROR -- : worker=1 PID:32508 tiempo agotado (31s > 30s), matando
E, [2020-07-15T18:50:25.949739 #32767] ERROR -- : recogido #<Process::Status: pid 13929 SIGKILL (signal 9)> worker=2
E, [2020-07-15T18:50:25.949869 #32767] ERROR -- : recogido #<Process::Status: pid 32508 SIGKILL (signal 9)> worker=1
I, [2020-07-15T18:51:00.385865 #19149]  INFO -- : worker=0 listo
I, [2020-07-15T18:51:00.385899 #19193]  INFO -- : worker=2 listo
I, [2020-07-15T18:51:00.385899 #19189]  INFO -- : worker=1 listo
E, [2020-07-15T18:51:44.033303 #32767] ERROR -- : worker=2 PID:19193 tiempo agotado (31s > 30s), matando
E, [2020-07-15T18:51:44.051941 #32767] ERROR -- : recogido #<Process::Status: pid 19193 SIGKILL (signal 9)> worker=2
I, [2020-07-15T18:51:49.476608 #19302]  INFO -- : worker=2 listo
E, [2020-07-15T18:51:55.064179 #32767] ERROR -- : worker=1 PID:19189 tiempo agotado (31s > 30s), matando
E, [2020-07-15T18:51:55.085863 #32767] ERROR -- : recogido #<Process::Status: pid 19189 SIGKILL (signal 9)> worker=1
I, [2020-07-15T18:52:00.812373 #19324]  INFO -- : worker=1 listo

Eso significa que tu proceso web está tardando más de 30 segundos en responder. ¿Puedes eliminar todos los plugins personalizados y volver a construir?

iniciado ./launcher rebuild app
¡solo un plugin de gestor de Docker

¿Cuál es tu servidor? ¿Es muy lento? ¿Cuánta RAM tiene? ¿Tienes SSD o discos mecánicos? ¿Qué tamaño tiene tu base de datos?

El sistema está funcionando con normalidad
información
CPU: 50% i3 4 núcleos
Uso del disco de /: 7.9% de 1.79TB
Uso de memoria: 61% 8g
Uso de swap: 19% 4g

He reconstruido la aplicación, listo

 new_subscriber_thread'"]
I, [2020-07-15T19:56:10.094624 #72]  INFO -- : Actualizando la lista de Gem
I, [2020-07-15T19:56:41.824138 #72]  INFO -- : Escuchando en addr=127.0.0.1:3000 fd=9
I, [2020-07-15T19:57:06.077895 #72]  INFO -- : proceso maestro listo
I, [2020-07-15T19:57:17.979526 #229]  INFO -- : worker=2 listo
I, [2020-07-15T19:57:17.979509 #218]  INFO -- : worker=1 listo
I, [2020-07-15T19:57:17.979637 #241]  INFO -- : worker=3 listo
I, [2020-07-15T19:57:17.979868 #211]  INFO -- : worker=0 listo

mi problema continúa

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

¿Podrías responder al resto de las preguntas de Jay?

¿Esto está en un SSD? 2 TB sugiere que podría ser un disco SATA giratorio convencional, lo cual será demasiado lento para usar con Discourse.

Sí, un disco SATA de 2 TB suele funcionar rápido, pero está caído.

https://forum.wishl.net/

El SSD es el mínimo y está documentado en los requisitos de Discourse. Necesitarás un SSD; no podemos ayudarte si usas un disco giratorio.

¿Puedes entrar al contenedor y seguir otros registros?

Mi apuesta es que PostgreSQL no está logrando iniciarse, empieza a investigar eso.

hola, ¿qué archivo de registro debería revisar?

Si sirve de ayuda, el servidor de Discourse que ayudo a administrar ha empezado a mostrar mensajes de error 502 Bad Gateway desde hace aproximadamente un mes. Tanto el servidor como yo nos encontramos en Alemania. No puede tratarse de una regresión reciente de Discourse, ya que no hemos realizado ninguna actualización en meses. Funcionamos con un contrato de plataforma alojada muy básico. El servidor también es ahora realmente lento cuando logra conectarse con éxito. No tengo una buena explicación para este servicio degradado, pero imaginé que se debía simplemente a nuestro plan económico. Al leer este hilo, ¿quizás haya otras explicaciones? R.

Gracias por la respuesta.
El servidor transfirió el SSD, el problema se ha resuelto.

¡Hola! ¿Puedes decirme si usar discos duros de tipo vida mejora el rendimiento? Gracias.

El SSD es mucho más rápido que los discos magnéticos giratorios. Es ampliamente reconocido que se requiere un SSD, aunque conozco un sitio bastante grande que utilizó discos magnéticos. Esto resultó en al menos un cambio en el núcleo para darles soporte. Tomó semanas configurarlo. Si decides usar discos magnéticos, necesitarás más RAM para proporcionar más caché. Realmente no se recomienda.