ich habe einige Fragen zu dieser Option. Es ist klar, dass diese Option in app.yml standardmäßig auskommentiert ist und die Sortierleistung verbessern kann, aber den Speicherverbrauch pro Verbindung erhöht. Was bedeutet das jedoch genau? Hängt das von der Anzahl der Verbindungen ab? Was ist db_work_mem? Wird dieser Wert beim Installieren von Discourse automatisch festgelegt, genau wie db_shared_buffers und UNICORN_WORKERS? Ist die Aktivierung dieser Option sicher oder eher etwas für Fortgeschrittene?
Derzeit sieht es so aus: #db_work_mem: "40MB"
Der Server ist: Vultr High Frequency Compute 2 vCore, 4096 MB
Es ist ein komplexes Thema. Du kannst in der PostgreSQL-Dokumentation nach Details suchen. Hier gibt es einige Themen, die sich mit der Optimierung befassen:
Die Standardwerte funktionieren in der Regel gut.
Wenn du ein Problem hast, kannst du es beschreiben und angeben, wie viel Traffic du hast und wie groß deine Datenbank ist.
Danke, Jay! Eigentlich interessiere ich mich nur dafür. Ich suche nach Möglichkeiten, die Leistung des Forums zu verbessern, aber wenn es Probleme verursachen könnte, ist es vielleicht besser, es auskommentiert zu lassen.
Wenn ich es also aktiviere, besteht eine gute Chance, dass der Speicher erschöpft wird, wenn die Einstellungen nicht korrekt sind oder der Traffic steigt? Habe ich das richtig verstanden?
work_mem ( integer )
Legt die grundlegende maximale Speichermenge fest, die von einem Datenbankabfragevorgang (wie einer Sortierung oder einer Hash-Tabelle) verwendet werden kann, bevor auf temporäre Festplattendateien geschrieben wird. Wenn dieser Wert ohne Einheit angegeben wird, wird er als Kilobyte interpretiert. Der Standardwert beträgt vier Megabyte ( 4MB ). Beachten Sie, dass bei komplexen Abfragen mehrere Sortier- oder Hash-Vorgänge parallel ausgeführt werden können; jeder Vorgang darf im Allgemeinen so viel Speicher verwenden, wie dieser Wert angibt, bevor er beginnt, Daten in temporäre Dateien zu schreiben. Außerdem können mehrere laufende Sitzungen solche Vorgänge gleichzeitig durchführen. Daher kann der insgesamt verwendete Speicher ein Vielfaches des Wertes von work_mem betragen; dies muss bei der Auswahl des Wertes berücksichtigt werden. Sortiervorgänge werden für ORDER BY, DISTINCT und Merge-Joins verwendet. Hash-Tabellen werden bei Hash-Joins, hash-basierter Aggregation und hash-basierter Verarbeitung von IN-Unterabfragen eingesetzt.
Hash-basierte Vorgänge sind im Allgemeinen empfindlicher gegenüber der verfügbaren Speichermenge als gleichwertige sortierbasierte Vorgänge. Der für Hash-Tabellen verfügbare Speicher wird berechnet, indem work_mem mit hash_mem_multiplier multipliziert wird. Dies ermöglicht es hash-basierten Vorgängen, eine Speichermenge zu verwenden, die den üblichen Basiswert von work_mem überschreitet.
Es hilft manchmal, den Arbeitsspeicher auf das Doppelte des auskommentierten Standardwerts zu erhöhen. Ich denke, das hilft bei großen Websites mit umfangreichen Indizes, aber ich bin mir nicht ganz sicher. Ich habe bereits eine Website beschädigt, indem ich den Wert zu hoch angesetzt habe.
Wenn du mit der Optimierung experimentieren möchtest, kannst du das Prometheus-Plugin ausprobieren und mit Grafana hübsche Diagramme erstellen.
Ich habe hier die Formel gefunden, um db_work_mem zu berechnen.
Standardmäßig ist sie auf 100 Verbindungen ausgelegt.
Gesamter RAM * 0,25 / max_connections
Ich habe 4096 MB * 0,25 / 100 = ~10 MB.
In der Vorlage postgres.template.yml ist db_work_mem: "10 MB" standardmäßig gesetzt, was ich so interpretiere, dass sie mit dieser Formel berechnet wird. Ich denke, diese 10 MB sind derzeit das Maximum. Danke, Jay
