Ressourcennutzung/Arbeitsspeicher
autovacuum_work_mem
attribute | Wert |
---|---|
Kategorie | Ressourcennutzung/Arbeitsspeicher |
Beschreibung | Legt den maximalen Arbeitsspeicher zur Verwendung durch die einzelnen Autovacuum-Workerprozesse fest. |
Datentyp | integer |
Standardwert | -1 |
Zulässige Werte | -1-2097151 |
Parametertyp | dynamisch |
Dokumentation | autovacuum_work_mem |
dynamic_shared_memory_type
attribute | Wert |
---|---|
Kategorie | Ressourcennutzung/Arbeitsspeicher |
Beschreibung | Wählt die verwendete Implementierung des dynamischen freigegebenen Speichers aus. |
Datentyp | Enumeration |
Standardwert | posix |
Zulässige Werte | posix |
Parametertyp | schreibgeschützt |
Dokumentation | dynamic_shared_memory_type |
hash_mem_multiplier
attribute | Wert |
---|---|
Kategorie | Ressourcennutzung/Arbeitsspeicher |
Beschreibung | Mehrfaches von work_mem, das für Hashtabellen verwendet werden soll |
Datentyp | NUMERIC |
Standardwert | 2 |
Zulässige Werte | 1-1000 |
Parametertyp | dynamisch |
Dokumentation | hash_mem_multiplier |
huge_pages
attribute | Wert |
---|---|
Kategorie | Ressourcennutzung/Arbeitsspeicher |
Beschreibung | Aktiviert/deaktiviert die Verwendung großer Speicherseiten. Diese Einstellung gilt nicht für Server mit weniger als 4 virtuellen Kernen. |
Datentyp | Enumeration |
Standardwert | try |
Zulässige Werte | on,off,try |
Parametertyp | static |
Dokumentation | huge_pages |
Beschreibung
Große Seiten sind ein Feature, mit dem Arbeitsspeicher in größeren Blöcken verwaltet werden kann. Sie können in der Regel Blöcke von bis zu 2 MB verwalten, im Gegensatz zu den standardmäßigen 4-KB-Seiten.
Die Verwendung großer Seiten kann Leistungsvorteile bieten, welche die CPU effektiv auslagern:
- Sie reduzieren den Aufwand in Zusammenhang mit den Speicherverwaltungsaufgaben, z. B. weniger Translation Lookaside Buffer (TLB)-Fehler.
- Sie verkürzen die für die Speicherverwaltung benötigte Zeit.
Insbesondere können Sie in PostgreSQL große Seiten nur für den freigegebenen Speicherbereich verwenden. Ein erheblicher Teil des freigegebenen Speicherbereichs wird an freigegebene Puffer zugewiesen.
Ein weiterer Vorteil besteht darin, dass große Seiten den Austausch des freigegebenen Speicherbereichs auf den Datenträger verhindern und so die Leistung weiter stabilisieren.
Empfehlungen
- Vermeiden Sie für Server mit erheblichen Speicherressourcen das Deaktivieren großer Seiten. Das Deaktivieren großer Seiten kann die Leistung beeinträchtigen.
- Wenn Sie mit einem kleineren Server beginnen, der keine großen Seiten unterstützt, aber die Skalierung auf einen Server mit Unterstützung für große Seiten antizipieren, belassen Sie die Einstellung
huge_pages
aufTRY
, um einen nahtlosen Übergang und optimale Leistung zu gewährleisten.
Azure-spezifische Hinweise
Für Server mit vier oder mehr vCores werden große Seiten automatisch vom zugrunde liegenden Betriebssystem zugewiesen. Das Feature ist für Server mit weniger als vier vCores nicht verfügbar. Die Anzahl der großen Seiten wird automatisch angepasst, wenn Einstellungen für gemeinsam genutzten Speicher geändert werden, einschließlich Änderungen an shared_buffers
.
huge_page_size
attribute | Wert |
---|---|
Kategorie | Ressourcennutzung/Arbeitsspeicher |
Beschreibung | Die Größe einer riesigen Seite, die angefordert werden soll. |
Datentyp | integer |
Standardwert | 0 |
Zulässige Werte | 0 |
Parametertyp | schreibgeschützt |
Dokumentation | huge_page_size |
logical_decoding_work_mem
attribute | Wert |
---|---|
Kategorie | Ressourcennutzung/Arbeitsspeicher |
Beschreibung | Legt den maximalen Arbeitsspeicher fest, der für die logische Decodierung verwendet werden soll. |
Datentyp | integer |
Standardwert | 65536 |
Zulässige Werte | 65536 |
Parametertyp | schreibgeschützt |
Dokumentation | logical_decoding_work_mem |
maintenance_work_mem
attribute | Wert |
---|---|
Kategorie | Ressourcennutzung/Arbeitsspeicher |
Beschreibung | Legt den maximalen Arbeitsspeicher fest, der für Wartungsvorgänge wie VACUUM, „Create Index“ verwendet werden soll. |
Datentyp | integer |
Standardwert | Hängt von Ressourcen (virtuelle Kerne, RAM oder Speicherplatz) ab, die dem Server zugeordnet sind. |
Zulässige Werte | 1024-2097151 |
Parametertyp | dynamisch |
Dokumentation | maintenance_work_mem |
Beschreibung
maintenance_work_mem
ist ein Konfigurationsparameter in PostgreSQL. Er bestimmt die Menge an Arbeitsspeicher, der den Wartungsvorgängen zugeordnet ist, z. B. VACUUM
, CREATE INDEX
und ALTER TABLE
. Im Gegensatz zu work_mem
, was sich auf die Speicherzuweisung für Abfragevorgänge auswirkt, ist maintenance_work_mem
für Aufgaben reserviert, die die Datenbankstruktur verwalten und optimieren.
Wesentliche Punkte
- Begrenzung des Vakuumspeichers: Wenn Sie die Bereinigung von toten Tupeln beschleunigen möchten, indem Sie
maintenance_work_mem
erhöhen, beachten Sie, dass überVACUUM
eine integrierte Einschränkung für das Sammeln von toten Tupel-IDs verfügt. Es kann nur bis zu 1 GB Arbeitsspeicher für diesen Prozess verwenden. - Trennung des Arbeitsspeichers für Autovacuum: Sie können die Einstellung
autovacuum_work_mem
verwenden, um den für Autovacuum-Vorgänge verwendeten Arbeitsspeicher unabhängig zu nutzen. Diese Einstellung fungiert als Teilmenge vonmaintenance_work_mem
. Sie können entscheiden, wie viel Arbeitsspeicher Autovacuum verwendet, ohne die Speicherzuweisung für andere Wartungsaufgaben und Datendefinitionsvorgänge zu beeinflussen.
Azure-spezifische Hinweise
Der Standardwert für den Serverparameter maintenance_work_mem
wird berechnet, wenn Sie die Instanz von Azure Database for PostgreSQL – Flexible Server basierend auf dem Produktnamen bereitstellen, den Sie für die Berechnung auswählen. Alle nachfolgenden Änderungen der Produktauswahl an der Berechnung, die den flexiblen Server unterstützt, haben keine Auswirkungen auf den Standardwert für den Serverparameter maintenance_work_mem
dieser Instanz.
Bei jeder Änderung des Produkts, das einer Instanz zugewiesen ist, sollten Sie auch den Wert für den maintenance_work_mem
-Parameter entsprechend den Werten in der folgenden Formel anpassen.
Die Formel, die zum Berechnen des Werts verwendet maintenance_work_mem
wird, lautet (long)(82.5 * ln(memoryGiB) + 40) * 1024
.
Basierend auf der vorherigen Formel werden in der folgenden Tabelle die Werte aufgeführt, auf die dieser Serverparameter je nach bereitgestellter Arbeitsspeichermenge festgelegt wird:
Arbeitsspeichergröße | maintenance_work_mem |
---|---|
2 GiB | 99328 KiB |
4 GiB | 157696 KiB |
8 GiB | 216064 KiB |
16 GiB | 274432 KiB |
32GiB | 332800 KiB |
48 GiB | 367616 KiB |
64GiB | 392192 KiB |
80 GiB | 410624 KiB |
128 GB | 450560 KiB |
160 GiB | 468992 KiB |
192 GiB | 484352 KiB |
256 GiB | 508928 KiB |
384 GiB | 542720 KiB |
432 GiB | 552960 KiB |
672 GiB | 590848 KiB |
max_prepared_transactions
attribute | Wert |
---|---|
Kategorie | Ressourcennutzung/Arbeitsspeicher |
Beschreibung | Legt die maximale Anzahl gleichzeitig vorbereiteter Transaktionen fest. Wenn Sie einen Replikationsserver betreiben, müssen Sie diesen Parameter auf denselben oder einen höheren Wert als auf dem Primärserver festlegen. |
Datentyp | integer |
Standardwert | 0 |
Zulässige Werte | 0-262143 |
Parametertyp | static |
Dokumentation | max_prepared_transactions |
max_stack_depth
attribute | Wert |
---|---|
Kategorie | Ressourcennutzung/Arbeitsspeicher |
Beschreibung | Legt die maximale Stapeltiefe in Kilobyte fest. |
Datentyp | integer |
Standardwert | 2048 |
Zulässige Werte | 2048 |
Parametertyp | schreibgeschützt |
Dokumentation | max_stack_depth |
min_dynamic_shared_memory
attribute | Wert |
---|---|
Kategorie | Ressourcennutzung/Arbeitsspeicher |
Beschreibung | Die Menge des beim Start reservierten dynamischen freigegebenen Speichers. |
Datentyp | integer |
Standardwert | 0 |
Zulässige Werte | 0 |
Parametertyp | schreibgeschützt |
Dokumentation | min_dynamic_shared_memory |
shared_buffers
attribute | Wert |
---|---|
Kategorie | Ressourcennutzung/Arbeitsspeicher |
Beschreibung | Legt die Anzahl der vom Server verwendeten freigegebenen Speicherpuffer fest. Die Einheit ist 8 KB. Zulässige Werte liegen innerhalb des Bereich von 10 % bis 75 % des verfügbaren Arbeitsspeichers. |
Datentyp | integer |
Standardwert | Hängt von Ressourcen (virtuelle Kerne, RAM oder Speicherplatz) ab, die dem Server zugeordnet sind. |
Zulässige Werte | 16-1073741823 |
Parametertyp | static |
Dokumentation | shared_buffers |
Beschreibung
Der Konfigurationsparameter shared_buffers
bestimmt die Menge des Systemspeichers, der der PostgreSQL-Datenbank zur Pufferung von Daten zugeordnet ist. Er dient als zentraler Speicherpool, auf den alle Datenbankprozesse zugreifen können.
Wenn Daten benötigt werden, überprüft der Datenbankprozess zuerst den freigegebenen Puffer. Wenn die erforderlichen Daten vorhanden sind, werden sie schnell abgerufen, und ein zeitaufwändigerer Datenträgerlesevorgang wird umgangen. Freigegebene Puffer dienen als Vermittler zwischen den Datenbankprozessen und dem Datenträger und reduzieren effektiv die Anzahl der erforderlichen E/A-Vorgänge.
Azure-spezifische Hinweise
Der Standardwert für den Serverparameter shared_buffers
wird berechnet, wenn Sie die Instanz von Azure Database for PostgreSQL – Flexible Server basierend auf dem Produktnamen bereitstellen, den Sie für die Berechnung auswählen. Alle nachfolgenden Änderungen der Produktauswahl an der Berechnung, die den flexiblen Server unterstützt, haben keine Auswirkungen auf den Standardwert für den Serverparameter shared_buffers
dieser Instanz.
Bei jeder Änderung des Produkts, das einer Instanz zugewiesen ist, sollten Sie auch den Wert für den shared_buffers
-Parameter entsprechend den Werten in den folgenden Formeln anpassen.
Bei virtuellen Computern mit bis zu 2 GiB Arbeitsspeicher lautet die Formel, die zum Berechnen des Werts shared_buffers
verwendet wird: memoryGib * 16384
.
Bei virtuellen Computern mit mehr als 2 GiB lautet die Formel, die zum Berechnen des Werts shared_buffers
verwendet wird: memoryGib * 32768
.
Basierend auf der vorherigen Formel werden in der folgenden Tabelle die Werte aufgeführt, auf die dieser Serverparameter je nach bereitgestellter Arbeitsspeichermenge festgelegt wird:
Arbeitsspeichergröße | shared_buffers |
---|---|
2 GiB | 32768 |
4 GiB | 131072 |
8 GiB | 262144 |
16 GiB | 524288 |
32GiB | 1048576 |
48 GiB | 1572864 |
64GiB | 2097152 |
80 GiB | 2621440 |
128 GB | 4194304 |
160 GiB | 5242880 |
192 GiB | 6291456 |
256 GiB | 8388608 |
384 GiB | 12582912 |
432 GiB | 14155776 |
672 GiB | 22020096 |
shared_memory_type
attribute | Wert |
---|---|
Kategorie | Ressourcennutzung/Arbeitsspeicher |
Beschreibung | Wählt die für den Hauptspeicherbereich gemeinsam genutzte Speicherimplementierung aus. |
Datentyp | Enumeration |
Standardwert | mmap |
Zulässige Werte | mmap |
Parametertyp | schreibgeschützt |
Dokumentation | shared_memory_type |
temp_buffers
attribute | Wert |
---|---|
Kategorie | Ressourcennutzung/Arbeitsspeicher |
Beschreibung | Legt die maximale Anzahl von temporären Puffern fest, die von den einzelnen Datenbanksitzungen verwendet werden. |
Datentyp | integer |
Standardwert | 1024 |
Zulässige Werte | 100-1073741823 |
Parametertyp | dynamisch |
Dokumentation | temp_buffers |
vacuum_buffer_usage_limit
attribute | Wert |
---|---|
Kategorie | Ressourcennutzung/Arbeitsspeicher |
Beschreibung | Legt die Pufferpoolgröße für VACUUM, ANALYZE und autovacuum fest |
Datentyp | integer |
Standardwert | 2048 |
Zulässige Werte | 0-16777216 |
Parametertyp | dynamisch |
Dokumentation | vacuum_buffer_usage_limit |
work_mem
attribute | Wert |
---|---|
Kategorie | Ressourcennutzung/Arbeitsspeicher |
Beschreibung | Legt den Arbeitsspeicher fest, der von internen Sortiervorgängen und Hashtabellen vor dem Schreiben in temporäre Datenträgerdateien verwendet werden soll. |
Datentyp | integer |
Standardwert | 4096 |
Zulässige Werte | 4096-2097151 |
Parametertyp | dynamisch |
Dokumentation | work_mem |
Beschreibung
Der Parameter work_mem
in PostgreSQL steuert die Menge des Speichers, der bestimmten internen Vorgängen innerhalb des privaten Speicherbereichs jeder Datenbanksitzung zugeordnet ist. Beispiele für diese Vorgänge sind Sortieren und Hashing.
Im Gegensatz zu freigegebenen Puffern, die sich im freigegebenen Speicherbereich befinden, wird work_mem
in einem privaten Speicherbereich pro Sitzung oder pro Abfrage zugewiesen. Indem Sie eine angemessene work_mem
-Größe festlegen, können Sie die Effizienz dieser Vorgänge erheblich verbessern und die Notwendigkeit, temporäre Daten auf den Datenträger zu schreiben, verringern.
Wesentliche Punkte
- Privater Verbindungsspeicher:
work_mem
ist Teil des privaten Speichers, den jede Datenbanksitzung verwendet. Dieser Speicher unterscheidet sich von dem freigegebenen Speicherbereich, denshared_buffers
verwendet. - Abfragespezifische Verwendung: Nicht alle Sitzungen oder Abfragen verwenden
work_mem
. Für einfache Abfragen wieSELECT 1
istwork_mem
wahrscheinlich nicht erforderlich. Komplexere Abfragen mit Vorgängen wie Sortieren oder Hashing können jedoch einen oder mehrere Abschnitte vonwork_mem
nutzen. - Parallele Vorgänge: Bei Abfragen, die mehrere parallele Back-Ends umfassen, kann jedes Back-End potenziell einen oder mehrere Blöcke von
work_mem
verwenden.
Überwachen und Anpassen von work_mem
Es ist wichtig, die Leistung Ihres Systems kontinuierlich zu überwachen und work_mem
nach Bedarf anzupassen, in erster Linie, wenn langsame Abfrageausführungszeiten im Zusammenhang mit Sortier- oder Hashvorgängen langsam sind. Im Folgenden finden Sie Möglichkeiten zum Überwachen der Leistung mithilfe von Tools, die im Azure-Portal verfügbar sind:
- Einblick in die Abfrageleistung: Überprüfen Sie die wichtigsten Abfragen auf der Registerkarte temporärer Dateien, um Abfragen zu identifizieren, die temporäre Dateien generieren. Diese Situation deutet darauf hin, dass ein potenzieller Bedarf für die Erhöhung von
work_mem
vorhanden ist. - Anleitungen zur Problembehandlung: Verwenden Sie die Registerkarte Hohe Anzahl temporärer Dateien in den Anleitungen zur Problembehandlung, um problematische Abfragen zu identifizieren.
Granulare Anpassung
Beim Verwalten des work_mem
-Parameters ist es oft effizienter, Anpassungen granular vorzunehmen, anstatt einen globalen Wert festzulegen. Dieser Ansatz stellt sicher, dass Sie Speicher bewusst basierend auf den spezifischen Anforderungen von Prozessen und Benutzern zuordnen. Außerdem wird das Risiko minimiert, dass Probleme aufgrund ungenügendem Arbeitsspeicher auftreten. Gehen Sie hierzu wie folgt vor:
Benutzerebene: Wenn ein bestimmter Benutzer in erster Linie an Aggregations- oder Berichterstellungsaufgaben beteiligt ist, die arbeitsspeicherintensiv sind, sollten Sie den
work_mem
-Wert für diesen Benutzer anpassen. Verwenden Sie denALTER ROLE
-Befehl, um die Leistung der Benutzervorgänge zu verbessern.Funktions-/Prozedurebene: Wenn bestimmte Funktionen oder Prozeduren erhebliche Mengen temporärer Dateien generieren, kann die Erhöhung des
work_mem
-Wertes auf der Ebene der spezifischen Funktion oder Prozedur von Vorteil sein. Verwenden Sie den BefehlALTER FUNCTION
oderALTER PROCEDURE
, um diesen Vorgängen gezielt mehr Arbeitsspeicher zuzuweisen.Datenbankebene: Ändern Sie
work_mem
auf Datenbankebene nur, wenn bestimmte Datenbanken eine hohe Anzahl temporärer Dateien generieren.Globale Ebene: Wenn eine Analyse Ihres Systems zeigt, dass die meisten Abfragen kleine temporäre Dateien generieren, während nur wenige große Dateien erstellen, kann es sinnvoll sein, den
work_mem
-Wert global zu erhöhen. Diese Aktion erleichtert die meisten Abfragen zum Verarbeiten im Arbeitsspeicher, sodass Sie datenträgerbasierte Vorgänge vermeiden und die Effizienz verbessern können. Seien Sie jedoch immer vorsichtig und überwachen Sie die Speicherauslastung auf Ihrem Server, um sicherzustellen, dass der erhöhtework_mem
-Wert verarbeitet werden kann.
Bestimmen des minimalen work_mem-Werts für Sortiervorgänge
Um den Mindestwert von work_mem
für eine bestimmte Abfrage zu ermitteln, insbesondere wenn während des Sortiervorgangs temporäre Datenträgerdateien generiert werden, betrachten Sie zunächst die Größe der temporären Datei, die während der Abfrageausführung generiert wurde. Beispiel: Wenn eine Abfrage eine temporäre Datei mit 20 MB generiert:
- Stellen Sie mithilfe von psql oder Ihrem bevorzugten PostgreSQL-Client eine Verbindung mit Ihrer Datenbank her.
- Legen Sie einen anfänglichen
work_mem
-Wert etwas höher als 20 MB fest, um zusätzliche Header bei der Verarbeitung im Arbeitsspeicher zu berücksichtigen. Verwenden Sie z.B. folgenden Befehl:SET work_mem TO '25MB'
. - Führen Sie
EXPLAIN ANALYZE
für die problematische Abfrage in derselben Sitzung aus. - Überprüfen Sie die Ausgabe für
"Sort Method: quicksort Memory: xkB"
. Wenn es"external merge Disk: xkB"
angibt, heben Sie denwork_mem
-Wert inkrementell an, und testen Sie ihn erneut, bis"quicksort Memory"
angezeigt wird. Das Auftreten von"quicksort Memory"
-Signalen, dass die Abfrage jetzt im Arbeitsspeicher ausgeführt wird. - Nachdem Sie den Wert anhand dieser Methode ermittelt haben, können Sie ihn entweder global oder auf granulareren Ebenen (wie zuvor beschrieben) auf Ihre betrieblichen Anforderungen anwenden.
autovacuum_work_mem
attribute | Wert |
---|---|
Kategorie | Ressourcennutzung/Arbeitsspeicher |
Beschreibung | Legt den maximalen Arbeitsspeicher zur Verwendung durch die einzelnen Autovacuum-Workerprozesse fest. |
Datentyp | integer |
Standardwert | -1 |
Zulässige Werte | -1-2097151 |
Parametertyp | dynamisch |
Dokumentation | autovacuum_work_mem |
dynamic_shared_memory_type
attribute | Wert |
---|---|
Kategorie | Ressourcennutzung/Arbeitsspeicher |
Beschreibung | Wählt die verwendete Implementierung des dynamischen freigegebenen Speichers aus. |
Datentyp | Enumeration |
Standardwert | posix |
Zulässige Werte | posix |
Parametertyp | schreibgeschützt |
Dokumentation | dynamic_shared_memory_type |
hash_mem_multiplier
attribute | Wert |
---|---|
Kategorie | Ressourcennutzung/Arbeitsspeicher |
Beschreibung | Mehrfaches von work_mem, das für Hashtabellen verwendet werden soll |
Datentyp | NUMERIC |
Standardwert | 2 |
Zulässige Werte | 1-1000 |
Parametertyp | dynamisch |
Dokumentation | hash_mem_multiplier |
huge_pages
attribute | Wert |
---|---|
Kategorie | Ressourcennutzung/Arbeitsspeicher |
Beschreibung | Aktiviert/deaktiviert die Verwendung großer Speicherseiten. Diese Einstellung gilt nicht für Server mit weniger als 4 virtuellen Kernen. |
Datentyp | Enumeration |
Standardwert | try |
Zulässige Werte | on,off,try |
Parametertyp | static |
Dokumentation | huge_pages |
Beschreibung
Große Seiten sind ein Feature, mit dem Arbeitsspeicher in größeren Blöcken verwaltet werden kann. Sie können in der Regel Blöcke von bis zu 2 MB verwalten, im Gegensatz zu den standardmäßigen 4-KB-Seiten.
Die Verwendung großer Seiten kann Leistungsvorteile bieten, welche die CPU effektiv auslagern:
- Sie reduzieren den Aufwand in Zusammenhang mit den Speicherverwaltungsaufgaben, z. B. weniger Translation Lookaside Buffer (TLB)-Fehler.
- Sie verkürzen die für die Speicherverwaltung benötigte Zeit.
Insbesondere können Sie in PostgreSQL große Seiten nur für den freigegebenen Speicherbereich verwenden. Ein erheblicher Teil des freigegebenen Speicherbereichs wird an freigegebene Puffer zugewiesen.
Ein weiterer Vorteil besteht darin, dass große Seiten den Austausch des freigegebenen Speicherbereichs auf den Datenträger verhindern und so die Leistung weiter stabilisieren.
Empfehlungen
- Vermeiden Sie für Server mit erheblichen Speicherressourcen das Deaktivieren großer Seiten. Das Deaktivieren großer Seiten kann die Leistung beeinträchtigen.
- Wenn Sie mit einem kleineren Server beginnen, der keine großen Seiten unterstützt, aber die Skalierung auf einen Server mit Unterstützung für große Seiten antizipieren, belassen Sie die Einstellung
huge_pages
aufTRY
, um einen nahtlosen Übergang und optimale Leistung zu gewährleisten.
Azure-spezifische Hinweise
Für Server mit vier oder mehr vCores werden große Seiten automatisch vom zugrunde liegenden Betriebssystem zugewiesen. Das Feature ist für Server mit weniger als vier vCores nicht verfügbar. Die Anzahl der großen Seiten wird automatisch angepasst, wenn Einstellungen für gemeinsam genutzten Speicher geändert werden, einschließlich Änderungen an shared_buffers
.
huge_page_size
attribute | Wert |
---|---|
Kategorie | Ressourcennutzung/Arbeitsspeicher |
Beschreibung | Die Größe einer riesigen Seite, die angefordert werden soll. |
Datentyp | integer |
Standardwert | 0 |
Zulässige Werte | 0 |
Parametertyp | schreibgeschützt |
Dokumentation | huge_page_size |
logical_decoding_work_mem
attribute | Wert |
---|---|
Kategorie | Ressourcennutzung/Arbeitsspeicher |
Beschreibung | Legt den maximalen Arbeitsspeicher fest, der für die logische Decodierung verwendet werden soll. |
Datentyp | integer |
Standardwert | 65536 |
Zulässige Werte | 64-2147483647 |
Parametertyp | dynamisch |
Dokumentation | logical_decoding_work_mem |
maintenance_work_mem
attribute | Wert |
---|---|
Kategorie | Ressourcennutzung/Arbeitsspeicher |
Beschreibung | Legt den maximalen Arbeitsspeicher fest, der für Wartungsvorgänge wie VACUUM, „Create Index“ verwendet werden soll. |
Datentyp | integer |
Standardwert | Hängt von Ressourcen (virtuelle Kerne, RAM oder Speicherplatz) ab, die dem Server zugeordnet sind. |
Zulässige Werte | 1024-2097151 |
Parametertyp | dynamisch |
Dokumentation | maintenance_work_mem |
Beschreibung
maintenance_work_mem
ist ein Konfigurationsparameter in PostgreSQL. Er bestimmt die Menge an Arbeitsspeicher, der den Wartungsvorgängen zugeordnet ist, z. B. VACUUM
, CREATE INDEX
und ALTER TABLE
. Im Gegensatz zu work_mem
, was sich auf die Speicherzuweisung für Abfragevorgänge auswirkt, ist maintenance_work_mem
für Aufgaben reserviert, die die Datenbankstruktur verwalten und optimieren.
Wesentliche Punkte
- Begrenzung des Vakuumspeichers: Wenn Sie die Bereinigung von toten Tupeln beschleunigen möchten, indem Sie
maintenance_work_mem
erhöhen, beachten Sie, dass überVACUUM
eine integrierte Einschränkung für das Sammeln von toten Tupel-IDs verfügt. Es kann nur bis zu 1 GB Arbeitsspeicher für diesen Prozess verwenden. - Trennung des Arbeitsspeichers für Autovacuum: Sie können die Einstellung
autovacuum_work_mem
verwenden, um den für Autovacuum-Vorgänge verwendeten Arbeitsspeicher unabhängig zu nutzen. Diese Einstellung fungiert als Teilmenge vonmaintenance_work_mem
. Sie können entscheiden, wie viel Arbeitsspeicher Autovacuum verwendet, ohne die Speicherzuweisung für andere Wartungsaufgaben und Datendefinitionsvorgänge zu beeinflussen.
Azure-spezifische Hinweise
Der Standardwert für den Serverparameter maintenance_work_mem
wird berechnet, wenn Sie die Instanz von Azure Database for PostgreSQL – Flexible Server basierend auf dem Produktnamen bereitstellen, den Sie für die Berechnung auswählen. Alle nachfolgenden Änderungen der Produktauswahl an der Berechnung, die den flexiblen Server unterstützt, haben keine Auswirkungen auf den Standardwert für den Serverparameter maintenance_work_mem
dieser Instanz.
Bei jeder Änderung des Produkts, das einer Instanz zugewiesen ist, sollten Sie auch den Wert für den maintenance_work_mem
-Parameter entsprechend den Werten in der folgenden Formel anpassen.
Die Formel, die zum Berechnen des Werts verwendet maintenance_work_mem
wird, lautet (long)(82.5 * ln(memoryGiB) + 40) * 1024
.
Basierend auf der vorherigen Formel werden in der folgenden Tabelle die Werte aufgeführt, auf die dieser Serverparameter je nach bereitgestellter Arbeitsspeichermenge festgelegt wird:
Arbeitsspeichergröße | maintenance_work_mem |
---|---|
2 GiB | 99328 KiB |
4 GiB | 157696 KiB |
8 GiB | 216064 KiB |
16 GiB | 274432 KiB |
32GiB | 332800 KiB |
48 GiB | 367616 KiB |
64GiB | 392192 KiB |
80 GiB | 410624 KiB |
128 GB | 450560 KiB |
160 GiB | 468992 KiB |
192 GiB | 484352 KiB |
256 GiB | 508928 KiB |
384 GiB | 542720 KiB |
432 GiB | 552960 KiB |
672 GiB | 590848 KiB |
max_prepared_transactions
attribute | Wert |
---|---|
Kategorie | Ressourcennutzung/Arbeitsspeicher |
Beschreibung | Legt die maximale Anzahl gleichzeitig vorbereiteter Transaktionen fest. Wenn Sie einen Replikationsserver betreiben, müssen Sie diesen Parameter auf denselben oder einen höheren Wert als auf dem Primärserver festlegen. |
Datentyp | integer |
Standardwert | 0 |
Zulässige Werte | 0-262143 |
Parametertyp | static |
Dokumentation | max_prepared_transactions |
max_stack_depth
attribute | Wert |
---|---|
Kategorie | Ressourcennutzung/Arbeitsspeicher |
Beschreibung | Legt die maximale Stapeltiefe in Kilobyte fest. |
Datentyp | integer |
Standardwert | 2048 |
Zulässige Werte | 2048 |
Parametertyp | schreibgeschützt |
Dokumentation | max_stack_depth |
min_dynamic_shared_memory
attribute | Wert |
---|---|
Kategorie | Ressourcennutzung/Arbeitsspeicher |
Beschreibung | Die Menge des beim Start reservierten dynamischen freigegebenen Speichers. |
Datentyp | integer |
Standardwert | 0 |
Zulässige Werte | 0 |
Parametertyp | schreibgeschützt |
Dokumentation | min_dynamic_shared_memory |
shared_buffers
attribute | Wert |
---|---|
Kategorie | Ressourcennutzung/Arbeitsspeicher |
Beschreibung | Legt die Anzahl der vom Server verwendeten freigegebenen Speicherpuffer fest. Die Einheit ist 8 KB. Zulässige Werte liegen innerhalb des Bereich von 10 % bis 75 % des verfügbaren Arbeitsspeichers. |
Datentyp | integer |
Standardwert | Hängt von Ressourcen (virtuelle Kerne, RAM oder Speicherplatz) ab, die dem Server zugeordnet sind. |
Zulässige Werte | 16-1073741823 |
Parametertyp | static |
Dokumentation | shared_buffers |
Beschreibung
Der Konfigurationsparameter shared_buffers
bestimmt die Menge des Systemspeichers, der der PostgreSQL-Datenbank zur Pufferung von Daten zugeordnet ist. Er dient als zentraler Speicherpool, auf den alle Datenbankprozesse zugreifen können.
Wenn Daten benötigt werden, überprüft der Datenbankprozess zuerst den freigegebenen Puffer. Wenn die erforderlichen Daten vorhanden sind, werden sie schnell abgerufen, und ein zeitaufwändigerer Datenträgerlesevorgang wird umgangen. Freigegebene Puffer dienen als Vermittler zwischen den Datenbankprozessen und dem Datenträger und reduzieren effektiv die Anzahl der erforderlichen E/A-Vorgänge.
Azure-spezifische Hinweise
Der Standardwert für den Serverparameter shared_buffers
wird berechnet, wenn Sie die Instanz von Azure Database for PostgreSQL – Flexible Server basierend auf dem Produktnamen bereitstellen, den Sie für die Berechnung auswählen. Alle nachfolgenden Änderungen der Produktauswahl an der Berechnung, die den flexiblen Server unterstützt, haben keine Auswirkungen auf den Standardwert für den Serverparameter shared_buffers
dieser Instanz.
Bei jeder Änderung des Produkts, das einer Instanz zugewiesen ist, sollten Sie auch den Wert für den shared_buffers
-Parameter entsprechend den Werten in den folgenden Formeln anpassen.
Bei virtuellen Computern mit bis zu 2 GiB Arbeitsspeicher lautet die Formel, die zum Berechnen des Werts shared_buffers
verwendet wird: memoryGib * 16384
.
Bei virtuellen Computern mit mehr als 2 GiB lautet die Formel, die zum Berechnen des Werts shared_buffers
verwendet wird: memoryGib * 32768
.
Basierend auf der vorherigen Formel werden in der folgenden Tabelle die Werte aufgeführt, auf die dieser Serverparameter je nach bereitgestellter Arbeitsspeichermenge festgelegt wird:
Arbeitsspeichergröße | shared_buffers |
---|---|
2 GiB | 32768 |
4 GiB | 131072 |
8 GiB | 262144 |
16 GiB | 524288 |
32GiB | 1048576 |
48 GiB | 1572864 |
64GiB | 2097152 |
80 GiB | 2621440 |
128 GB | 4194304 |
160 GiB | 5242880 |
192 GiB | 6291456 |
256 GiB | 8388608 |
384 GiB | 12582912 |
432 GiB | 14155776 |
672 GiB | 22020096 |
shared_memory_type
attribute | Wert |
---|---|
Kategorie | Ressourcennutzung/Arbeitsspeicher |
Beschreibung | Wählt die für den Hauptspeicherbereich gemeinsam genutzte Speicherimplementierung aus. |
Datentyp | Enumeration |
Standardwert | mmap |
Zulässige Werte | mmap |
Parametertyp | schreibgeschützt |
Dokumentation | shared_memory_type |
temp_buffers
attribute | Wert |
---|---|
Kategorie | Ressourcennutzung/Arbeitsspeicher |
Beschreibung | Legt die maximale Anzahl von temporären Puffern fest, die von den einzelnen Datenbanksitzungen verwendet werden. |
Datentyp | integer |
Standardwert | 1024 |
Zulässige Werte | 100-1073741823 |
Parametertyp | dynamisch |
Dokumentation | temp_buffers |
vacuum_buffer_usage_limit
attribute | Wert |
---|---|
Kategorie | Ressourcennutzung/Arbeitsspeicher |
Beschreibung | Legt die Pufferpoolgröße für VACUUM, ANALYZE und autovacuum fest |
Datentyp | integer |
Standardwert | 256 |
Zulässige Werte | 0-16777216 |
Parametertyp | dynamisch |
Dokumentation | vacuum_buffer_usage_limit |
work_mem
attribute | Wert |
---|---|
Kategorie | Ressourcennutzung/Arbeitsspeicher |
Beschreibung | Legt den Arbeitsspeicher fest, der von internen Sortiervorgängen und Hashtabellen vor dem Schreiben in temporäre Datenträgerdateien verwendet werden soll. |
Datentyp | integer |
Standardwert | 4096 |
Zulässige Werte | 4096-2097151 |
Parametertyp | dynamisch |
Dokumentation | work_mem |
Beschreibung
Der Parameter work_mem
in PostgreSQL steuert die Menge des Speichers, der bestimmten internen Vorgängen innerhalb des privaten Speicherbereichs jeder Datenbanksitzung zugeordnet ist. Beispiele für diese Vorgänge sind Sortieren und Hashing.
Im Gegensatz zu freigegebenen Puffern, die sich im freigegebenen Speicherbereich befinden, wird work_mem
in einem privaten Speicherbereich pro Sitzung oder pro Abfrage zugewiesen. Indem Sie eine angemessene work_mem
-Größe festlegen, können Sie die Effizienz dieser Vorgänge erheblich verbessern und die Notwendigkeit, temporäre Daten auf den Datenträger zu schreiben, verringern.
Wesentliche Punkte
- Privater Verbindungsspeicher:
work_mem
ist Teil des privaten Speichers, den jede Datenbanksitzung verwendet. Dieser Speicher unterscheidet sich von dem freigegebenen Speicherbereich, denshared_buffers
verwendet. - Abfragespezifische Verwendung: Nicht alle Sitzungen oder Abfragen verwenden
work_mem
. Für einfache Abfragen wieSELECT 1
istwork_mem
wahrscheinlich nicht erforderlich. Komplexere Abfragen mit Vorgängen wie Sortieren oder Hashing können jedoch einen oder mehrere Abschnitte vonwork_mem
nutzen. - Parallele Vorgänge: Bei Abfragen, die mehrere parallele Back-Ends umfassen, kann jedes Back-End potenziell einen oder mehrere Blöcke von
work_mem
verwenden.
Überwachen und Anpassen von work_mem
Es ist wichtig, die Leistung Ihres Systems kontinuierlich zu überwachen und work_mem
nach Bedarf anzupassen, in erster Linie, wenn langsame Abfrageausführungszeiten im Zusammenhang mit Sortier- oder Hashvorgängen langsam sind. Im Folgenden finden Sie Möglichkeiten zum Überwachen der Leistung mithilfe von Tools, die im Azure-Portal verfügbar sind:
- Einblick in die Abfrageleistung: Überprüfen Sie die wichtigsten Abfragen auf der Registerkarte temporärer Dateien, um Abfragen zu identifizieren, die temporäre Dateien generieren. Diese Situation deutet darauf hin, dass ein potenzieller Bedarf für die Erhöhung von
work_mem
vorhanden ist. - Anleitungen zur Problembehandlung: Verwenden Sie die Registerkarte Hohe Anzahl temporärer Dateien in den Anleitungen zur Problembehandlung, um problematische Abfragen zu identifizieren.
Granulare Anpassung
Beim Verwalten des work_mem
-Parameters ist es oft effizienter, Anpassungen granular vorzunehmen, anstatt einen globalen Wert festzulegen. Dieser Ansatz stellt sicher, dass Sie Speicher bewusst basierend auf den spezifischen Anforderungen von Prozessen und Benutzern zuordnen. Außerdem wird das Risiko minimiert, dass Probleme aufgrund ungenügendem Arbeitsspeicher auftreten. Gehen Sie hierzu wie folgt vor:
Benutzerebene: Wenn ein bestimmter Benutzer in erster Linie an Aggregations- oder Berichterstellungsaufgaben beteiligt ist, die arbeitsspeicherintensiv sind, sollten Sie den
work_mem
-Wert für diesen Benutzer anpassen. Verwenden Sie denALTER ROLE
-Befehl, um die Leistung der Benutzervorgänge zu verbessern.Funktions-/Prozedurebene: Wenn bestimmte Funktionen oder Prozeduren erhebliche Mengen temporärer Dateien generieren, kann die Erhöhung des
work_mem
-Wertes auf der Ebene der spezifischen Funktion oder Prozedur von Vorteil sein. Verwenden Sie den BefehlALTER FUNCTION
oderALTER PROCEDURE
, um diesen Vorgängen gezielt mehr Arbeitsspeicher zuzuweisen.Datenbankebene: Ändern Sie
work_mem
auf Datenbankebene nur, wenn bestimmte Datenbanken eine hohe Anzahl temporärer Dateien generieren.Globale Ebene: Wenn eine Analyse Ihres Systems zeigt, dass die meisten Abfragen kleine temporäre Dateien generieren, während nur wenige große Dateien erstellen, kann es sinnvoll sein, den
work_mem
-Wert global zu erhöhen. Diese Aktion erleichtert die meisten Abfragen zum Verarbeiten im Arbeitsspeicher, sodass Sie datenträgerbasierte Vorgänge vermeiden und die Effizienz verbessern können. Seien Sie jedoch immer vorsichtig und überwachen Sie die Speicherauslastung auf Ihrem Server, um sicherzustellen, dass der erhöhtework_mem
-Wert verarbeitet werden kann.
Bestimmen des minimalen work_mem-Werts für Sortiervorgänge
Um den Mindestwert von work_mem
für eine bestimmte Abfrage zu ermitteln, insbesondere wenn während des Sortiervorgangs temporäre Datenträgerdateien generiert werden, betrachten Sie zunächst die Größe der temporären Datei, die während der Abfrageausführung generiert wurde. Beispiel: Wenn eine Abfrage eine temporäre Datei mit 20 MB generiert:
- Stellen Sie mithilfe von psql oder Ihrem bevorzugten PostgreSQL-Client eine Verbindung mit Ihrer Datenbank her.
- Legen Sie einen anfänglichen
work_mem
-Wert etwas höher als 20 MB fest, um zusätzliche Header bei der Verarbeitung im Arbeitsspeicher zu berücksichtigen. Verwenden Sie z.B. folgenden Befehl:SET work_mem TO '25MB'
. - Führen Sie
EXPLAIN ANALYZE
für die problematische Abfrage in derselben Sitzung aus. - Überprüfen Sie die Ausgabe für
"Sort Method: quicksort Memory: xkB"
. Wenn es"external merge Disk: xkB"
angibt, heben Sie denwork_mem
-Wert inkrementell an, und testen Sie ihn erneut, bis"quicksort Memory"
angezeigt wird. Das Auftreten von"quicksort Memory"
-Signalen, dass die Abfrage jetzt im Arbeitsspeicher ausgeführt wird. - Nachdem Sie den Wert anhand dieser Methode ermittelt haben, können Sie ihn entweder global oder auf granulareren Ebenen (wie zuvor beschrieben) auf Ihre betrieblichen Anforderungen anwenden.
autovacuum_work_mem
attribute | Wert |
---|---|
Kategorie | Ressourcennutzung/Arbeitsspeicher |
Beschreibung | Legt den maximalen Arbeitsspeicher zur Verwendung durch die einzelnen Autovacuum-Workerprozesse fest. |
Datentyp | integer |
Standardwert | -1 |
Zulässige Werte | -1-2097151 |
Parametertyp | dynamisch |
Dokumentation | autovacuum_work_mem |
dynamic_shared_memory_type
attribute | Wert |
---|---|
Kategorie | Ressourcennutzung/Arbeitsspeicher |
Beschreibung | Wählt die verwendete Implementierung des dynamischen freigegebenen Speichers aus. |
Datentyp | Enumeration |
Standardwert | posix |
Zulässige Werte | posix |
Parametertyp | schreibgeschützt |
Dokumentation | dynamic_shared_memory_type |
hash_mem_multiplier
attribute | Wert |
---|---|
Kategorie | Ressourcennutzung/Arbeitsspeicher |
Beschreibung | Mehrfaches von work_mem, das für Hashtabellen verwendet werden soll |
Datentyp | NUMERIC |
Standardwert | 2 |
Zulässige Werte | 1-1000 |
Parametertyp | dynamisch |
Dokumentation | hash_mem_multiplier |
huge_pages
attribute | Wert |
---|---|
Kategorie | Ressourcennutzung/Arbeitsspeicher |
Beschreibung | Aktiviert/deaktiviert die Verwendung großer Speicherseiten. Diese Einstellung gilt nicht für Server mit weniger als 4 virtuellen Kernen. |
Datentyp | Enumeration |
Standardwert | try |
Zulässige Werte | on,off,try |
Parametertyp | static |
Dokumentation | huge_pages |
Beschreibung
Große Seiten sind ein Feature, mit dem Arbeitsspeicher in größeren Blöcken verwaltet werden kann. Sie können in der Regel Blöcke von bis zu 2 MB verwalten, im Gegensatz zu den standardmäßigen 4-KB-Seiten.
Die Verwendung großer Seiten kann Leistungsvorteile bieten, welche die CPU effektiv auslagern:
- Sie reduzieren den Aufwand in Zusammenhang mit den Speicherverwaltungsaufgaben, z. B. weniger Translation Lookaside Buffer (TLB)-Fehler.
- Sie verkürzen die für die Speicherverwaltung benötigte Zeit.
Insbesondere können Sie in PostgreSQL große Seiten nur für den freigegebenen Speicherbereich verwenden. Ein erheblicher Teil des freigegebenen Speicherbereichs wird an freigegebene Puffer zugewiesen.
Ein weiterer Vorteil besteht darin, dass große Seiten den Austausch des freigegebenen Speicherbereichs auf den Datenträger verhindern und so die Leistung weiter stabilisieren.
Empfehlungen
- Vermeiden Sie für Server mit erheblichen Speicherressourcen das Deaktivieren großer Seiten. Das Deaktivieren großer Seiten kann die Leistung beeinträchtigen.
- Wenn Sie mit einem kleineren Server beginnen, der keine großen Seiten unterstützt, aber die Skalierung auf einen Server mit Unterstützung für große Seiten antizipieren, belassen Sie die Einstellung
huge_pages
aufTRY
, um einen nahtlosen Übergang und optimale Leistung zu gewährleisten.
Azure-spezifische Hinweise
Für Server mit vier oder mehr vCores werden große Seiten automatisch vom zugrunde liegenden Betriebssystem zugewiesen. Das Feature ist für Server mit weniger als vier vCores nicht verfügbar. Die Anzahl der großen Seiten wird automatisch angepasst, wenn Einstellungen für gemeinsam genutzten Speicher geändert werden, einschließlich Änderungen an shared_buffers
.
huge_page_size
attribute | Wert |
---|---|
Kategorie | Ressourcennutzung/Arbeitsspeicher |
Beschreibung | Die Größe einer riesigen Seite, die angefordert werden soll. |
Datentyp | integer |
Standardwert | 0 |
Zulässige Werte | 0 |
Parametertyp | schreibgeschützt |
Dokumentation | huge_page_size |
logical_decoding_work_mem
attribute | Wert |
---|---|
Kategorie | Ressourcennutzung/Arbeitsspeicher |
Beschreibung | Legt den maximalen Arbeitsspeicher fest, der für die logische Decodierung verwendet werden soll. |
Datentyp | integer |
Standardwert | 65536 |
Zulässige Werte | 64-2147483647 |
Parametertyp | dynamisch |
Dokumentation | logical_decoding_work_mem |
maintenance_work_mem
attribute | Wert |
---|---|
Kategorie | Ressourcennutzung/Arbeitsspeicher |
Beschreibung | Legt den maximalen Arbeitsspeicher fest, der für Wartungsvorgänge wie VACUUM, „Create Index“ verwendet werden soll. |
Datentyp | integer |
Standardwert | Hängt von Ressourcen (virtuelle Kerne, RAM oder Speicherplatz) ab, die dem Server zugeordnet sind. |
Zulässige Werte | 1024-2097151 |
Parametertyp | dynamisch |
Dokumentation | maintenance_work_mem |
Beschreibung
maintenance_work_mem
ist ein Konfigurationsparameter in PostgreSQL. Er bestimmt die Menge an Arbeitsspeicher, der den Wartungsvorgängen zugeordnet ist, z. B. VACUUM
, CREATE INDEX
und ALTER TABLE
. Im Gegensatz zu work_mem
, was sich auf die Speicherzuweisung für Abfragevorgänge auswirkt, ist maintenance_work_mem
für Aufgaben reserviert, die die Datenbankstruktur verwalten und optimieren.
Wesentliche Punkte
- Begrenzung des Vakuumspeichers: Wenn Sie die Bereinigung von toten Tupeln beschleunigen möchten, indem Sie
maintenance_work_mem
erhöhen, beachten Sie, dass überVACUUM
eine integrierte Einschränkung für das Sammeln von toten Tupel-IDs verfügt. Es kann nur bis zu 1 GB Arbeitsspeicher für diesen Prozess verwenden. - Trennung des Arbeitsspeichers für Autovacuum: Sie können die Einstellung
autovacuum_work_mem
verwenden, um den für Autovacuum-Vorgänge verwendeten Arbeitsspeicher unabhängig zu nutzen. Diese Einstellung fungiert als Teilmenge vonmaintenance_work_mem
. Sie können entscheiden, wie viel Arbeitsspeicher Autovacuum verwendet, ohne die Speicherzuweisung für andere Wartungsaufgaben und Datendefinitionsvorgänge zu beeinflussen.
Azure-spezifische Hinweise
Der Standardwert für den Serverparameter maintenance_work_mem
wird berechnet, wenn Sie die Instanz von Azure Database for PostgreSQL – Flexible Server basierend auf dem Produktnamen bereitstellen, den Sie für die Berechnung auswählen. Alle nachfolgenden Änderungen der Produktauswahl an der Berechnung, die den flexiblen Server unterstützt, haben keine Auswirkungen auf den Standardwert für den Serverparameter maintenance_work_mem
dieser Instanz.
Bei jeder Änderung des Produkts, das einer Instanz zugewiesen ist, sollten Sie auch den Wert für den maintenance_work_mem
-Parameter entsprechend den Werten in der folgenden Formel anpassen.
Die Formel, die zum Berechnen des Werts verwendet maintenance_work_mem
wird, lautet (long)(82.5 * ln(memoryGiB) + 40) * 1024
.
Basierend auf der vorherigen Formel werden in der folgenden Tabelle die Werte aufgeführt, auf die dieser Serverparameter je nach bereitgestellter Arbeitsspeichermenge festgelegt wird:
Arbeitsspeichergröße | maintenance_work_mem |
---|---|
2 GiB | 99328 KiB |
4 GiB | 157696 KiB |
8 GiB | 216064 KiB |
16 GiB | 274432 KiB |
32GiB | 332800 KiB |
48 GiB | 367616 KiB |
64GiB | 392192 KiB |
80 GiB | 410624 KiB |
128 GB | 450560 KiB |
160 GiB | 468992 KiB |
192 GiB | 484352 KiB |
256 GiB | 508928 KiB |
384 GiB | 542720 KiB |
432 GiB | 552960 KiB |
672 GiB | 590848 KiB |
max_prepared_transactions
attribute | Wert |
---|---|
Kategorie | Ressourcennutzung/Arbeitsspeicher |
Beschreibung | Legt die maximale Anzahl gleichzeitig vorbereiteter Transaktionen fest. Wenn Sie einen Replikationsserver betreiben, müssen Sie diesen Parameter auf denselben oder einen höheren Wert als auf dem Primärserver festlegen. |
Datentyp | integer |
Standardwert | 0 |
Zulässige Werte | 0-262143 |
Parametertyp | static |
Dokumentation | max_prepared_transactions |
max_stack_depth
attribute | Wert |
---|---|
Kategorie | Ressourcennutzung/Arbeitsspeicher |
Beschreibung | Legt die maximale Stapeltiefe in Kilobyte fest. |
Datentyp | integer |
Standardwert | 2048 |
Zulässige Werte | 2048 |
Parametertyp | schreibgeschützt |
Dokumentation | max_stack_depth |
min_dynamic_shared_memory
attribute | Wert |
---|---|
Kategorie | Ressourcennutzung/Arbeitsspeicher |
Beschreibung | Die Menge des beim Start reservierten dynamischen freigegebenen Speichers. |
Datentyp | integer |
Standardwert | 0 |
Zulässige Werte | 0 |
Parametertyp | schreibgeschützt |
Dokumentation | min_dynamic_shared_memory |
shared_buffers
attribute | Wert |
---|---|
Kategorie | Ressourcennutzung/Arbeitsspeicher |
Beschreibung | Legt die Anzahl der vom Server verwendeten freigegebenen Speicherpuffer fest. Die Einheit ist 8 KB. Zulässige Werte liegen innerhalb des Bereich von 10 % bis 75 % des verfügbaren Arbeitsspeichers. |
Datentyp | integer |
Standardwert | Hängt von Ressourcen (virtuelle Kerne, RAM oder Speicherplatz) ab, die dem Server zugeordnet sind. |
Zulässige Werte | 16-1073741823 |
Parametertyp | static |
Dokumentation | shared_buffers |
Beschreibung
Der Konfigurationsparameter shared_buffers
bestimmt die Menge des Systemspeichers, der der PostgreSQL-Datenbank zur Pufferung von Daten zugeordnet ist. Er dient als zentraler Speicherpool, auf den alle Datenbankprozesse zugreifen können.
Wenn Daten benötigt werden, überprüft der Datenbankprozess zuerst den freigegebenen Puffer. Wenn die erforderlichen Daten vorhanden sind, werden sie schnell abgerufen, und ein zeitaufwändigerer Datenträgerlesevorgang wird umgangen. Freigegebene Puffer dienen als Vermittler zwischen den Datenbankprozessen und dem Datenträger und reduzieren effektiv die Anzahl der erforderlichen E/A-Vorgänge.
Azure-spezifische Hinweise
Der Standardwert für den Serverparameter shared_buffers
wird berechnet, wenn Sie die Instanz von Azure Database for PostgreSQL – Flexible Server basierend auf dem Produktnamen bereitstellen, den Sie für die Berechnung auswählen. Alle nachfolgenden Änderungen der Produktauswahl an der Berechnung, die den flexiblen Server unterstützt, haben keine Auswirkungen auf den Standardwert für den Serverparameter shared_buffers
dieser Instanz.
Bei jeder Änderung des Produkts, das einer Instanz zugewiesen ist, sollten Sie auch den Wert für den shared_buffers
-Parameter entsprechend den Werten in den folgenden Formeln anpassen.
Bei virtuellen Computern mit bis zu 2 GiB Arbeitsspeicher lautet die Formel, die zum Berechnen des Werts shared_buffers
verwendet wird: memoryGib * 16384
.
Bei virtuellen Computern mit mehr als 2 GiB lautet die Formel, die zum Berechnen des Werts shared_buffers
verwendet wird: memoryGib * 32768
.
Basierend auf der vorherigen Formel werden in der folgenden Tabelle die Werte aufgeführt, auf die dieser Serverparameter je nach bereitgestellter Arbeitsspeichermenge festgelegt wird:
Arbeitsspeichergröße | shared_buffers |
---|---|
2 GiB | 32768 |
4 GiB | 131072 |
8 GiB | 262144 |
16 GiB | 524288 |
32GiB | 1048576 |
48 GiB | 1572864 |
64GiB | 2097152 |
80 GiB | 2621440 |
128 GB | 4194304 |
160 GiB | 5242880 |
192 GiB | 6291456 |
256 GiB | 8388608 |
384 GiB | 12582912 |
432 GiB | 14155776 |
672 GiB | 22020096 |
shared_memory_type
attribute | Wert |
---|---|
Kategorie | Ressourcennutzung/Arbeitsspeicher |
Beschreibung | Wählt die für den Hauptspeicherbereich gemeinsam genutzte Speicherimplementierung aus. |
Datentyp | Enumeration |
Standardwert | mmap |
Zulässige Werte | mmap |
Parametertyp | schreibgeschützt |
Dokumentation | shared_memory_type |
temp_buffers
attribute | Wert |
---|---|
Kategorie | Ressourcennutzung/Arbeitsspeicher |
Beschreibung | Legt die maximale Anzahl von temporären Puffern fest, die von den einzelnen Datenbanksitzungen verwendet werden. |
Datentyp | integer |
Standardwert | 1024 |
Zulässige Werte | 100-1073741823 |
Parametertyp | dynamisch |
Dokumentation | temp_buffers |
work_mem
attribute | Wert |
---|---|
Kategorie | Ressourcennutzung/Arbeitsspeicher |
Beschreibung | Legt den Arbeitsspeicher fest, der von internen Sortiervorgängen und Hashtabellen vor dem Schreiben in temporäre Datenträgerdateien verwendet werden soll. |
Datentyp | integer |
Standardwert | 4096 |
Zulässige Werte | 4096-2097151 |
Parametertyp | dynamisch |
Dokumentation | work_mem |
Beschreibung
Der Parameter work_mem
in PostgreSQL steuert die Menge des Speichers, der bestimmten internen Vorgängen innerhalb des privaten Speicherbereichs jeder Datenbanksitzung zugeordnet ist. Beispiele für diese Vorgänge sind Sortieren und Hashing.
Im Gegensatz zu freigegebenen Puffern, die sich im freigegebenen Speicherbereich befinden, wird work_mem
in einem privaten Speicherbereich pro Sitzung oder pro Abfrage zugewiesen. Indem Sie eine angemessene work_mem
-Größe festlegen, können Sie die Effizienz dieser Vorgänge erheblich verbessern und die Notwendigkeit, temporäre Daten auf den Datenträger zu schreiben, verringern.
Wesentliche Punkte
- Privater Verbindungsspeicher:
work_mem
ist Teil des privaten Speichers, den jede Datenbanksitzung verwendet. Dieser Speicher unterscheidet sich von dem freigegebenen Speicherbereich, denshared_buffers
verwendet. - Abfragespezifische Verwendung: Nicht alle Sitzungen oder Abfragen verwenden
work_mem
. Für einfache Abfragen wieSELECT 1
istwork_mem
wahrscheinlich nicht erforderlich. Komplexere Abfragen mit Vorgängen wie Sortieren oder Hashing können jedoch einen oder mehrere Abschnitte vonwork_mem
nutzen. - Parallele Vorgänge: Bei Abfragen, die mehrere parallele Back-Ends umfassen, kann jedes Back-End potenziell einen oder mehrere Blöcke von
work_mem
verwenden.
Überwachen und Anpassen von work_mem
Es ist wichtig, die Leistung Ihres Systems kontinuierlich zu überwachen und work_mem
nach Bedarf anzupassen, in erster Linie, wenn langsame Abfrageausführungszeiten im Zusammenhang mit Sortier- oder Hashvorgängen langsam sind. Im Folgenden finden Sie Möglichkeiten zum Überwachen der Leistung mithilfe von Tools, die im Azure-Portal verfügbar sind:
- Einblick in die Abfrageleistung: Überprüfen Sie die wichtigsten Abfragen auf der Registerkarte temporärer Dateien, um Abfragen zu identifizieren, die temporäre Dateien generieren. Diese Situation deutet darauf hin, dass ein potenzieller Bedarf für die Erhöhung von
work_mem
vorhanden ist. - Anleitungen zur Problembehandlung: Verwenden Sie die Registerkarte Hohe Anzahl temporärer Dateien in den Anleitungen zur Problembehandlung, um problematische Abfragen zu identifizieren.
Granulare Anpassung
Beim Verwalten des work_mem
-Parameters ist es oft effizienter, Anpassungen granular vorzunehmen, anstatt einen globalen Wert festzulegen. Dieser Ansatz stellt sicher, dass Sie Speicher bewusst basierend auf den spezifischen Anforderungen von Prozessen und Benutzern zuordnen. Außerdem wird das Risiko minimiert, dass Probleme aufgrund ungenügendem Arbeitsspeicher auftreten. Gehen Sie hierzu wie folgt vor:
Benutzerebene: Wenn ein bestimmter Benutzer in erster Linie an Aggregations- oder Berichterstellungsaufgaben beteiligt ist, die arbeitsspeicherintensiv sind, sollten Sie den
work_mem
-Wert für diesen Benutzer anpassen. Verwenden Sie denALTER ROLE
-Befehl, um die Leistung der Benutzervorgänge zu verbessern.Funktions-/Prozedurebene: Wenn bestimmte Funktionen oder Prozeduren erhebliche Mengen temporärer Dateien generieren, kann die Erhöhung des
work_mem
-Wertes auf der Ebene der spezifischen Funktion oder Prozedur von Vorteil sein. Verwenden Sie den BefehlALTER FUNCTION
oderALTER PROCEDURE
, um diesen Vorgängen gezielt mehr Arbeitsspeicher zuzuweisen.Datenbankebene: Ändern Sie
work_mem
auf Datenbankebene nur, wenn bestimmte Datenbanken eine hohe Anzahl temporärer Dateien generieren.Globale Ebene: Wenn eine Analyse Ihres Systems zeigt, dass die meisten Abfragen kleine temporäre Dateien generieren, während nur wenige große Dateien erstellen, kann es sinnvoll sein, den
work_mem
-Wert global zu erhöhen. Diese Aktion erleichtert die meisten Abfragen zum Verarbeiten im Arbeitsspeicher, sodass Sie datenträgerbasierte Vorgänge vermeiden und die Effizienz verbessern können. Seien Sie jedoch immer vorsichtig und überwachen Sie die Speicherauslastung auf Ihrem Server, um sicherzustellen, dass der erhöhtework_mem
-Wert verarbeitet werden kann.
Bestimmen des minimalen work_mem-Werts für Sortiervorgänge
Um den Mindestwert von work_mem
für eine bestimmte Abfrage zu ermitteln, insbesondere wenn während des Sortiervorgangs temporäre Datenträgerdateien generiert werden, betrachten Sie zunächst die Größe der temporären Datei, die während der Abfrageausführung generiert wurde. Beispiel: Wenn eine Abfrage eine temporäre Datei mit 20 MB generiert:
- Stellen Sie mithilfe von psql oder Ihrem bevorzugten PostgreSQL-Client eine Verbindung mit Ihrer Datenbank her.
- Legen Sie einen anfänglichen
work_mem
-Wert etwas höher als 20 MB fest, um zusätzliche Header bei der Verarbeitung im Arbeitsspeicher zu berücksichtigen. Verwenden Sie z.B. folgenden Befehl:SET work_mem TO '25MB'
. - Führen Sie
EXPLAIN ANALYZE
für die problematische Abfrage in derselben Sitzung aus. - Überprüfen Sie die Ausgabe für
"Sort Method: quicksort Memory: xkB"
. Wenn es"external merge Disk: xkB"
angibt, heben Sie denwork_mem
-Wert inkrementell an, und testen Sie ihn erneut, bis"quicksort Memory"
angezeigt wird. Das Auftreten von"quicksort Memory"
-Signalen, dass die Abfrage jetzt im Arbeitsspeicher ausgeführt wird. - Nachdem Sie den Wert anhand dieser Methode ermittelt haben, können Sie ihn entweder global oder auf granulareren Ebenen (wie zuvor beschrieben) auf Ihre betrieblichen Anforderungen anwenden.
autovacuum_work_mem
attribute | Wert |
---|---|
Kategorie | Ressourcennutzung/Arbeitsspeicher |
Beschreibung | Legt den maximalen Arbeitsspeicher zur Verwendung durch die einzelnen Autovacuum-Workerprozesse fest. |
Datentyp | integer |
Standardwert | -1 |
Zulässige Werte | -1-2097151 |
Parametertyp | dynamisch |
Dokumentation | autovacuum_work_mem |
dynamic_shared_memory_type
attribute | Wert |
---|---|
Kategorie | Ressourcennutzung/Arbeitsspeicher |
Beschreibung | Wählt die verwendete Implementierung des dynamischen freigegebenen Speichers aus. |
Datentyp | Enumeration |
Standardwert | posix |
Zulässige Werte | posix |
Parametertyp | schreibgeschützt |
Dokumentation | dynamic_shared_memory_type |
hash_mem_multiplier
attribute | Wert |
---|---|
Kategorie | Ressourcennutzung/Arbeitsspeicher |
Beschreibung | Mehrfaches von work_mem, das für Hashtabellen verwendet werden soll |
Datentyp | NUMERIC |
Standardwert | 1 |
Zulässige Werte | 1-1000 |
Parametertyp | dynamisch |
Dokumentation | hash_mem_multiplier |
huge_pages
attribute | Wert |
---|---|
Kategorie | Ressourcennutzung/Arbeitsspeicher |
Beschreibung | Aktiviert/deaktiviert die Verwendung großer Speicherseiten. Diese Einstellung gilt nicht für Server mit weniger als 4 virtuellen Kernen. |
Datentyp | Enumeration |
Standardwert | try |
Zulässige Werte | on,off,try |
Parametertyp | static |
Dokumentation | huge_pages |
Beschreibung
Große Seiten sind ein Feature, mit dem Arbeitsspeicher in größeren Blöcken verwaltet werden kann. Sie können in der Regel Blöcke von bis zu 2 MB verwalten, im Gegensatz zu den standardmäßigen 4-KB-Seiten.
Die Verwendung großer Seiten kann Leistungsvorteile bieten, welche die CPU effektiv auslagern:
- Sie reduzieren den Aufwand in Zusammenhang mit den Speicherverwaltungsaufgaben, z. B. weniger Translation Lookaside Buffer (TLB)-Fehler.
- Sie verkürzen die für die Speicherverwaltung benötigte Zeit.
Insbesondere können Sie in PostgreSQL große Seiten nur für den freigegebenen Speicherbereich verwenden. Ein erheblicher Teil des freigegebenen Speicherbereichs wird an freigegebene Puffer zugewiesen.
Ein weiterer Vorteil besteht darin, dass große Seiten den Austausch des freigegebenen Speicherbereichs auf den Datenträger verhindern und so die Leistung weiter stabilisieren.
Empfehlungen
- Vermeiden Sie für Server mit erheblichen Speicherressourcen das Deaktivieren großer Seiten. Das Deaktivieren großer Seiten kann die Leistung beeinträchtigen.
- Wenn Sie mit einem kleineren Server beginnen, der keine großen Seiten unterstützt, aber die Skalierung auf einen Server mit Unterstützung für große Seiten antizipieren, belassen Sie die Einstellung
huge_pages
aufTRY
, um einen nahtlosen Übergang und optimale Leistung zu gewährleisten.
Azure-spezifische Hinweise
Für Server mit vier oder mehr vCores werden große Seiten automatisch vom zugrunde liegenden Betriebssystem zugewiesen. Das Feature ist für Server mit weniger als vier vCores nicht verfügbar. Die Anzahl der großen Seiten wird automatisch angepasst, wenn Einstellungen für gemeinsam genutzten Speicher geändert werden, einschließlich Änderungen an shared_buffers
.
huge_page_size
attribute | Wert |
---|---|
Kategorie | Ressourcennutzung/Arbeitsspeicher |
Beschreibung | Die Größe einer riesigen Seite, die angefordert werden soll. |
Datentyp | integer |
Standardwert | 0 |
Zulässige Werte | 0 |
Parametertyp | schreibgeschützt |
Dokumentation | huge_page_size |
logical_decoding_work_mem
attribute | Wert |
---|---|
Kategorie | Ressourcennutzung/Arbeitsspeicher |
Beschreibung | Legt den maximalen Arbeitsspeicher fest, der für die logische Decodierung verwendet werden soll. |
Datentyp | integer |
Standardwert | 65536 |
Zulässige Werte | 64-2147483647 |
Parametertyp | dynamisch |
Dokumentation | logical_decoding_work_mem |
maintenance_work_mem
attribute | Wert |
---|---|
Kategorie | Ressourcennutzung/Arbeitsspeicher |
Beschreibung | Legt den maximalen Arbeitsspeicher fest, der für Wartungsvorgänge wie VACUUM, „Create Index“ verwendet werden soll. |
Datentyp | integer |
Standardwert | Hängt von Ressourcen (virtuelle Kerne, RAM oder Speicherplatz) ab, die dem Server zugeordnet sind. |
Zulässige Werte | 1024-2097151 |
Parametertyp | dynamisch |
Dokumentation | maintenance_work_mem |
Beschreibung
maintenance_work_mem
ist ein Konfigurationsparameter in PostgreSQL. Er bestimmt die Menge an Arbeitsspeicher, der den Wartungsvorgängen zugeordnet ist, z. B. VACUUM
, CREATE INDEX
und ALTER TABLE
. Im Gegensatz zu work_mem
, was sich auf die Speicherzuweisung für Abfragevorgänge auswirkt, ist maintenance_work_mem
für Aufgaben reserviert, die die Datenbankstruktur verwalten und optimieren.
Wesentliche Punkte
- Begrenzung des Vakuumspeichers: Wenn Sie die Bereinigung von toten Tupeln beschleunigen möchten, indem Sie
maintenance_work_mem
erhöhen, beachten Sie, dass überVACUUM
eine integrierte Einschränkung für das Sammeln von toten Tupel-IDs verfügt. Es kann nur bis zu 1 GB Arbeitsspeicher für diesen Prozess verwenden. - Trennung des Arbeitsspeichers für Autovacuum: Sie können die Einstellung
autovacuum_work_mem
verwenden, um den für Autovacuum-Vorgänge verwendeten Arbeitsspeicher unabhängig zu nutzen. Diese Einstellung fungiert als Teilmenge vonmaintenance_work_mem
. Sie können entscheiden, wie viel Arbeitsspeicher Autovacuum verwendet, ohne die Speicherzuweisung für andere Wartungsaufgaben und Datendefinitionsvorgänge zu beeinflussen.
Azure-spezifische Hinweise
Der Standardwert für den Serverparameter maintenance_work_mem
wird berechnet, wenn Sie die Instanz von Azure Database for PostgreSQL – Flexible Server basierend auf dem Produktnamen bereitstellen, den Sie für die Berechnung auswählen. Alle nachfolgenden Änderungen der Produktauswahl an der Berechnung, die den flexiblen Server unterstützt, haben keine Auswirkungen auf den Standardwert für den Serverparameter maintenance_work_mem
dieser Instanz.
Bei jeder Änderung des Produkts, das einer Instanz zugewiesen ist, sollten Sie auch den Wert für den maintenance_work_mem
-Parameter entsprechend den Werten in der folgenden Formel anpassen.
Die Formel, die zum Berechnen des Werts verwendet maintenance_work_mem
wird, lautet (long)(82.5 * ln(memoryGiB) + 40) * 1024
.
Basierend auf der vorherigen Formel werden in der folgenden Tabelle die Werte aufgeführt, auf die dieser Serverparameter je nach bereitgestellter Arbeitsspeichermenge festgelegt wird:
Arbeitsspeichergröße | maintenance_work_mem |
---|---|
2 GiB | 99328 KiB |
4 GiB | 157696 KiB |
8 GiB | 216064 KiB |
16 GiB | 274432 KiB |
32GiB | 332800 KiB |
48 GiB | 367616 KiB |
64GiB | 392192 KiB |
80 GiB | 410624 KiB |
128 GB | 450560 KiB |
160 GiB | 468992 KiB |
192 GiB | 484352 KiB |
256 GiB | 508928 KiB |
384 GiB | 542720 KiB |
432 GiB | 552960 KiB |
672 GiB | 590848 KiB |
max_prepared_transactions
attribute | Wert |
---|---|
Kategorie | Ressourcennutzung/Arbeitsspeicher |
Beschreibung | Legt die maximale Anzahl gleichzeitig vorbereiteter Transaktionen fest. Wenn Sie einen Replikationsserver betreiben, müssen Sie diesen Parameter auf denselben oder einen höheren Wert als auf dem Primärserver festlegen. |
Datentyp | integer |
Standardwert | 0 |
Zulässige Werte | 0-262143 |
Parametertyp | static |
Dokumentation | max_prepared_transactions |
max_stack_depth
attribute | Wert |
---|---|
Kategorie | Ressourcennutzung/Arbeitsspeicher |
Beschreibung | Legt die maximale Stapeltiefe in Kilobyte fest. |
Datentyp | integer |
Standardwert | 2048 |
Zulässige Werte | 2048 |
Parametertyp | schreibgeschützt |
Dokumentation | max_stack_depth |
min_dynamic_shared_memory
attribute | Wert |
---|---|
Kategorie | Ressourcennutzung/Arbeitsspeicher |
Beschreibung | Die Menge des beim Start reservierten dynamischen freigegebenen Speichers. |
Datentyp | integer |
Standardwert | 0 |
Zulässige Werte | 0 |
Parametertyp | schreibgeschützt |
Dokumentation | min_dynamic_shared_memory |
shared_buffers
attribute | Wert |
---|---|
Kategorie | Ressourcennutzung/Arbeitsspeicher |
Beschreibung | Legt die Anzahl der vom Server verwendeten freigegebenen Speicherpuffer fest. Die Einheit ist 8 KB. Zulässige Werte liegen innerhalb des Bereich von 10 % bis 75 % des verfügbaren Arbeitsspeichers. |
Datentyp | integer |
Standardwert | Hängt von Ressourcen (virtuelle Kerne, RAM oder Speicherplatz) ab, die dem Server zugeordnet sind. |
Zulässige Werte | 16-1073741823 |
Parametertyp | static |
Dokumentation | shared_buffers |
Beschreibung
Der Konfigurationsparameter shared_buffers
bestimmt die Menge des Systemspeichers, der der PostgreSQL-Datenbank zur Pufferung von Daten zugeordnet ist. Er dient als zentraler Speicherpool, auf den alle Datenbankprozesse zugreifen können.
Wenn Daten benötigt werden, überprüft der Datenbankprozess zuerst den freigegebenen Puffer. Wenn die erforderlichen Daten vorhanden sind, werden sie schnell abgerufen, und ein zeitaufwändigerer Datenträgerlesevorgang wird umgangen. Freigegebene Puffer dienen als Vermittler zwischen den Datenbankprozessen und dem Datenträger und reduzieren effektiv die Anzahl der erforderlichen E/A-Vorgänge.
Azure-spezifische Hinweise
Der Standardwert für den Serverparameter shared_buffers
wird berechnet, wenn Sie die Instanz von Azure Database for PostgreSQL – Flexible Server basierend auf dem Produktnamen bereitstellen, den Sie für die Berechnung auswählen. Alle nachfolgenden Änderungen der Produktauswahl an der Berechnung, die den flexiblen Server unterstützt, haben keine Auswirkungen auf den Standardwert für den Serverparameter shared_buffers
dieser Instanz.
Bei jeder Änderung des Produkts, das einer Instanz zugewiesen ist, sollten Sie auch den Wert für den shared_buffers
-Parameter entsprechend den Werten in den folgenden Formeln anpassen.
Bei virtuellen Computern mit bis zu 2 GiB Arbeitsspeicher lautet die Formel, die zum Berechnen des Werts shared_buffers
verwendet wird: memoryGib * 16384
.
Bei virtuellen Computern mit mehr als 2 GiB lautet die Formel, die zum Berechnen des Werts shared_buffers
verwendet wird: memoryGib * 32768
.
Basierend auf der vorherigen Formel werden in der folgenden Tabelle die Werte aufgeführt, auf die dieser Serverparameter je nach bereitgestellter Arbeitsspeichermenge festgelegt wird:
Arbeitsspeichergröße | shared_buffers |
---|---|
2 GiB | 32768 |
4 GiB | 131072 |
8 GiB | 262144 |
16 GiB | 524288 |
32GiB | 1048576 |
48 GiB | 1572864 |
64GiB | 2097152 |
80 GiB | 2621440 |
128 GB | 4194304 |
160 GiB | 5242880 |
192 GiB | 6291456 |
256 GiB | 8388608 |
384 GiB | 12582912 |
432 GiB | 14155776 |
672 GiB | 22020096 |
shared_memory_type
attribute | Wert |
---|---|
Kategorie | Ressourcennutzung/Arbeitsspeicher |
Beschreibung | Wählt die für den Hauptspeicherbereich gemeinsam genutzte Speicherimplementierung aus. |
Datentyp | Enumeration |
Standardwert | mmap |
Zulässige Werte | mmap |
Parametertyp | schreibgeschützt |
Dokumentation | shared_memory_type |
temp_buffers
attribute | Wert |
---|---|
Kategorie | Ressourcennutzung/Arbeitsspeicher |
Beschreibung | Legt die maximale Anzahl von temporären Puffern fest, die von den einzelnen Datenbanksitzungen verwendet werden. |
Datentyp | integer |
Standardwert | 1024 |
Zulässige Werte | 100-1073741823 |
Parametertyp | dynamisch |
Dokumentation | temp_buffers |
work_mem
attribute | Wert |
---|---|
Kategorie | Ressourcennutzung/Arbeitsspeicher |
Beschreibung | Legt den Arbeitsspeicher fest, der von internen Sortiervorgängen und Hashtabellen vor dem Schreiben in temporäre Datenträgerdateien verwendet werden soll. |
Datentyp | integer |
Standardwert | 4096 |
Zulässige Werte | 4096-2097151 |
Parametertyp | dynamisch |
Dokumentation | work_mem |
Beschreibung
Der Parameter work_mem
in PostgreSQL steuert die Menge des Speichers, der bestimmten internen Vorgängen innerhalb des privaten Speicherbereichs jeder Datenbanksitzung zugeordnet ist. Beispiele für diese Vorgänge sind Sortieren und Hashing.
Im Gegensatz zu freigegebenen Puffern, die sich im freigegebenen Speicherbereich befinden, wird work_mem
in einem privaten Speicherbereich pro Sitzung oder pro Abfrage zugewiesen. Indem Sie eine angemessene work_mem
-Größe festlegen, können Sie die Effizienz dieser Vorgänge erheblich verbessern und die Notwendigkeit, temporäre Daten auf den Datenträger zu schreiben, verringern.
Wesentliche Punkte
- Privater Verbindungsspeicher:
work_mem
ist Teil des privaten Speichers, den jede Datenbanksitzung verwendet. Dieser Speicher unterscheidet sich von dem freigegebenen Speicherbereich, denshared_buffers
verwendet. - Abfragespezifische Verwendung: Nicht alle Sitzungen oder Abfragen verwenden
work_mem
. Für einfache Abfragen wieSELECT 1
istwork_mem
wahrscheinlich nicht erforderlich. Komplexere Abfragen mit Vorgängen wie Sortieren oder Hashing können jedoch einen oder mehrere Abschnitte vonwork_mem
nutzen. - Parallele Vorgänge: Bei Abfragen, die mehrere parallele Back-Ends umfassen, kann jedes Back-End potenziell einen oder mehrere Blöcke von
work_mem
verwenden.
Überwachen und Anpassen von work_mem
Es ist wichtig, die Leistung Ihres Systems kontinuierlich zu überwachen und work_mem
nach Bedarf anzupassen, in erster Linie, wenn langsame Abfrageausführungszeiten im Zusammenhang mit Sortier- oder Hashvorgängen langsam sind. Im Folgenden finden Sie Möglichkeiten zum Überwachen der Leistung mithilfe von Tools, die im Azure-Portal verfügbar sind:
- Einblick in die Abfrageleistung: Überprüfen Sie die wichtigsten Abfragen auf der Registerkarte temporärer Dateien, um Abfragen zu identifizieren, die temporäre Dateien generieren. Diese Situation deutet darauf hin, dass ein potenzieller Bedarf für die Erhöhung von
work_mem
vorhanden ist. - Anleitungen zur Problembehandlung: Verwenden Sie die Registerkarte Hohe Anzahl temporärer Dateien in den Anleitungen zur Problembehandlung, um problematische Abfragen zu identifizieren.
Granulare Anpassung
Beim Verwalten des work_mem
-Parameters ist es oft effizienter, Anpassungen granular vorzunehmen, anstatt einen globalen Wert festzulegen. Dieser Ansatz stellt sicher, dass Sie Speicher bewusst basierend auf den spezifischen Anforderungen von Prozessen und Benutzern zuordnen. Außerdem wird das Risiko minimiert, dass Probleme aufgrund ungenügendem Arbeitsspeicher auftreten. Gehen Sie hierzu wie folgt vor:
Benutzerebene: Wenn ein bestimmter Benutzer in erster Linie an Aggregations- oder Berichterstellungsaufgaben beteiligt ist, die arbeitsspeicherintensiv sind, sollten Sie den
work_mem
-Wert für diesen Benutzer anpassen. Verwenden Sie denALTER ROLE
-Befehl, um die Leistung der Benutzervorgänge zu verbessern.Funktions-/Prozedurebene: Wenn bestimmte Funktionen oder Prozeduren erhebliche Mengen temporärer Dateien generieren, kann die Erhöhung des
work_mem
-Wertes auf der Ebene der spezifischen Funktion oder Prozedur von Vorteil sein. Verwenden Sie den BefehlALTER FUNCTION
oderALTER PROCEDURE
, um diesen Vorgängen gezielt mehr Arbeitsspeicher zuzuweisen.Datenbankebene: Ändern Sie
work_mem
auf Datenbankebene nur, wenn bestimmte Datenbanken eine hohe Anzahl temporärer Dateien generieren.Globale Ebene: Wenn eine Analyse Ihres Systems zeigt, dass die meisten Abfragen kleine temporäre Dateien generieren, während nur wenige große Dateien erstellen, kann es sinnvoll sein, den
work_mem
-Wert global zu erhöhen. Diese Aktion erleichtert die meisten Abfragen zum Verarbeiten im Arbeitsspeicher, sodass Sie datenträgerbasierte Vorgänge vermeiden und die Effizienz verbessern können. Seien Sie jedoch immer vorsichtig und überwachen Sie die Speicherauslastung auf Ihrem Server, um sicherzustellen, dass der erhöhtework_mem
-Wert verarbeitet werden kann.
Bestimmen des minimalen work_mem-Werts für Sortiervorgänge
Um den Mindestwert von work_mem
für eine bestimmte Abfrage zu ermitteln, insbesondere wenn während des Sortiervorgangs temporäre Datenträgerdateien generiert werden, betrachten Sie zunächst die Größe der temporären Datei, die während der Abfrageausführung generiert wurde. Beispiel: Wenn eine Abfrage eine temporäre Datei mit 20 MB generiert:
- Stellen Sie mithilfe von psql oder Ihrem bevorzugten PostgreSQL-Client eine Verbindung mit Ihrer Datenbank her.
- Legen Sie einen anfänglichen
work_mem
-Wert etwas höher als 20 MB fest, um zusätzliche Header bei der Verarbeitung im Arbeitsspeicher zu berücksichtigen. Verwenden Sie z.B. folgenden Befehl:SET work_mem TO '25MB'
. - Führen Sie
EXPLAIN ANALYZE
für die problematische Abfrage in derselben Sitzung aus. - Überprüfen Sie die Ausgabe für
"Sort Method: quicksort Memory: xkB"
. Wenn es"external merge Disk: xkB"
angibt, heben Sie denwork_mem
-Wert inkrementell an, und testen Sie ihn erneut, bis"quicksort Memory"
angezeigt wird. Das Auftreten von"quicksort Memory"
-Signalen, dass die Abfrage jetzt im Arbeitsspeicher ausgeführt wird. - Nachdem Sie den Wert anhand dieser Methode ermittelt haben, können Sie ihn entweder global oder auf granulareren Ebenen (wie zuvor beschrieben) auf Ihre betrieblichen Anforderungen anwenden.
autovacuum_work_mem
attribute | Wert |
---|---|
Kategorie | Ressourcennutzung/Arbeitsspeicher |
Beschreibung | Legt den maximalen Arbeitsspeicher zur Verwendung durch die einzelnen Autovacuum-Workerprozesse fest. |
Datentyp | integer |
Standardwert | -1 |
Zulässige Werte | -1-2097151 |
Parametertyp | dynamisch |
Dokumentation | autovacuum_work_mem |
dynamic_shared_memory_type
attribute | Wert |
---|---|
Kategorie | Ressourcennutzung/Arbeitsspeicher |
Beschreibung | Wählt die verwendete Implementierung des dynamischen freigegebenen Speichers aus. |
Datentyp | Enumeration |
Standardwert | posix |
Zulässige Werte | posix |
Parametertyp | schreibgeschützt |
Dokumentation | dynamic_shared_memory_type |
hash_mem_multiplier
attribute | Wert |
---|---|
Kategorie | Ressourcennutzung/Arbeitsspeicher |
Beschreibung | Mehrfaches von work_mem, das für Hashtabellen verwendet werden soll |
Datentyp | NUMERIC |
Standardwert | 1 |
Zulässige Werte | 1-1000 |
Parametertyp | dynamisch |
Dokumentation | hash_mem_multiplier |
huge_pages
attribute | Wert |
---|---|
Kategorie | Ressourcennutzung/Arbeitsspeicher |
Beschreibung | Aktiviert/deaktiviert die Verwendung großer Speicherseiten. Diese Einstellung gilt nicht für Server mit weniger als 4 virtuellen Kernen. |
Datentyp | Enumeration |
Standardwert | try |
Zulässige Werte | on,off,try |
Parametertyp | static |
Dokumentation | huge_pages |
Beschreibung
Große Seiten sind ein Feature, mit dem Arbeitsspeicher in größeren Blöcken verwaltet werden kann. Sie können in der Regel Blöcke von bis zu 2 MB verwalten, im Gegensatz zu den standardmäßigen 4-KB-Seiten.
Die Verwendung großer Seiten kann Leistungsvorteile bieten, welche die CPU effektiv auslagern:
- Sie reduzieren den Aufwand in Zusammenhang mit den Speicherverwaltungsaufgaben, z. B. weniger Translation Lookaside Buffer (TLB)-Fehler.
- Sie verkürzen die für die Speicherverwaltung benötigte Zeit.
Insbesondere können Sie in PostgreSQL große Seiten nur für den freigegebenen Speicherbereich verwenden. Ein erheblicher Teil des freigegebenen Speicherbereichs wird an freigegebene Puffer zugewiesen.
Ein weiterer Vorteil besteht darin, dass große Seiten den Austausch des freigegebenen Speicherbereichs auf den Datenträger verhindern und so die Leistung weiter stabilisieren.
Empfehlungen
- Vermeiden Sie für Server mit erheblichen Speicherressourcen das Deaktivieren großer Seiten. Das Deaktivieren großer Seiten kann die Leistung beeinträchtigen.
- Wenn Sie mit einem kleineren Server beginnen, der keine großen Seiten unterstützt, aber die Skalierung auf einen Server mit Unterstützung für große Seiten antizipieren, belassen Sie die Einstellung
huge_pages
aufTRY
, um einen nahtlosen Übergang und optimale Leistung zu gewährleisten.
Azure-spezifische Hinweise
Für Server mit vier oder mehr vCores werden große Seiten automatisch vom zugrunde liegenden Betriebssystem zugewiesen. Das Feature ist für Server mit weniger als vier vCores nicht verfügbar. Die Anzahl der großen Seiten wird automatisch angepasst, wenn Einstellungen für gemeinsam genutzten Speicher geändert werden, einschließlich Änderungen an shared_buffers
.
logical_decoding_work_mem
attribute | Wert |
---|---|
Kategorie | Ressourcennutzung/Arbeitsspeicher |
Beschreibung | Legt den maximalen Arbeitsspeicher fest, der für die logische Decodierung verwendet werden soll. |
Datentyp | integer |
Standardwert | 65536 |
Zulässige Werte | 64-2147483647 |
Parametertyp | dynamisch |
Dokumentation | logical_decoding_work_mem |
maintenance_work_mem
attribute | Wert |
---|---|
Kategorie | Ressourcennutzung/Arbeitsspeicher |
Beschreibung | Legt den maximalen Arbeitsspeicher fest, der für Wartungsvorgänge wie VACUUM, „Create Index“ verwendet werden soll. |
Datentyp | integer |
Standardwert | Hängt von Ressourcen (virtuelle Kerne, RAM oder Speicherplatz) ab, die dem Server zugeordnet sind. |
Zulässige Werte | 1024-2097151 |
Parametertyp | dynamisch |
Dokumentation | maintenance_work_mem |
Beschreibung
maintenance_work_mem
ist ein Konfigurationsparameter in PostgreSQL. Er bestimmt die Menge an Arbeitsspeicher, der den Wartungsvorgängen zugeordnet ist, z. B. VACUUM
, CREATE INDEX
und ALTER TABLE
. Im Gegensatz zu work_mem
, was sich auf die Speicherzuweisung für Abfragevorgänge auswirkt, ist maintenance_work_mem
für Aufgaben reserviert, die die Datenbankstruktur verwalten und optimieren.
Wesentliche Punkte
- Begrenzung des Vakuumspeichers: Wenn Sie die Bereinigung von toten Tupeln beschleunigen möchten, indem Sie
maintenance_work_mem
erhöhen, beachten Sie, dass überVACUUM
eine integrierte Einschränkung für das Sammeln von toten Tupel-IDs verfügt. Es kann nur bis zu 1 GB Arbeitsspeicher für diesen Prozess verwenden. - Trennung des Arbeitsspeichers für Autovacuum: Sie können die Einstellung
autovacuum_work_mem
verwenden, um den für Autovacuum-Vorgänge verwendeten Arbeitsspeicher unabhängig zu nutzen. Diese Einstellung fungiert als Teilmenge vonmaintenance_work_mem
. Sie können entscheiden, wie viel Arbeitsspeicher Autovacuum verwendet, ohne die Speicherzuweisung für andere Wartungsaufgaben und Datendefinitionsvorgänge zu beeinflussen.
Azure-spezifische Hinweise
Der Standardwert für den Serverparameter maintenance_work_mem
wird berechnet, wenn Sie die Instanz von Azure Database for PostgreSQL – Flexible Server basierend auf dem Produktnamen bereitstellen, den Sie für die Berechnung auswählen. Alle nachfolgenden Änderungen der Produktauswahl an der Berechnung, die den flexiblen Server unterstützt, haben keine Auswirkungen auf den Standardwert für den Serverparameter maintenance_work_mem
dieser Instanz.
Bei jeder Änderung des Produkts, das einer Instanz zugewiesen ist, sollten Sie auch den Wert für den maintenance_work_mem
-Parameter entsprechend den Werten in der folgenden Formel anpassen.
Die Formel, die zum Berechnen des Werts verwendet maintenance_work_mem
wird, lautet (long)(82.5 * ln(memoryGiB) + 40) * 1024
.
Basierend auf der vorherigen Formel werden in der folgenden Tabelle die Werte aufgeführt, auf die dieser Serverparameter je nach bereitgestellter Arbeitsspeichermenge festgelegt wird:
Arbeitsspeichergröße | maintenance_work_mem |
---|---|
2 GiB | 99328 KiB |
4 GiB | 157696 KiB |
8 GiB | 216064 KiB |
16 GiB | 274432 KiB |
32GiB | 332800 KiB |
48 GiB | 367616 KiB |
64GiB | 392192 KiB |
80 GiB | 410624 KiB |
128 GB | 450560 KiB |
160 GiB | 468992 KiB |
192 GiB | 484352 KiB |
256 GiB | 508928 KiB |
384 GiB | 542720 KiB |
432 GiB | 552960 KiB |
672 GiB | 590848 KiB |
max_prepared_transactions
attribute | Wert |
---|---|
Kategorie | Ressourcennutzung/Arbeitsspeicher |
Beschreibung | Legt die maximale Anzahl gleichzeitig vorbereiteter Transaktionen fest. Wenn Sie einen Replikationsserver betreiben, müssen Sie diesen Parameter auf denselben oder einen höheren Wert als auf dem Primärserver festlegen. |
Datentyp | integer |
Standardwert | 0 |
Zulässige Werte | 0-262143 |
Parametertyp | static |
Dokumentation | max_prepared_transactions |
max_stack_depth
attribute | Wert |
---|---|
Kategorie | Ressourcennutzung/Arbeitsspeicher |
Beschreibung | Legt die maximale Stapeltiefe in Kilobyte fest. |
Datentyp | integer |
Standardwert | 2048 |
Zulässige Werte | 2048 |
Parametertyp | schreibgeschützt |
Dokumentation | max_stack_depth |
shared_buffers
attribute | Wert |
---|---|
Kategorie | Ressourcennutzung/Arbeitsspeicher |
Beschreibung | Legt die Anzahl der vom Server verwendeten freigegebenen Speicherpuffer fest. Die Einheit ist 8 KB. Zulässige Werte liegen innerhalb des Bereich von 10 % bis 75 % des verfügbaren Arbeitsspeichers. |
Datentyp | integer |
Standardwert | Hängt von Ressourcen (virtuelle Kerne, RAM oder Speicherplatz) ab, die dem Server zugeordnet sind. |
Zulässige Werte | 16-1073741823 |
Parametertyp | static |
Dokumentation | shared_buffers |
Beschreibung
Der Konfigurationsparameter shared_buffers
bestimmt die Menge des Systemspeichers, der der PostgreSQL-Datenbank zur Pufferung von Daten zugeordnet ist. Er dient als zentraler Speicherpool, auf den alle Datenbankprozesse zugreifen können.
Wenn Daten benötigt werden, überprüft der Datenbankprozess zuerst den freigegebenen Puffer. Wenn die erforderlichen Daten vorhanden sind, werden sie schnell abgerufen, und ein zeitaufwändigerer Datenträgerlesevorgang wird umgangen. Freigegebene Puffer dienen als Vermittler zwischen den Datenbankprozessen und dem Datenträger und reduzieren effektiv die Anzahl der erforderlichen E/A-Vorgänge.
Azure-spezifische Hinweise
Der Standardwert für den Serverparameter shared_buffers
wird berechnet, wenn Sie die Instanz von Azure Database for PostgreSQL – Flexible Server basierend auf dem Produktnamen bereitstellen, den Sie für die Berechnung auswählen. Alle nachfolgenden Änderungen der Produktauswahl an der Berechnung, die den flexiblen Server unterstützt, haben keine Auswirkungen auf den Standardwert für den Serverparameter shared_buffers
dieser Instanz.
Bei jeder Änderung des Produkts, das einer Instanz zugewiesen ist, sollten Sie auch den Wert für den shared_buffers
-Parameter entsprechend den Werten in den folgenden Formeln anpassen.
Bei virtuellen Computern mit bis zu 2 GiB Arbeitsspeicher lautet die Formel, die zum Berechnen des Werts shared_buffers
verwendet wird: memoryGib * 16384
.
Bei virtuellen Computern mit mehr als 2 GiB lautet die Formel, die zum Berechnen des Werts shared_buffers
verwendet wird: memoryGib * 32768
.
Basierend auf der vorherigen Formel werden in der folgenden Tabelle die Werte aufgeführt, auf die dieser Serverparameter je nach bereitgestellter Arbeitsspeichermenge festgelegt wird:
Arbeitsspeichergröße | shared_buffers |
---|---|
2 GiB | 32768 |
4 GiB | 131072 |
8 GiB | 262144 |
16 GiB | 524288 |
32GiB | 1048576 |
48 GiB | 1572864 |
64GiB | 2097152 |
80 GiB | 2621440 |
128 GB | 4194304 |
160 GiB | 5242880 |
192 GiB | 6291456 |
256 GiB | 8388608 |
384 GiB | 12582912 |
432 GiB | 14155776 |
672 GiB | 22020096 |
shared_memory_type
attribute | Wert |
---|---|
Kategorie | Ressourcennutzung/Arbeitsspeicher |
Beschreibung | Wählt die für den Hauptspeicherbereich gemeinsam genutzte Speicherimplementierung aus. |
Datentyp | Enumeration |
Standardwert | mmap |
Zulässige Werte | mmap |
Parametertyp | schreibgeschützt |
Dokumentation | shared_memory_type |
temp_buffers
attribute | Wert |
---|---|
Kategorie | Ressourcennutzung/Arbeitsspeicher |
Beschreibung | Legt die maximale Anzahl von temporären Puffern fest, die von den einzelnen Datenbanksitzungen verwendet werden. |
Datentyp | integer |
Standardwert | 1024 |
Zulässige Werte | 100-1073741823 |
Parametertyp | dynamisch |
Dokumentation | temp_buffers |
work_mem
attribute | Wert |
---|---|
Kategorie | Ressourcennutzung/Arbeitsspeicher |
Beschreibung | Legt den Arbeitsspeicher fest, der von internen Sortiervorgängen und Hashtabellen vor dem Schreiben in temporäre Datenträgerdateien verwendet werden soll. |
Datentyp | integer |
Standardwert | 4096 |
Zulässige Werte | 4096-2097151 |
Parametertyp | dynamisch |
Dokumentation | work_mem |
Beschreibung
Der Parameter work_mem
in PostgreSQL steuert die Menge des Speichers, der bestimmten internen Vorgängen innerhalb des privaten Speicherbereichs jeder Datenbanksitzung zugeordnet ist. Beispiele für diese Vorgänge sind Sortieren und Hashing.
Im Gegensatz zu freigegebenen Puffern, die sich im freigegebenen Speicherbereich befinden, wird work_mem
in einem privaten Speicherbereich pro Sitzung oder pro Abfrage zugewiesen. Indem Sie eine angemessene work_mem
-Größe festlegen, können Sie die Effizienz dieser Vorgänge erheblich verbessern und die Notwendigkeit, temporäre Daten auf den Datenträger zu schreiben, verringern.
Wesentliche Punkte
- Privater Verbindungsspeicher:
work_mem
ist Teil des privaten Speichers, den jede Datenbanksitzung verwendet. Dieser Speicher unterscheidet sich von dem freigegebenen Speicherbereich, denshared_buffers
verwendet. - Abfragespezifische Verwendung: Nicht alle Sitzungen oder Abfragen verwenden
work_mem
. Für einfache Abfragen wieSELECT 1
istwork_mem
wahrscheinlich nicht erforderlich. Komplexere Abfragen mit Vorgängen wie Sortieren oder Hashing können jedoch einen oder mehrere Abschnitte vonwork_mem
nutzen. - Parallele Vorgänge: Bei Abfragen, die mehrere parallele Back-Ends umfassen, kann jedes Back-End potenziell einen oder mehrere Blöcke von
work_mem
verwenden.
Überwachen und Anpassen von work_mem
Es ist wichtig, die Leistung Ihres Systems kontinuierlich zu überwachen und work_mem
nach Bedarf anzupassen, in erster Linie, wenn langsame Abfrageausführungszeiten im Zusammenhang mit Sortier- oder Hashvorgängen langsam sind. Im Folgenden finden Sie Möglichkeiten zum Überwachen der Leistung mithilfe von Tools, die im Azure-Portal verfügbar sind:
- Einblick in die Abfrageleistung: Überprüfen Sie die wichtigsten Abfragen auf der Registerkarte temporärer Dateien, um Abfragen zu identifizieren, die temporäre Dateien generieren. Diese Situation deutet darauf hin, dass ein potenzieller Bedarf für die Erhöhung von
work_mem
vorhanden ist. - Anleitungen zur Problembehandlung: Verwenden Sie die Registerkarte Hohe Anzahl temporärer Dateien in den Anleitungen zur Problembehandlung, um problematische Abfragen zu identifizieren.
Granulare Anpassung
Beim Verwalten des work_mem
-Parameters ist es oft effizienter, Anpassungen granular vorzunehmen, anstatt einen globalen Wert festzulegen. Dieser Ansatz stellt sicher, dass Sie Speicher bewusst basierend auf den spezifischen Anforderungen von Prozessen und Benutzern zuordnen. Außerdem wird das Risiko minimiert, dass Probleme aufgrund ungenügendem Arbeitsspeicher auftreten. Gehen Sie hierzu wie folgt vor:
Benutzerebene: Wenn ein bestimmter Benutzer in erster Linie an Aggregations- oder Berichterstellungsaufgaben beteiligt ist, die arbeitsspeicherintensiv sind, sollten Sie den
work_mem
-Wert für diesen Benutzer anpassen. Verwenden Sie denALTER ROLE
-Befehl, um die Leistung der Benutzervorgänge zu verbessern.Funktions-/Prozedurebene: Wenn bestimmte Funktionen oder Prozeduren erhebliche Mengen temporärer Dateien generieren, kann die Erhöhung des
work_mem
-Wertes auf der Ebene der spezifischen Funktion oder Prozedur von Vorteil sein. Verwenden Sie den BefehlALTER FUNCTION
oderALTER PROCEDURE
, um diesen Vorgängen gezielt mehr Arbeitsspeicher zuzuweisen.Datenbankebene: Ändern Sie
work_mem
auf Datenbankebene nur, wenn bestimmte Datenbanken eine hohe Anzahl temporärer Dateien generieren.Globale Ebene: Wenn eine Analyse Ihres Systems zeigt, dass die meisten Abfragen kleine temporäre Dateien generieren, während nur wenige große Dateien erstellen, kann es sinnvoll sein, den
work_mem
-Wert global zu erhöhen. Diese Aktion erleichtert die meisten Abfragen zum Verarbeiten im Arbeitsspeicher, sodass Sie datenträgerbasierte Vorgänge vermeiden und die Effizienz verbessern können. Seien Sie jedoch immer vorsichtig und überwachen Sie die Speicherauslastung auf Ihrem Server, um sicherzustellen, dass der erhöhtework_mem
-Wert verarbeitet werden kann.
Bestimmen des minimalen work_mem-Werts für Sortiervorgänge
Um den Mindestwert von work_mem
für eine bestimmte Abfrage zu ermitteln, insbesondere wenn während des Sortiervorgangs temporäre Datenträgerdateien generiert werden, betrachten Sie zunächst die Größe der temporären Datei, die während der Abfrageausführung generiert wurde. Beispiel: Wenn eine Abfrage eine temporäre Datei mit 20 MB generiert:
- Stellen Sie mithilfe von psql oder Ihrem bevorzugten PostgreSQL-Client eine Verbindung mit Ihrer Datenbank her.
- Legen Sie einen anfänglichen
work_mem
-Wert etwas höher als 20 MB fest, um zusätzliche Header bei der Verarbeitung im Arbeitsspeicher zu berücksichtigen. Verwenden Sie z.B. folgenden Befehl:SET work_mem TO '25MB'
. - Führen Sie
EXPLAIN ANALYZE
für die problematische Abfrage in derselben Sitzung aus. - Überprüfen Sie die Ausgabe für
"Sort Method: quicksort Memory: xkB"
. Wenn es"external merge Disk: xkB"
angibt, heben Sie denwork_mem
-Wert inkrementell an, und testen Sie ihn erneut, bis"quicksort Memory"
angezeigt wird. Das Auftreten von"quicksort Memory"
-Signalen, dass die Abfrage jetzt im Arbeitsspeicher ausgeführt wird. - Nachdem Sie den Wert anhand dieser Methode ermittelt haben, können Sie ihn entweder global oder auf granulareren Ebenen (wie zuvor beschrieben) auf Ihre betrieblichen Anforderungen anwenden.
autovacuum_work_mem
attribute | Wert |
---|---|
Kategorie | Ressourcennutzung/Arbeitsspeicher |
Beschreibung | Legt den maximalen Arbeitsspeicher zur Verwendung durch die einzelnen Autovacuum-Workerprozesse fest. |
Datentyp | integer |
Standardwert | -1 |
Zulässige Werte | -1-2097151 |
Parametertyp | dynamisch |
Dokumentation | autovacuum_work_mem |
dynamic_shared_memory_type
attribute | Wert |
---|---|
Kategorie | Ressourcennutzung/Arbeitsspeicher |
Beschreibung | Wählt die verwendete Implementierung des dynamischen freigegebenen Speichers aus. |
Datentyp | Enumeration |
Standardwert | posix |
Zulässige Werte | posix |
Parametertyp | schreibgeschützt |
Dokumentation | dynamic_shared_memory_type |
hash_mem_multiplier
attribute | Wert |
---|---|
Kategorie | Ressourcennutzung/Arbeitsspeicher |
Beschreibung | Mehrfaches von work_mem, das für Hashtabellen verwendet werden soll |
Datentyp | NUMERIC |
Standardwert | 1 |
Zulässige Werte | 1-1000 |
Parametertyp | dynamisch |
Dokumentation | hash_mem_multiplier |
huge_pages
attribute | Wert |
---|---|
Kategorie | Ressourcennutzung/Arbeitsspeicher |
Beschreibung | Aktiviert/deaktiviert die Verwendung großer Speicherseiten. Diese Einstellung gilt nicht für Server mit weniger als 4 virtuellen Kernen. |
Datentyp | Enumeration |
Standardwert | try |
Zulässige Werte | on,off,try |
Parametertyp | static |
Dokumentation | huge_pages |
Beschreibung
Große Seiten sind ein Feature, mit dem Arbeitsspeicher in größeren Blöcken verwaltet werden kann. Sie können in der Regel Blöcke von bis zu 2 MB verwalten, im Gegensatz zu den standardmäßigen 4-KB-Seiten.
Die Verwendung großer Seiten kann Leistungsvorteile bieten, welche die CPU effektiv auslagern:
- Sie reduzieren den Aufwand in Zusammenhang mit den Speicherverwaltungsaufgaben, z. B. weniger Translation Lookaside Buffer (TLB)-Fehler.
- Sie verkürzen die für die Speicherverwaltung benötigte Zeit.
Insbesondere können Sie in PostgreSQL große Seiten nur für den freigegebenen Speicherbereich verwenden. Ein erheblicher Teil des freigegebenen Speicherbereichs wird an freigegebene Puffer zugewiesen.
Ein weiterer Vorteil besteht darin, dass große Seiten den Austausch des freigegebenen Speicherbereichs auf den Datenträger verhindern und so die Leistung weiter stabilisieren.
Empfehlungen
- Vermeiden Sie für Server mit erheblichen Speicherressourcen das Deaktivieren großer Seiten. Das Deaktivieren großer Seiten kann die Leistung beeinträchtigen.
- Wenn Sie mit einem kleineren Server beginnen, der keine großen Seiten unterstützt, aber die Skalierung auf einen Server mit Unterstützung für große Seiten antizipieren, belassen Sie die Einstellung
huge_pages
aufTRY
, um einen nahtlosen Übergang und optimale Leistung zu gewährleisten.
Azure-spezifische Hinweise
Für Server mit vier oder mehr vCores werden große Seiten automatisch vom zugrunde liegenden Betriebssystem zugewiesen. Das Feature ist für Server mit weniger als vier vCores nicht verfügbar. Die Anzahl der großen Seiten wird automatisch angepasst, wenn Einstellungen für gemeinsam genutzten Speicher geändert werden, einschließlich Änderungen an shared_buffers
.
maintenance_work_mem
attribute | Wert |
---|---|
Kategorie | Ressourcennutzung/Arbeitsspeicher |
Beschreibung | Legt den maximalen Arbeitsspeicher fest, der für Wartungsvorgänge wie VACUUM, „Create Index“ verwendet werden soll. |
Datentyp | integer |
Standardwert | Hängt von Ressourcen (virtuelle Kerne, RAM oder Speicherplatz) ab, die dem Server zugeordnet sind. |
Zulässige Werte | 1024-2097151 |
Parametertyp | dynamisch |
Dokumentation | maintenance_work_mem |
Beschreibung
maintenance_work_mem
ist ein Konfigurationsparameter in PostgreSQL. Er bestimmt die Menge an Arbeitsspeicher, der den Wartungsvorgängen zugeordnet ist, z. B. VACUUM
, CREATE INDEX
und ALTER TABLE
. Im Gegensatz zu work_mem
, was sich auf die Speicherzuweisung für Abfragevorgänge auswirkt, ist maintenance_work_mem
für Aufgaben reserviert, die die Datenbankstruktur verwalten und optimieren.
Wesentliche Punkte
- Begrenzung des Vakuumspeichers: Wenn Sie die Bereinigung von toten Tupeln beschleunigen möchten, indem Sie
maintenance_work_mem
erhöhen, beachten Sie, dass überVACUUM
eine integrierte Einschränkung für das Sammeln von toten Tupel-IDs verfügt. Es kann nur bis zu 1 GB Arbeitsspeicher für diesen Prozess verwenden. - Trennung des Arbeitsspeichers für Autovacuum: Sie können die Einstellung
autovacuum_work_mem
verwenden, um den für Autovacuum-Vorgänge verwendeten Arbeitsspeicher unabhängig zu nutzen. Diese Einstellung fungiert als Teilmenge vonmaintenance_work_mem
. Sie können entscheiden, wie viel Arbeitsspeicher Autovacuum verwendet, ohne die Speicherzuweisung für andere Wartungsaufgaben und Datendefinitionsvorgänge zu beeinflussen.
Azure-spezifische Hinweise
Der Standardwert für den Serverparameter maintenance_work_mem
wird berechnet, wenn Sie die Instanz von Azure Database for PostgreSQL – Flexible Server basierend auf dem Produktnamen bereitstellen, den Sie für die Berechnung auswählen. Alle nachfolgenden Änderungen der Produktauswahl an der Berechnung, die den flexiblen Server unterstützt, haben keine Auswirkungen auf den Standardwert für den Serverparameter maintenance_work_mem
dieser Instanz.
Bei jeder Änderung des Produkts, das einer Instanz zugewiesen ist, sollten Sie auch den Wert für den maintenance_work_mem
-Parameter entsprechend den Werten in der folgenden Formel anpassen.
Die Formel, die zum Berechnen des Werts verwendet maintenance_work_mem
wird, lautet (long)(82.5 * ln(memoryGiB) + 40) * 1024
.
Basierend auf der vorherigen Formel werden in der folgenden Tabelle die Werte aufgeführt, auf die dieser Serverparameter je nach bereitgestellter Arbeitsspeichermenge festgelegt wird:
Arbeitsspeichergröße | maintenance_work_mem |
---|---|
2 GiB | 99328 KiB |
4 GiB | 157696 KiB |
8 GiB | 216064 KiB |
16 GiB | 274432 KiB |
32GiB | 332800 KiB |
48 GiB | 367616 KiB |
64GiB | 392192 KiB |
80 GiB | 410624 KiB |
128 GB | 450560 KiB |
160 GiB | 468992 KiB |
192 GiB | 484352 KiB |
256 GiB | 508928 KiB |
384 GiB | 542720 KiB |
432 GiB | 552960 KiB |
672 GiB | 590848 KiB |
max_prepared_transactions
attribute | Wert |
---|---|
Kategorie | Ressourcennutzung/Arbeitsspeicher |
Beschreibung | Legt die maximale Anzahl gleichzeitig vorbereiteter Transaktionen fest. Wenn Sie einen Replikationsserver betreiben, müssen Sie diesen Parameter auf denselben oder einen höheren Wert als auf dem Primärserver festlegen. |
Datentyp | integer |
Standardwert | 0 |
Zulässige Werte | 0-262143 |
Parametertyp | static |
Dokumentation | max_prepared_transactions |
max_stack_depth
attribute | Wert |
---|---|
Kategorie | Ressourcennutzung/Arbeitsspeicher |
Beschreibung | Legt die maximale Stapeltiefe in Kilobyte fest. |
Datentyp | integer |
Standardwert | 2048 |
Zulässige Werte | 2048 |
Parametertyp | schreibgeschützt |
Dokumentation | max_stack_depth |
shared_buffers
attribute | Wert |
---|---|
Kategorie | Ressourcennutzung/Arbeitsspeicher |
Beschreibung | Legt die Anzahl der vom Server verwendeten freigegebenen Speicherpuffer fest. Die Einheit ist 8 KB. Zulässige Werte liegen innerhalb des Bereich von 10 % bis 75 % des verfügbaren Arbeitsspeichers. |
Datentyp | integer |
Standardwert | Hängt von Ressourcen (virtuelle Kerne, RAM oder Speicherplatz) ab, die dem Server zugeordnet sind. |
Zulässige Werte | 16-1073741823 |
Parametertyp | static |
Dokumentation | shared_buffers |
Beschreibung
Der Konfigurationsparameter shared_buffers
bestimmt die Menge des Systemspeichers, der der PostgreSQL-Datenbank zur Pufferung von Daten zugeordnet ist. Er dient als zentraler Speicherpool, auf den alle Datenbankprozesse zugreifen können.
Wenn Daten benötigt werden, überprüft der Datenbankprozess zuerst den freigegebenen Puffer. Wenn die erforderlichen Daten vorhanden sind, werden sie schnell abgerufen, und ein zeitaufwändigerer Datenträgerlesevorgang wird umgangen. Freigegebene Puffer dienen als Vermittler zwischen den Datenbankprozessen und dem Datenträger und reduzieren effektiv die Anzahl der erforderlichen E/A-Vorgänge.
Azure-spezifische Hinweise
Der Standardwert für den Serverparameter shared_buffers
wird berechnet, wenn Sie die Instanz von Azure Database for PostgreSQL – Flexible Server basierend auf dem Produktnamen bereitstellen, den Sie für die Berechnung auswählen. Alle nachfolgenden Änderungen der Produktauswahl an der Berechnung, die den flexiblen Server unterstützt, haben keine Auswirkungen auf den Standardwert für den Serverparameter shared_buffers
dieser Instanz.
Bei jeder Änderung des Produkts, das einer Instanz zugewiesen ist, sollten Sie auch den Wert für den shared_buffers
-Parameter entsprechend den Werten in den folgenden Formeln anpassen.
Bei virtuellen Computern mit bis zu 2 GiB Arbeitsspeicher lautet die Formel, die zum Berechnen des Werts shared_buffers
verwendet wird: memoryGib * 16384
.
Bei virtuellen Computern mit mehr als 2 GiB lautet die Formel, die zum Berechnen des Werts shared_buffers
verwendet wird: memoryGib * 32768
.
Basierend auf der vorherigen Formel werden in der folgenden Tabelle die Werte aufgeführt, auf die dieser Serverparameter je nach bereitgestellter Arbeitsspeichermenge festgelegt wird:
Arbeitsspeichergröße | shared_buffers |
---|---|
2 GiB | 32768 |
4 GiB | 131072 |
8 GiB | 262144 |
16 GiB | 524288 |
32GiB | 1048576 |
48 GiB | 1572864 |
64GiB | 2097152 |
80 GiB | 2621440 |
128 GB | 4194304 |
160 GiB | 5242880 |
192 GiB | 6291456 |
256 GiB | 8388608 |
384 GiB | 12582912 |
432 GiB | 14155776 |
672 GiB | 22020096 |
shared_memory_type
attribute | Wert |
---|---|
Kategorie | Ressourcennutzung/Arbeitsspeicher |
Beschreibung | Wählt die für den Hauptspeicherbereich gemeinsam genutzte Speicherimplementierung aus. |
Datentyp | Enumeration |
Standardwert | mmap |
Zulässige Werte | mmap |
Parametertyp | schreibgeschützt |
Dokumentation | shared_memory_type |
temp_buffers
attribute | Wert |
---|---|
Kategorie | Ressourcennutzung/Arbeitsspeicher |
Beschreibung | Legt die maximale Anzahl von temporären Puffern fest, die von den einzelnen Datenbanksitzungen verwendet werden. |
Datentyp | integer |
Standardwert | 1024 |
Zulässige Werte | 100-1073741823 |
Parametertyp | dynamisch |
Dokumentation | temp_buffers |
work_mem
attribute | Wert |
---|---|
Kategorie | Ressourcennutzung/Arbeitsspeicher |
Beschreibung | Legt den Arbeitsspeicher fest, der von internen Sortiervorgängen und Hashtabellen vor dem Schreiben in temporäre Datenträgerdateien verwendet werden soll. |
Datentyp | integer |
Standardwert | 4096 |
Zulässige Werte | 4096-2097151 |
Parametertyp | dynamisch |
Dokumentation | work_mem |
Beschreibung
Der Parameter work_mem
in PostgreSQL steuert die Menge des Speichers, der bestimmten internen Vorgängen innerhalb des privaten Speicherbereichs jeder Datenbanksitzung zugeordnet ist. Beispiele für diese Vorgänge sind Sortieren und Hashing.
Im Gegensatz zu freigegebenen Puffern, die sich im freigegebenen Speicherbereich befinden, wird work_mem
in einem privaten Speicherbereich pro Sitzung oder pro Abfrage zugewiesen. Indem Sie eine angemessene work_mem
-Größe festlegen, können Sie die Effizienz dieser Vorgänge erheblich verbessern und die Notwendigkeit, temporäre Daten auf den Datenträger zu schreiben, verringern.
Wesentliche Punkte
- Privater Verbindungsspeicher:
work_mem
ist Teil des privaten Speichers, den jede Datenbanksitzung verwendet. Dieser Speicher unterscheidet sich von dem freigegebenen Speicherbereich, denshared_buffers
verwendet. - Abfragespezifische Verwendung: Nicht alle Sitzungen oder Abfragen verwenden
work_mem
. Für einfache Abfragen wieSELECT 1
istwork_mem
wahrscheinlich nicht erforderlich. Komplexere Abfragen mit Vorgängen wie Sortieren oder Hashing können jedoch einen oder mehrere Abschnitte vonwork_mem
nutzen. - Parallele Vorgänge: Bei Abfragen, die mehrere parallele Back-Ends umfassen, kann jedes Back-End potenziell einen oder mehrere Blöcke von
work_mem
verwenden.
Überwachen und Anpassen von work_mem
Es ist wichtig, die Leistung Ihres Systems kontinuierlich zu überwachen und work_mem
nach Bedarf anzupassen, in erster Linie, wenn langsame Abfrageausführungszeiten im Zusammenhang mit Sortier- oder Hashvorgängen langsam sind. Im Folgenden finden Sie Möglichkeiten zum Überwachen der Leistung mithilfe von Tools, die im Azure-Portal verfügbar sind:
- Einblick in die Abfrageleistung: Überprüfen Sie die wichtigsten Abfragen auf der Registerkarte temporärer Dateien, um Abfragen zu identifizieren, die temporäre Dateien generieren. Diese Situation deutet darauf hin, dass ein potenzieller Bedarf für die Erhöhung von
work_mem
vorhanden ist. - Anleitungen zur Problembehandlung: Verwenden Sie die Registerkarte Hohe Anzahl temporärer Dateien in den Anleitungen zur Problembehandlung, um problematische Abfragen zu identifizieren.
Granulare Anpassung
Beim Verwalten des work_mem
-Parameters ist es oft effizienter, Anpassungen granular vorzunehmen, anstatt einen globalen Wert festzulegen. Dieser Ansatz stellt sicher, dass Sie Speicher bewusst basierend auf den spezifischen Anforderungen von Prozessen und Benutzern zuordnen. Außerdem wird das Risiko minimiert, dass Probleme aufgrund ungenügendem Arbeitsspeicher auftreten. Gehen Sie hierzu wie folgt vor:
Benutzerebene: Wenn ein bestimmter Benutzer in erster Linie an Aggregations- oder Berichterstellungsaufgaben beteiligt ist, die arbeitsspeicherintensiv sind, sollten Sie den
work_mem
-Wert für diesen Benutzer anpassen. Verwenden Sie denALTER ROLE
-Befehl, um die Leistung der Benutzervorgänge zu verbessern.Funktions-/Prozedurebene: Wenn bestimmte Funktionen oder Prozeduren erhebliche Mengen temporärer Dateien generieren, kann die Erhöhung des
work_mem
-Wertes auf der Ebene der spezifischen Funktion oder Prozedur von Vorteil sein. Verwenden Sie den BefehlALTER FUNCTION
oderALTER PROCEDURE
, um diesen Vorgängen gezielt mehr Arbeitsspeicher zuzuweisen.Datenbankebene: Ändern Sie
work_mem
auf Datenbankebene nur, wenn bestimmte Datenbanken eine hohe Anzahl temporärer Dateien generieren.Globale Ebene: Wenn eine Analyse Ihres Systems zeigt, dass die meisten Abfragen kleine temporäre Dateien generieren, während nur wenige große Dateien erstellen, kann es sinnvoll sein, den
work_mem
-Wert global zu erhöhen. Diese Aktion erleichtert die meisten Abfragen zum Verarbeiten im Arbeitsspeicher, sodass Sie datenträgerbasierte Vorgänge vermeiden und die Effizienz verbessern können. Seien Sie jedoch immer vorsichtig und überwachen Sie die Speicherauslastung auf Ihrem Server, um sicherzustellen, dass der erhöhtework_mem
-Wert verarbeitet werden kann.
Bestimmen des minimalen work_mem-Werts für Sortiervorgänge
Um den Mindestwert von work_mem
für eine bestimmte Abfrage zu ermitteln, insbesondere wenn während des Sortiervorgangs temporäre Datenträgerdateien generiert werden, betrachten Sie zunächst die Größe der temporären Datei, die während der Abfrageausführung generiert wurde. Beispiel: Wenn eine Abfrage eine temporäre Datei mit 20 MB generiert:
- Stellen Sie mithilfe von psql oder Ihrem bevorzugten PostgreSQL-Client eine Verbindung mit Ihrer Datenbank her.
- Legen Sie einen anfänglichen
work_mem
-Wert etwas höher als 20 MB fest, um zusätzliche Header bei der Verarbeitung im Arbeitsspeicher zu berücksichtigen. Verwenden Sie z.B. folgenden Befehl:SET work_mem TO '25MB'
. - Führen Sie
EXPLAIN ANALYZE
für die problematische Abfrage in derselben Sitzung aus. - Überprüfen Sie die Ausgabe für
"Sort Method: quicksort Memory: xkB"
. Wenn es"external merge Disk: xkB"
angibt, heben Sie denwork_mem
-Wert inkrementell an, und testen Sie ihn erneut, bis"quicksort Memory"
angezeigt wird. Das Auftreten von"quicksort Memory"
-Signalen, dass die Abfrage jetzt im Arbeitsspeicher ausgeführt wird. - Nachdem Sie den Wert anhand dieser Methode ermittelt haben, können Sie ihn entweder global oder auf granulareren Ebenen (wie zuvor beschrieben) auf Ihre betrieblichen Anforderungen anwenden.
autovacuum_work_mem
attribute | Wert |
---|---|
Kategorie | Ressourcennutzung/Arbeitsspeicher |
Beschreibung | Legt den maximalen Arbeitsspeicher zur Verwendung durch die einzelnen Autovacuum-Workerprozesse fest. |
Datentyp | integer |
Standardwert | -1 |
Zulässige Werte | -1-2097151 |
Parametertyp | dynamisch |
Dokumentation | autovacuum_work_mem |
dynamic_shared_memory_type
attribute | Wert |
---|---|
Kategorie | Ressourcennutzung/Arbeitsspeicher |
Beschreibung | Wählt die verwendete Implementierung des dynamischen freigegebenen Speichers aus. |
Datentyp | Enumeration |
Standardwert | posix |
Zulässige Werte | posix |
Parametertyp | schreibgeschützt |
Dokumentation | dynamic_shared_memory_type |
huge_pages
attribute | Wert |
---|---|
Kategorie | Ressourcennutzung/Arbeitsspeicher |
Beschreibung | Aktiviert/deaktiviert die Verwendung großer Speicherseiten. Diese Einstellung gilt nicht für Server mit weniger als 4 virtuellen Kernen. |
Datentyp | Enumeration |
Standardwert | try |
Zulässige Werte | on,off,try |
Parametertyp | static |
Dokumentation | huge_pages |
Beschreibung
Große Seiten sind ein Feature, mit dem Arbeitsspeicher in größeren Blöcken verwaltet werden kann. Sie können in der Regel Blöcke von bis zu 2 MB verwalten, im Gegensatz zu den standardmäßigen 4-KB-Seiten.
Die Verwendung großer Seiten kann Leistungsvorteile bieten, welche die CPU effektiv auslagern:
- Sie reduzieren den Aufwand in Zusammenhang mit den Speicherverwaltungsaufgaben, z. B. weniger Translation Lookaside Buffer (TLB)-Fehler.
- Sie verkürzen die für die Speicherverwaltung benötigte Zeit.
Insbesondere können Sie in PostgreSQL große Seiten nur für den freigegebenen Speicherbereich verwenden. Ein erheblicher Teil des freigegebenen Speicherbereichs wird an freigegebene Puffer zugewiesen.
Ein weiterer Vorteil besteht darin, dass große Seiten den Austausch des freigegebenen Speicherbereichs auf den Datenträger verhindern und so die Leistung weiter stabilisieren.
Empfehlungen
- Vermeiden Sie für Server mit erheblichen Speicherressourcen das Deaktivieren großer Seiten. Das Deaktivieren großer Seiten kann die Leistung beeinträchtigen.
- Wenn Sie mit einem kleineren Server beginnen, der keine großen Seiten unterstützt, aber die Skalierung auf einen Server mit Unterstützung für große Seiten antizipieren, belassen Sie die Einstellung
huge_pages
aufTRY
, um einen nahtlosen Übergang und optimale Leistung zu gewährleisten.
Azure-spezifische Hinweise
Für Server mit vier oder mehr vCores werden große Seiten automatisch vom zugrunde liegenden Betriebssystem zugewiesen. Das Feature ist für Server mit weniger als vier vCores nicht verfügbar. Die Anzahl der großen Seiten wird automatisch angepasst, wenn Einstellungen für gemeinsam genutzten Speicher geändert werden, einschließlich Änderungen an shared_buffers
.
maintenance_work_mem
attribute | Wert |
---|---|
Kategorie | Ressourcennutzung/Arbeitsspeicher |
Beschreibung | Legt den maximalen Arbeitsspeicher fest, der für Wartungsvorgänge wie VACUUM, „Create Index“ verwendet werden soll. |
Datentyp | integer |
Standardwert | Hängt von Ressourcen (virtuelle Kerne, RAM oder Speicherplatz) ab, die dem Server zugeordnet sind. |
Zulässige Werte | 1024-2097151 |
Parametertyp | dynamisch |
Dokumentation | maintenance_work_mem |
Beschreibung
maintenance_work_mem
ist ein Konfigurationsparameter in PostgreSQL. Er bestimmt die Menge an Arbeitsspeicher, der den Wartungsvorgängen zugeordnet ist, z. B. VACUUM
, CREATE INDEX
und ALTER TABLE
. Im Gegensatz zu work_mem
, was sich auf die Speicherzuweisung für Abfragevorgänge auswirkt, ist maintenance_work_mem
für Aufgaben reserviert, die die Datenbankstruktur verwalten und optimieren.
Wesentliche Punkte
- Begrenzung des Vakuumspeichers: Wenn Sie die Bereinigung von toten Tupeln beschleunigen möchten, indem Sie
maintenance_work_mem
erhöhen, beachten Sie, dass überVACUUM
eine integrierte Einschränkung für das Sammeln von toten Tupel-IDs verfügt. Es kann nur bis zu 1 GB Arbeitsspeicher für diesen Prozess verwenden. - Trennung des Arbeitsspeichers für Autovacuum: Sie können die Einstellung
autovacuum_work_mem
verwenden, um den für Autovacuum-Vorgänge verwendeten Arbeitsspeicher unabhängig zu nutzen. Diese Einstellung fungiert als Teilmenge vonmaintenance_work_mem
. Sie können entscheiden, wie viel Arbeitsspeicher Autovacuum verwendet, ohne die Speicherzuweisung für andere Wartungsaufgaben und Datendefinitionsvorgänge zu beeinflussen.
Azure-spezifische Hinweise
Der Standardwert für den Serverparameter maintenance_work_mem
wird berechnet, wenn Sie die Instanz von Azure Database for PostgreSQL – Flexible Server basierend auf dem Produktnamen bereitstellen, den Sie für die Berechnung auswählen. Alle nachfolgenden Änderungen der Produktauswahl an der Berechnung, die den flexiblen Server unterstützt, haben keine Auswirkungen auf den Standardwert für den Serverparameter maintenance_work_mem
dieser Instanz.
Bei jeder Änderung des Produkts, das einer Instanz zugewiesen ist, sollten Sie auch den Wert für den maintenance_work_mem
-Parameter entsprechend den Werten in der folgenden Formel anpassen.
Die Formel, die zum Berechnen des Werts verwendet maintenance_work_mem
wird, lautet (long)(82.5 * ln(memoryGiB) + 40) * 1024
.
Basierend auf der vorherigen Formel werden in der folgenden Tabelle die Werte aufgeführt, auf die dieser Serverparameter je nach bereitgestellter Arbeitsspeichermenge festgelegt wird:
Arbeitsspeichergröße | maintenance_work_mem |
---|---|
2 GiB | 99328 KiB |
4 GiB | 157696 KiB |
8 GiB | 216064 KiB |
16 GiB | 274432 KiB |
32GiB | 332800 KiB |
48 GiB | 367616 KiB |
64GiB | 392192 KiB |
80 GiB | 410624 KiB |
128 GB | 450560 KiB |
160 GiB | 468992 KiB |
192 GiB | 484352 KiB |
256 GiB | 508928 KiB |
384 GiB | 542720 KiB |
432 GiB | 552960 KiB |
672 GiB | 590848 KiB |
max_prepared_transactions
attribute | Wert |
---|---|
Kategorie | Ressourcennutzung/Arbeitsspeicher |
Beschreibung | Legt die maximale Anzahl gleichzeitig vorbereiteter Transaktionen fest. Wenn Sie einen Replikationsserver betreiben, müssen Sie diesen Parameter auf denselben oder einen höheren Wert als auf dem Primärserver festlegen. |
Datentyp | integer |
Standardwert | 0 |
Zulässige Werte | 0-262143 |
Parametertyp | static |
Dokumentation | max_prepared_transactions |
max_stack_depth
attribute | Wert |
---|---|
Kategorie | Ressourcennutzung/Arbeitsspeicher |
Beschreibung | Legt die maximale Stapeltiefe in Kilobyte fest. |
Datentyp | integer |
Standardwert | 2048 |
Zulässige Werte | 2048 |
Parametertyp | schreibgeschützt |
Dokumentation | max_stack_depth |
shared_buffers
attribute | Wert |
---|---|
Kategorie | Ressourcennutzung/Arbeitsspeicher |
Beschreibung | Legt die Anzahl der vom Server verwendeten freigegebenen Speicherpuffer fest. Die Einheit ist 8 KB. Zulässige Werte liegen innerhalb des Bereich von 10 % bis 75 % des verfügbaren Arbeitsspeichers. |
Datentyp | integer |
Standardwert | Hängt von Ressourcen (virtuelle Kerne, RAM oder Speicherplatz) ab, die dem Server zugeordnet sind. |
Zulässige Werte | 16-1073741823 |
Parametertyp | static |
Dokumentation | shared_buffers |
Beschreibung
Der Konfigurationsparameter shared_buffers
bestimmt die Menge des Systemspeichers, der der PostgreSQL-Datenbank zur Pufferung von Daten zugeordnet ist. Er dient als zentraler Speicherpool, auf den alle Datenbankprozesse zugreifen können.
Wenn Daten benötigt werden, überprüft der Datenbankprozess zuerst den freigegebenen Puffer. Wenn die erforderlichen Daten vorhanden sind, werden sie schnell abgerufen, und ein zeitaufwändigerer Datenträgerlesevorgang wird umgangen. Freigegebene Puffer dienen als Vermittler zwischen den Datenbankprozessen und dem Datenträger und reduzieren effektiv die Anzahl der erforderlichen E/A-Vorgänge.
Azure-spezifische Hinweise
Der Standardwert für den Serverparameter shared_buffers
wird berechnet, wenn Sie die Instanz von Azure Database for PostgreSQL – Flexible Server basierend auf dem Produktnamen bereitstellen, den Sie für die Berechnung auswählen. Alle nachfolgenden Änderungen der Produktauswahl an der Berechnung, die den flexiblen Server unterstützt, haben keine Auswirkungen auf den Standardwert für den Serverparameter shared_buffers
dieser Instanz.
Bei jeder Änderung des Produkts, das einer Instanz zugewiesen ist, sollten Sie auch den Wert für den shared_buffers
-Parameter entsprechend den Werten in den folgenden Formeln anpassen.
Bei virtuellen Computern mit bis zu 2 GiB Arbeitsspeicher lautet die Formel, die zum Berechnen des Werts shared_buffers
verwendet wird: memoryGib * 16384
.
Bei virtuellen Computern mit mehr als 2 GiB lautet die Formel, die zum Berechnen des Werts shared_buffers
verwendet wird: memoryGib * 32768
.
Basierend auf der vorherigen Formel werden in der folgenden Tabelle die Werte aufgeführt, auf die dieser Serverparameter je nach bereitgestellter Arbeitsspeichermenge festgelegt wird:
Arbeitsspeichergröße | shared_buffers |
---|---|
2 GiB | 32768 |
4 GiB | 131072 |
8 GiB | 262144 |
16 GiB | 524288 |
32GiB | 1048576 |
48 GiB | 1572864 |
64GiB | 2097152 |
80 GiB | 2621440 |
128 GB | 4194304 |
160 GiB | 5242880 |
192 GiB | 6291456 |
256 GiB | 8388608 |
384 GiB | 12582912 |
432 GiB | 14155776 |
672 GiB | 22020096 |
temp_buffers
attribute | Wert |
---|---|
Kategorie | Ressourcennutzung/Arbeitsspeicher |
Beschreibung | Legt die maximale Anzahl von temporären Puffern fest, die von den einzelnen Datenbanksitzungen verwendet werden. |
Datentyp | integer |
Standardwert | 1024 |
Zulässige Werte | 100-1073741823 |
Parametertyp | dynamisch |
Dokumentation | temp_buffers |
work_mem
attribute | Wert |
---|---|
Kategorie | Ressourcennutzung/Arbeitsspeicher |
Beschreibung | Legt den Arbeitsspeicher fest, der von internen Sortiervorgängen und Hashtabellen vor dem Schreiben in temporäre Datenträgerdateien verwendet werden soll. |
Datentyp | integer |
Standardwert | 4096 |
Zulässige Werte | 4096-2097151 |
Parametertyp | dynamisch |
Dokumentation | work_mem |
Beschreibung
Der Parameter work_mem
in PostgreSQL steuert die Menge des Speichers, der bestimmten internen Vorgängen innerhalb des privaten Speicherbereichs jeder Datenbanksitzung zugeordnet ist. Beispiele für diese Vorgänge sind Sortieren und Hashing.
Im Gegensatz zu freigegebenen Puffern, die sich im freigegebenen Speicherbereich befinden, wird work_mem
in einem privaten Speicherbereich pro Sitzung oder pro Abfrage zugewiesen. Indem Sie eine angemessene work_mem
-Größe festlegen, können Sie die Effizienz dieser Vorgänge erheblich verbessern und die Notwendigkeit, temporäre Daten auf den Datenträger zu schreiben, verringern.
Wesentliche Punkte
- Privater Verbindungsspeicher:
work_mem
ist Teil des privaten Speichers, den jede Datenbanksitzung verwendet. Dieser Speicher unterscheidet sich von dem freigegebenen Speicherbereich, denshared_buffers
verwendet. - Abfragespezifische Verwendung: Nicht alle Sitzungen oder Abfragen verwenden
work_mem
. Für einfache Abfragen wieSELECT 1
istwork_mem
wahrscheinlich nicht erforderlich. Komplexere Abfragen mit Vorgängen wie Sortieren oder Hashing können jedoch einen oder mehrere Abschnitte vonwork_mem
nutzen. - Parallele Vorgänge: Bei Abfragen, die mehrere parallele Back-Ends umfassen, kann jedes Back-End potenziell einen oder mehrere Blöcke von
work_mem
verwenden.
Überwachen und Anpassen von work_mem
Es ist wichtig, die Leistung Ihres Systems kontinuierlich zu überwachen und work_mem
nach Bedarf anzupassen, in erster Linie, wenn langsame Abfrageausführungszeiten im Zusammenhang mit Sortier- oder Hashvorgängen langsam sind. Im Folgenden finden Sie Möglichkeiten zum Überwachen der Leistung mithilfe von Tools, die im Azure-Portal verfügbar sind:
- Einblick in die Abfrageleistung: Überprüfen Sie die wichtigsten Abfragen auf der Registerkarte temporärer Dateien, um Abfragen zu identifizieren, die temporäre Dateien generieren. Diese Situation deutet darauf hin, dass ein potenzieller Bedarf für die Erhöhung von
work_mem
vorhanden ist. - Anleitungen zur Problembehandlung: Verwenden Sie die Registerkarte Hohe Anzahl temporärer Dateien in den Anleitungen zur Problembehandlung, um problematische Abfragen zu identifizieren.
Granulare Anpassung
Beim Verwalten des work_mem
-Parameters ist es oft effizienter, Anpassungen granular vorzunehmen, anstatt einen globalen Wert festzulegen. Dieser Ansatz stellt sicher, dass Sie Speicher bewusst basierend auf den spezifischen Anforderungen von Prozessen und Benutzern zuordnen. Außerdem wird das Risiko minimiert, dass Probleme aufgrund ungenügendem Arbeitsspeicher auftreten. Gehen Sie hierzu wie folgt vor:
Benutzerebene: Wenn ein bestimmter Benutzer in erster Linie an Aggregations- oder Berichterstellungsaufgaben beteiligt ist, die arbeitsspeicherintensiv sind, sollten Sie den
work_mem
-Wert für diesen Benutzer anpassen. Verwenden Sie denALTER ROLE
-Befehl, um die Leistung der Benutzervorgänge zu verbessern.Funktions-/Prozedurebene: Wenn bestimmte Funktionen oder Prozeduren erhebliche Mengen temporärer Dateien generieren, kann die Erhöhung des
work_mem
-Wertes auf der Ebene der spezifischen Funktion oder Prozedur von Vorteil sein. Verwenden Sie den BefehlALTER FUNCTION
oderALTER PROCEDURE
, um diesen Vorgängen gezielt mehr Arbeitsspeicher zuzuweisen.Datenbankebene: Ändern Sie
work_mem
auf Datenbankebene nur, wenn bestimmte Datenbanken eine hohe Anzahl temporärer Dateien generieren.Globale Ebene: Wenn eine Analyse Ihres Systems zeigt, dass die meisten Abfragen kleine temporäre Dateien generieren, während nur wenige große Dateien erstellen, kann es sinnvoll sein, den
work_mem
-Wert global zu erhöhen. Diese Aktion erleichtert die meisten Abfragen zum Verarbeiten im Arbeitsspeicher, sodass Sie datenträgerbasierte Vorgänge vermeiden und die Effizienz verbessern können. Seien Sie jedoch immer vorsichtig und überwachen Sie die Speicherauslastung auf Ihrem Server, um sicherzustellen, dass der erhöhtework_mem
-Wert verarbeitet werden kann.
Bestimmen des minimalen work_mem-Werts für Sortiervorgänge
Um den Mindestwert von work_mem
für eine bestimmte Abfrage zu ermitteln, insbesondere wenn während des Sortiervorgangs temporäre Datenträgerdateien generiert werden, betrachten Sie zunächst die Größe der temporären Datei, die während der Abfrageausführung generiert wurde. Beispiel: Wenn eine Abfrage eine temporäre Datei mit 20 MB generiert:
- Stellen Sie mithilfe von psql oder Ihrem bevorzugten PostgreSQL-Client eine Verbindung mit Ihrer Datenbank her.
- Legen Sie einen anfänglichen
work_mem
-Wert etwas höher als 20 MB fest, um zusätzliche Header bei der Verarbeitung im Arbeitsspeicher zu berücksichtigen. Verwenden Sie z.B. folgenden Befehl:SET work_mem TO '25MB'
. - Führen Sie
EXPLAIN ANALYZE
für die problematische Abfrage in derselben Sitzung aus. - Überprüfen Sie die Ausgabe für
"Sort Method: quicksort Memory: xkB"
. Wenn es"external merge Disk: xkB"
angibt, heben Sie denwork_mem
-Wert inkrementell an, und testen Sie ihn erneut, bis"quicksort Memory"
angezeigt wird. Das Auftreten von"quicksort Memory"
-Signalen, dass die Abfrage jetzt im Arbeitsspeicher ausgeführt wird. - Nachdem Sie den Wert anhand dieser Methode ermittelt haben, können Sie ihn entweder global oder auf granulareren Ebenen (wie zuvor beschrieben) auf Ihre betrieblichen Anforderungen anwenden.