Discourse docker automatiquement en panne

Bonjour à tous, mes problèmes sont automatiquement supprimés du forum Discourse.
Et parfois, je reçois également une erreur 502 Bad Gateway.

unicorn.stderr.log

D, [2020-07-15T16:29:57.037389 #32767] DEBUG -- : attente de 16,0 s après la suspension/mise en veille prolongée
E, [2020-07-15T18:49:48.649399 #32767] ERROR -- : worker=0 PID:8593 timeout (31s > 30s), killing
E, [2020-07-15T18:49:50.220209 #32767] ERROR -- : reaped #<Process::Status: pid 8593 SIGKILL (signal 9)> worker=0
E, [2020-07-15T18:50:25.881312 #32767] ERROR -- : worker=2 PID:13929 timeout (31s > 30s), killing
E, [2020-07-15T18:50:25.881493 #32767] ERROR -- : worker=1 PID:32508 timeout (31s > 30s), killing
E, [2020-07-15T18:50:25.949739 #32767] ERROR -- : reaped #<Process::Status: pid 13929 SIGKILL (signal 9)> worker=2
E, [2020-07-15T18:50:25.949869 #32767] ERROR -- : reaped #<Process::Status: pid 32508 SIGKILL (signal 9)> worker=1
I, [2020-07-15T18:51:00.385865 #19149]  INFO -- : worker=0 ready
I, [2020-07-15T18:51:00.385899 #19193]  INFO -- : worker=2 ready
I, [2020-07-15T18:51:00.385899 #19189]  INFO -- : worker=1 ready
E, [2020-07-15T18:51:44.033303 #32767] ERROR -- : worker=2 PID:19193 timeout (31s > 30s), killing
E, [2020-07-15T18:51:44.051941 #32767] ERROR -- : reaped #<Process::Status: pid 19193 SIGKILL (signal 9)> worker=2
I, [2020-07-15T18:51:49.476608 #19302]  INFO -- : worker=2 ready
E, [2020-07-15T18:51:55.064179 #32767] ERROR -- : worker=1 PID:19189 timeout (31s > 30s), killing
E, [2020-07-15T18:51:55.085863 #32767] ERROR -- : reaped #<Process::Status: pid 19189 SIGKILL (signal 9)> worker=1
I, [2020-07-15T18:52:00.812373 #19324]  INFO -- : worker=1 ready

Cela signifie que votre processus web met plus de 30 secondes à répondre. Pouvez-vous supprimer tous les plugins personnalisés et reconstruire ?

démarré ./launcher rebuild app
uniquement un seul plugin de gestionnaire Docker

Quel est votre serveur ? Est-il très lent ? Combien de RAM ? Avez-vous un SSD ou des disques mécaniques ? Quelle est la taille de votre base de données ?

Le système fonctionne normalement
information
CPU : 50 % i3 4 cœurs
Utilisation du disque / : 7,9 % sur 1,79 To
Utilisation de la mémoire : 61 % 8 Go
Utilisation du swap : 19 % 4 Go

Reconstruction de l’application terminée

 new_subscriber_thread'"] 
I, [2020-07-15T19:56:10.094624 #72]  INFO -- : Actualisation de la liste des Gems
I, [2020-07-15T19:56:41.824138 #72]  INFO -- : écoute sur addr=127.0.0.1:3000 fd=9
I, [2020-07-15T19:57:06.077895 #72]  INFO -- : processus maître prêt
I, [2020-07-15T19:57:17.979526 #229]  INFO -- : worker=2 prêt
I, [2020-07-15T19:57:17.979509 #218]  INFO -- : worker=1 prêt
I, [2020-07-15T19:57:17.979637 #241]  INFO -- : worker=3 prêt
I, [2020-07-15T19:57:17.979868 #211]  INFO -- : worker=0 prêt

Mon problème persiste

tail -100 unicorn.stderr.log

    I, [2020-07-16T07:51:49.785061 #72] INFO -- : le maître a terminé la réouverture des journaux

    I, [2020-07-16T07:52:05.423701 #18420] INFO -- : worker=3 a terminé la réouverture des journaux

    I, [2020-07-16T07:52:05.439574 #10177] INFO -- : worker=2 a terminé la réouverture des journaux

    I, [2020-07-16T07:52:06.614121 #11282] INFO -- : worker=1 a terminé la réouverture des journaux

    I, [2020-07-16T07:52:06.626403 #30350] INFO -- : worker=0 a terminé la réouverture des journaux

    E, [2020-07-16T13:43:49.118620 #72] ERROR -- : worker=1 PID:11282 a expiré (31s > 30s), mise à mort

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

    D, [2020-07-16T13:44:19.448200 #72] DEBUG -- : attente de 16,0 s après une mise en veille/hibernation

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

    E, [2020-07-16T14:24:40.454209 #72] ERROR -- : worker=1 PID:10639 a expiré (31s > 30s), mise à mort

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

    D, [2020-07-16T14:25:10.744135 #72] DEBUG -- : attente de 16,0 s après une mise en veille/hibernation

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

    E, [2020-07-16T16:03:01.918109 #72] ERROR -- : worker=2 PID:10177 a expiré (31s > 30s), mise à mort

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

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

    E, [2020-07-16T18:29:27.607372 #72] ERROR -- : worker=1 PID:13472 a expiré (31s > 30s), mise à mort

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

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

    E, [2020-07-16T18:51:56.470192 #72] ERROR -- : worker=0 PID:30350 a expiré (31s > 30s), mise à mort

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

    I, [2020-07-16T18:52:43.150079 #31968] INFO -- : worker=0 prêt
D, [2020-07-16T19:13:52.263197 #72] DEBUG -- : attente de 16,0 s après une mise en veille/hibernation

Pourriez-vous répondre au reste des questions de Jay ?

Est-ce sur un SSD ? 2 To suggère qu’il pourrait s’agir d’un disque SATA mécanique conventionnel, qui sera trop lent pour être utilisé avec Discourse.

Oui, un disque SATA de 2 To fonctionne normalement rapidement, mais il est actuellement hors ligne.

https://forum.wishl.net/

Le SSD est le minimum requis et est documenté dans les exigences de Discourse. Vous aurez besoin d’un SSD ; nous ne pouvons pas vous aider si vous utilisez un disque mécanique.

Peux-tu entrer dans le conteneur et suivre d’autres journaux ?

Mon pari est que PostgreSQL échoue au démarrage ; commence par examiner cela.

bonjour, quel fichier de journal devrais-je examiner ?

Si cela peut aider, le serveur Discourse que j’aide à administrer affiche des messages d’erreur 502 Bad Gateway depuis environ un mois. Le serveur et moi-même sommes situés en Allemagne. Il ne peut pas s’agir d’une régression récente de Discourse, car nous n’avons pas effectué de mise à niveau depuis des mois. Nous utilisons un contrat d’hébergement très basique. Le serveur est également devenu très lent lorsqu’il parvient à se connecter. Je n’ai pas d’explication satisfaisante pour cette dégradation du service, mais j’imaginais que cela était simplement dû à notre plan peu coûteux. En lisant ce fil de discussion, il pourrait peut-être y avoir d’autres explications ? R.

Merci pour la réponse.
Le serveur a transféré le SSD, le problème est résolu.

Bonjour ! Pouvez-vous me dire si l’utilisation de disques durs de type ‘life’ peut améliorer les performances ? Merci.

Le SSD est beaucoup plus rapide que les disques magnétiques rotatifs. Il est largement reconnu que le SSD est requis, bien que je sache qu’un site de taille moyenne a utilisé des disques magnétiques. Cela a entraîné au moins une modification du noyau pour le prendre en charge. La configuration a pris plusieurs semaines. Si vous utilisez des disques magnétiques, vous aurez besoin de plus de RAM pour fournir plus de cache. Ce n’est vraiment pas recommandé.