diese Meldung erscheint seit meinem letzten Discourse-Update vor ein paar Tagen fast ständig.
Ich hätte kein Thema eröffnet, wenn… es nicht wahr wäre.
Die Meldung erscheint, aber man kann das Forum durchsuchen, als wäre man angemeldet, nichts wird wirklich so angezeigt, als wäre man es nicht.
Die Überprüfung der auf dem Host verwendeten/verfügbaren Ressourcen zeigt keine Überlastung der Maschine oder Ähnliches.
Kann mir jemand helfen zu verstehen, wie diese Meldung ausgelöst wird, damit ich untersuchen kann, was diese Warnung verursacht, obwohl dies nicht wirklich der Fall ist?
Diese Nachricht ist bedeutungsvoll. Die Tatsache, dass Ihr System über freie Ressourcen verfügt, deutet eher auf eine Fehlkonfiguration als auf eine Fehlidentifizierung hin.
Wie viele unicorn_workers haben Sie?
Angenommen, es gibt nichts anderes auf dem Host, haben Sie 16 zugewiesen (zwei pro Kern)?
Wenn Sie lokales Postgres verwenden, was sind Ihre db_shared_buffers?
Ich habe die Standardeinstellungen aus dem ./launcher-Ersteinrichtungsassistenten beibehalten, und das waren 8 Worker.
Dasselbe gilt für db_shared_buffers: 4096MB.
Aufgrund einiger Tests, deren Grund Sie hier nachlesen können, wurden die Worker auf 4 reduziert. Dies hatte keine Auswirkung, sodass ich sie zumindest wieder auf 8 zurücksetzen kann.
Der Grund, warum es nicht 2xCore ist, liegt darin, dass es sich um eine VM handelt und dies vCPUs und keine echten Kerne sind.
Ich werde die Instanz eine Weile beobachten und dann zurückkommen, um die Lösung zuzuweisen, falls dies der Fall ist. Danke, @Stephen.
Die Nachricht bezieht sich auf die Ressourcen, die Sie Discourse zuweisen, nicht auf die Ressourcen der VM/des Hosts.
Stellen Sie db_shared_buffers auf 25 % Ihres zugewiesenen Speichers und 2 Unicorn-Worker pro CPU ein. Möglicherweise sind einige Feinabstimmungen erforderlich.
Offensichtlich müssen Sie auch Ressourcen außerhalb der VM verwalten, wenn Sie das Gefühl haben, dass der Ressourcenpool nicht zuverlässig ist. Fast jeder, der Discourse betreibt, tut dies auf einer Art VPS.
Ich bin kein Experte für Discourse, daher habe ich einfach das Skript ausgeführt, das es installiert, da ich mich erinnere, dass es diese Parameter basierend auf dem verfügbaren Arbeitsspeicher/CPU einstellen sollte.
Ich habe die Worker wiederhergestellt, wie sie vor einigen Tests waren, und werde sie erneut überprüfen.
Ehrlich gesagt hatten wir mit diesen Einstellungen keine Probleme, aber es könnte auch nicht damit zusammenhängen oder nur teilweise damit zusammenhängen.
Ich werde Ihren Vorschlag von 2 Kernen für Worker und 25 % des reservierten Speichers für die DB-Shared-Buffer im Hinterkopf behalten.
Wenn Sie von reserviertem Speicher sprechen, meinen Sie den vom Container reservierten Speicher? Denn es scheint immer nur “so viel wie der Host verfügbar hat” zu sein
# db_shared_buffers: 128MB für 1GB, 256MB für 2GB oder 256MB * GB, max 4096MB
# UNICORN_WORKERS: 2 * GB für 2GB oder weniger, oder 2 * CPU, max 8
„Max“ kann man dort mit einer Prise Salz nehmen, insbesondere große Communities werden davon über diese Zahlen hinaus profitieren.
Ja, in Ihrem Fall hätte es die Maximalwerte von 8 Workern und 4096 MB angeben sollen. Wenn Sie die Worker und Shared Buffers, die für Discourse verfügbar sind, reduzieren, wird es erschöpft, bevor alle Ressourcen auf der VM verbraucht sind.
Dieser Beitrag von @mpalmer ist immer noch eine gute Anleitung:
[quote=“Crius, post:1, topic:268636, username:Crius”]
Diese Meldung erscheint seit meinem letzten Discourse-Update vor ein paar Tagen fast ständig.
…
Kann mir jemand helfen zu verstehen, wie diese Meldung ausgelöst wird?
[/quote]Es sieht für mich so aus, als ob sie ausgelöst wird, wenn Anfragen zu lange in der Warteschlange stehen – mit anderen Worten, wenn Anfragen schneller eingehen, als sie bearbeitet werden können. Man könnte sich fragen, warum so viele Anfragen oder warum eine so langsame Bearbeitung. Auf Discourse-Ebene gibt es Einstellungen, die in diesem Thread und auch z. B. in Extreme load error bereits diskutiert werden.
Seitdem schienen die Dinge in Ordnung zu sein, aber seit ein paar Tagen fühlt sich das Forum manchmal „langsam“ an. Wenn ich langsam sage, meine ich, dass Anfragen einige Zeit dauern, bis sie verarbeitet werden (Antworten senden, bearbeiten usw.), und gerade eben habe ich dieselbe Nachricht wieder bemerkt.
Ich habe mir das von mir eingerichtete Grafana-Dashboard angesehen und gesehen, dass der Server am Limit in Bezug auf die CPU-Auslastung ist.
Der Versuch, die App neu zu starten, hat nicht geholfen, die Auslastung steigt unmittelbar nach dem Neustart wieder auf den gleichen Wert an.
Gibt es eine Möglichkeit zu sehen, welcher Prozess die meisten Ressourcen verbraucht? Ich habe versucht, das Sidekiq-Dashboard zu überprüfen, aber es zeigt mir nur die Liste der laufenden/in der Warteschlange befindlichen Prozesse und die durchschnittliche Ausführungszeit an. Einige sind langsam (dauern Minuten), aber ich kann derzeit nichts Verarbeitendes oder Fehlerhaftes sehen.
Ich habe auch den VPS neu gestartet, nur für den Fall, dass etwas Seltsames vor sich ging (zweifelhaft, da es gestern nach 150 Tagen Betrieb plötzlich begann), aber nein, das gleiche Verhalten.
Es ist ein Einhorn-Prozess, der alle CPU-Ressourcen beansprucht. Gibt es eine Möglichkeit, mehr Informationen darüber zu erhalten, was diese Einhörner dort tun?
Für einen schnellen Blick oszilliert er natürlich, aber das ist der Durchschnitt für Unicorn-Mitarbeiter, der mir abnormal erscheint, wenn er seit dem Vortag läuft:
Ihre Load Average von > 8 auf einer 8-vCPU-Maschine bedeutet, dass Ihr Server überlastet ist.
Zwischen 8 Unicorns, vielen PostgreSQL-PIDs und allem anderen auf Ihrem Server kann er eingehende Anfragen nicht schnell genug verarbeiten. Zumindest haben Sie viel Speicher
Es ist ziemlich ungewöhnlich, dass Discourse auf diese Weise durch Unicorn-CPU-Engpässe behindert wird. Meistens, wenn ich das erlebt habe, lag es an einem fehlverhalten eines Plugins. Können Sie Ihre app.yml teilen?
Bitte teilen Sie auch die MiniProfiler-Ergebnisse des Ladens Ihrer Homepage und einer Topic-Seite.
Ich habe das Hosting gebeten zu untersuchen, ob uns von anderen VPS auf unserem Host CPU-Zeit gestohlen wird, da es wirklich seltsam ist, dass dies so plötzlich geschah, ohne dass sich auf unserer Seite wirklich etwas geändert hat.
Ich warte darauf, dass der technische Support mit Ergebnissen zurückkommt.
Es sieht so aus, als ob dieser Screenshot die Spaltenbeschriftungen abschneidet, aber wenn eine der ersten 3 ein Durchschnitt ist, hast du das Problem gelöst.
Entschuldigung, ich habe vergessen, hier zu aktualisieren.
Es war am Ende, wie ich vermutet hatte. Ein weiterer VPS wurde auf dem Host bereitgestellt und hat ihn ausgelastet.
Wir wurden weniger als 24 Stunden nach Eröffnung des Tickets auf einen anderen Host umgezogen.
Bravo an Contabo
Ich möchte die Moderatoren bitten, diese letzten Antworten hier stehen zu lassen, auch wenn sie nicht “diskursbezogen” sind, da sie anderen helfen können, andere Gründe zu finden, warum ihre Instanz Probleme haben könnte.
