Sind also alle Behauptungen, dass der UNICORN WORKER 2*vCPU haben sollte, falsch?
Mein Server ist Intel Xeon E5-2686 v4 @ 2,30GHz—24 vCPU + 32 GB RAM
Wie viele UNICORN WORKER soll ich einrichten?
8? oder 48?
Meine Website hat mehr als 7.000 Benutzer und etwa 1.000 täglich aktive Benutzer. Benutzer senden 3.000-7.000 Beiträge pro Tag. Unsere Community hat 120.000-200.000 Seitenaufrufe pro Tag, einschließlich Crawlern und anonymen Benutzern.
Das hängt von vielen Faktoren ab. Wie groß ist Ihre Datenbank im Verhältnis zu Ihrem RAM, das Verhältnis von angemeldeten zu anonymen Zugriffen, ob Sie Plugins haben, die Ihre Sidekiq-Warteschlange stärker auslasten, ob Sie YJIT ausführen usw.
Einfach ist es, die MiniProfiler-Daten während Ihrer Spitzenstunde zu betrachten und das Forum zu durchsuchen, um zu sehen, ob die Leistung schlechter ist, und den Engpass zu identifizieren.
Da diese CPU älter ist, würde ich mit mehr als der üblichen Anzahl von Unicorn-Arbeitern beginnen, da jede Anfrage länger als üblich dauern wird. Wenn Sie jedoch PostgreSQL und Redis auf demselben Server ausführen, können Sie diese nicht durch zu viele Arbeiter verhungern lassen.
Versuchen Sie zunächst, 16 Arbeiter auszuführen und zu bewerten, wie die Website funktioniert.
Gibt es eine einfache, für Menschen verständliche Beschreibung dessen, was Unicorn-Worker tun? Mein Eindruck ist, dass jede Benutzerseitenanfrage an einen Unicorn-Worker gehen muss, um bearbeitet zu werden. Wenn Sie nicht genug haben, muss der Benutzer warten. Wenn Sie zu viele haben… nun, vielleicht kostet Sie das ein wenig RAM?
Sie sind die Webserver der Anwendung.
Es sieht so aus, als ob Ihre 10 Jahre alte CPU ihr Alter zeigt. Die Erhöhung der Unicorn-Worker ermöglicht es Ihnen, mehr Benutzer gleichzeitig zu bedienen, macht aber eine einzelne Anfrage nicht schneller.
Können Sie versuchen, YJIT zu aktivieren?
Mit Ihrer Hardware würde ich erwarten, dass Sie eine durchschnittliche Anmeldeliste/neueste Zeit von etwa 150 ms App, 80 ms SQL erhalten.
Ich würde mit 12 Arbeitern beginnen und sehen, wie es sich damit verhält. Das Beste, was Sie tun können, ist, Metriken zu verfolgen; Wenn Sie wissen möchten, ob Sie weitere Arbeiter hinzufügen sollen, prüfen Sie, ob Anfragen in der Warteschlange stehen und auf App-Arbeiter warten.
Verfolgen Sie die Metriken, die Discourse selbst über den Prometheus-Exporter exportiert? Diese geben Ihnen einen guten Überblick über die Gesamtleistung der Instanz.
Wie sind die Leistungswerte für anonyme und normale (nicht-admin) Benutzer?
Es gibt viele Mega-Themen in unserem Discourse, und das größte befindet sich bereits im zwölften Abschnitt.
Antwortansichten
(/hört auf zu lachen, loggt sich beim Hosting-Provider ein …)
Wow, ist das nicht mittlerweile Standard??
Bearbeiten: Ah, natürlich haben Sie vielleicht mit einer alten app.yml erstellt und seitdem nicht mehr aktualisiert
Es ist in unserem Hosting, aber es ist irgendwie schwer, es zum Standard zu machen, da Leute möglicherweise in RAM-beschränkten Szenarien laufen…
Das gesagt, unser JS-Build verbraucht so viel mehr RAM als Discourse selbst, dass man sagen könnte, jeder, der die JS-Assets bauen kann, hat viel RAM übrig ![]()
Wie viele Worker sind in diesen Bildern eingerichtet?
Ich würde sagen, Sie sollten
- Die Worker ein wenig erhöhen, da es zu leichten Warteschlangen kommt
- YJIT aktivieren, da Ihre Web-Zeit recht langsam ist
Es gibt jetzt nur noch 8 Worker und YJIT ist bereits aktiviert.
Wie viele Worker sollte ich erhöhen?
Übrigens, hier ist, was Falco sich angesehen hat, um diese Empfehlung auszusprechen:
Ich würde 8 → 12 erhöhen. Das gibt Ihnen etwas Spielraum und sollte diese Warteschlangen leeren.
Diese große Spitze, übrigens, deutet auf die anderen Anfragen hin, die auf… etwas warten, wahrscheinlich eine gemeinsame Sperre. Vielleicht ein Megathemen-Post.
Wenn Sie auch Metriken zur PostgreSQL-Nutzung erhalten können, wäre das nützlich.
Megathemen sind eine Schwachstelle, siehe Improving Instance Performance (Megatopics, Database Size and Extreme Load)
Erwägen Sie, diese aufzuteilen oder stattdessen Chat zu verwenden (ich sehe, dass Ihr größtes mit 8,9k Antworten explizit ein Chatraum ist).
Die Diskussionskultur unserer Community sind Megathemen, die bereits vor der Nutzung von Discourse entstanden sind, und Chat-Funktionen wie ausgeblendete Spoiler und versteckte Details fehlen.
Wie mache ich das?
Wir verwenden GitHub - prometheus-community/postgres_exporter: A PostgreSQL metric exporter for Prometheus, obwohl ich nicht sicher bin, ob es Anleitungen auf Meta gibt, wie man es einrichtet.
Aber da Sie anscheinend bereits Prometheus eingerichtet haben, scheinen Sie zu wissen, was Sie tun.
Jetzt ist der Server-RAM 16/32 GB, UNICORN_WORKERS: 12, db_shared_buffers: “4096MB”
Da noch RAM verfügbar ist und nur wenige Webanfragen in der Warteschlange stehen, habe ich die UNICORN_WORKERS auf 24 erhöht. Am Nachmittag stürzte der Server plötzlich ab und nach dem Neustart kamen sofort die Benutzer herein. Dies führte zu einer sehr geringen Anzahl aktiver Webanfragen und einer großen Anzahl von Anfragen in der Warteschlange. Vor ein paar Tagen haben wir festgestellt, dass 24 UNICORN_WORKERS über 150 aktive Webanfragen verarbeiten konnten, aber heute Nachmittag nur 30 aktive Webanfragen. Das liegt daran, dass wir gerade die Domain geändert haben und viele Beiträge von Sidekiq neu gebacken werden. Dies hat zu einer hohen Belastung des Servers geführt. Was sollen wir tun?










