Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
autovacuum_work_mem
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | Legt den maximalen Arbeitsspeicher für die einzelnen Autovacuum-Arbeitsprozesse fest. |
| Datentyp | integer |
| Standardwert | -1 |
| Zulässige Werte | -1-2097151 |
| Parametertyp | dynamic |
| Dokumentation | autovacuum_work_mem |
commit_timestamp_buffers
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | Legt die Größe des dedizierten Pufferpools fest, der für den Commit-Zeitstempelcache verwendet wird. Geben Sie 0 an, damit dieser Wert als Bruchteil von shared_buffers bestimmt wird. |
| Datentyp | integer |
| Standardwert | 1024 |
| Zulässige Werte | 0-131072 |
| Parametertyp | Statisch |
| Dokumentation | commit_timestamp_buffers |
dynamischer_geteilt-Speicher_Typ
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | 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
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | Mehrfaches von work_mem, das für Hashtabellen verwendet werden soll. |
| Datentyp | NUMERIC |
| Standardwert | 2 |
| Zulässige Werte | 1-1000 |
| Parametertyp | dynamic |
| Dokumentation | hash_mem_multiplier |
huge_pages
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | Verwendung riesiger Seiten unter Linux oder Windows. |
| Datentyp | enumeration |
| Standardwert | try |
| Zulässige Werte | on,off,try |
| Parametertyp | Statisch |
| Dokumentation | huge_pages |
Description
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 riesiger Seiten kann Leistungsvorteile bieten, die 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 riesige Seiten nur für den freigegebenen Speicherbereich verwenden. Ein erheblicher Teil des gemeinsamen Speicherbereichs wird für geteilte Puffer zugewiesen.
Ein weiterer Vorteil besteht darin, dass große Seiten den Austausch des freigegebenen Speicherbereichs auf den Datenträger verhindern, wodurch die Leistung weiter stabilisiert wird.
Recommendations
- 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 sie erwarten, dass sie auf einen Server skaliert werden, der dies tut, behalten Sie die
huge_pagesEinstellungTRYfür einen nahtlosen Übergang und eine optimale Leistung bei.
Azure-spezifische Hinweise
Für Server mit vier oder mehr vCores werden riesige Seiten automatisch vom zugrunde liegenden Betriebssystem zugeordnet. Das Feature ist für Server mit weniger als vier vCores nicht verfügbar. Die Anzahl der riesigen Seiten wird automatisch angepasst, wenn alle Einstellungen für gemeinsam genutzten Speicher geändert werden, einschließlich Änderungen an shared_buffers.
huge_page_size
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | 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 |
io_combine_limit
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | Grenzwert für die Größe von Datenlese- und Schreibvorgängen. |
| Datentyp | integer |
| Standardwert | 16 |
| Zulässige Werte | 1-128 |
| Parametertyp | dynamic |
| Dokumentation | io_combine_limit |
io_max_combine_limit
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | Server-weite Grenze, die io_combine_limit begrenzt. |
| Datentyp | integer |
| Standardwert | 16 |
| Zulässige Werte | 1-128 |
| Parametertyp | dynamic |
| Dokumentation | io_max_combine_limit |
io_max_concurrency
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | Maximale Anzahl von IOs, die ein Prozess gleichzeitig ausführen kann. |
| Datentyp | integer |
| Standardwert | 64 |
| Zulässige Werte | -1-1024 |
| Parametertyp | Statisch |
| Dokumentation | io_max_concurrency |
io_method
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | Wählt die Methode zum Ausführen asynchroner E/A-Vorgänge aus. |
| Datentyp | enumeration |
| Standardwert | worker |
| Zulässige Werte | worker,sync |
| Parametertyp | Statisch |
| Dokumentation | io_method |
io_workers
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | Anzahl der IO-Arbeitsprozesse für io_method=worker. |
| Datentyp | integer |
| Standardwert | 3 |
| Zulässige Werte | 1-32 |
| Parametertyp | dynamic |
| Dokumentation | io_workers |
logical_decoding_work_mem
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | Legt den maximalen Arbeitsspeicher fest, der für die logische Decodierung verwendet werden soll. Dieser Arbeitsspeicher kann von jedem internen Neuanordnungspuffer verwendet werden, bevor ein Überlauf auf den Datenträger erfolgt. |
| Datentyp | integer |
| Standardwert | 65536 |
| Zulässige Werte | 64-2147483647 |
| Parametertyp | dynamic |
| Dokumentation | logical_decoding_work_mem |
maintenance_work_mem
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | Legt den maximalen Arbeitsspeicher fest, der für Wartungsvorgänge verwendet werden soll. Dazu gehören Vorgänge wie VAKUUM und CREATE INDEX. |
| Datentyp | integer |
| Standardwert | Hängt von Ressourcen (virtuelle Kerne, RAM oder Speicherplatz) ab, die dem Server zugeordnet sind. |
| Zulässige Werte | 1024-2097151 |
| Parametertyp | dynamic |
| Dokumentation | maintenance_work_mem |
Description
maintenance_work_mem ist ein Konfigurationsparameter in PostgreSQL. Sie bestimmt die Menge des Arbeitsspeichers, der für Wartungsvorgänge 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 Aufgaben vorbehalten, die die Datenbankstruktur verwalten und optimieren.
! [HINWEIS] Das Festlegen
maintenance_work_memauf übermäßig aggressive Werte kann in regelmäßigen Abständen zu einem Speicherfehler im System führen. Es ist äußerst wichtig zu verstehen, wie viel Arbeitsspeicher auf dem Server verfügbar ist, und die Anzahl der gleichzeitigen Vorgänge, die Speicher für die zuvor beschriebenen Aufgaben zuweisen können, bevor Änderungen an diesem Parameter vorgenommen werden.
Wichtige Punkte
-
Speicherbegrenzung des Vakuums: Wenn Sie die Bereinigung von toten Tupeln beschleunigen möchten, indem Sie die
maintenance_work_memerhöhen, beachten Sie, dassVACUUMintegrierte Einschränkungen für das Sammeln von toten Tupel-IDs aufweist. Es kann nur bis zu 1 GB Arbeitsspeicher für diesen Prozess verwenden. -
Trennung des Speichers für autovacuum: Sie können die
autovacuum_work_memEinstellung verwenden, um den Speicher zu steuern, den autovacuum-Vorgänge unabhängig voneinander verwenden. 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 beeinträchtigen.
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.
Jedes Mal, wenn Sie das einer Instanz zugewiesene Produkt ändern, 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 | 99.328 KiB |
| 4 GiB | 157.696 KiB |
| 8 GiB | 216.064 KiB |
| 16 GiB | 274.432 KiB |
| 32GiB | 332.800 KiB |
| 48 GiB | 367.616 KiB |
| 64 GiB | 392.192 KiB |
| 80 GiB | 410.624 KiB |
| 128 GB | 450.560 KiB |
| 160 GiB | 468.992 KiB |
| 192 GiB | 484.352 KiB |
| 256 GiB | 508.928 KiB |
| 384 GiB | 542.720 KiB |
| 432 GiB | 552.960 KiB |
| 672 GiB | 590.848 KiB |
max_prepared_transactions
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | Legt die maximale Anzahl gleichzeitig vorbereiteter Transaktionen fest. |
| Datentyp | integer |
| Standardwert | 0 |
| Zulässige Werte | 0-262143 |
| Parametertyp | Statisch |
| Dokumentation | max_prepared_transactions |
max_stack_depth
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | 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
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | Die Menge des beim Start reservierten dynamischen gemeinsam genutzten Speichers. |
| Datentyp | integer |
| Standardwert | 0 |
| Zulässige Werte | 0 |
| Parametertyp | schreibgeschützt |
| Dokumentation | min_dynamic_shared_memory |
multixact_member_buffers
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | Legt die Größe des dedizierten Pufferpools fest, der für den MultiXact-Membercache verwendet wird. |
| Datentyp | integer |
| Standardwert | 32 |
| Zulässige Werte | 16-131072 |
| Parametertyp | Statisch |
| Dokumentation | multixact_member_buffers |
multixact_offset_buffers
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | Legt die Größe des dedizierten Pufferpools fest, der für den MultiXact-Offsetcache verwendet wird. |
| Datentyp | integer |
| Standardwert | 16 |
| Zulässige Werte | 16-131072 |
| Parametertyp | Statisch |
| Dokumentation | multixact_offset_buffers |
Benachrichtigungs-Puffer
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | Legt die Größe des dedizierten Pufferpools fest, der für den LISTEN/NOTIFY-Nachrichtencache verwendet wird. |
| Datentyp | integer |
| Standardwert | 16 |
| Zulässige Werte | 16-131072 |
| Parametertyp | Statisch |
| Dokumentation | notify_buffers |
serialisierbare Puffer
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | Legt die Größe des dedizierten Pufferpools fest, der für den serialisierbaren Transaktionscache verwendet wird. |
| Datentyp | integer |
| Standardwert | 32 |
| Zulässige Werte | 16-131072 |
| Parametertyp | Statisch |
| Dokumentation | serializable_buffers |
shared_buffers
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | Legt die Anzahl der vom Server verwendeten freigegebenen Speicherpuffer fest. |
| Datentyp | integer |
| Standardwert | Hängt von Ressourcen (virtuelle Kerne, RAM oder Speicherplatz) ab, die dem Server zugeordnet sind. |
| Zulässige Werte | 16-1073741823 |
| Parametertyp | Statisch |
| Dokumentation | shared_buffers |
Description
Der shared_buffers Konfigurationsparameter bestimmt die Menge des Systemspeichers, der der PostgreSQL-Datenbank zur Pufferung von Daten zugeordnet ist. Sie 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 zeitraubender Lesevorgang vom Datenträger wird umgangen. Geteilte Puffer dienen als Vermittler zwischen den Datenbankprozessen und dem Datenträger und verringern 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 shared_buffers Serverparameter dieser Instanz.
Jedes Mal, wenn Sie das einer Instanz zugewiesene Produkt ändern, 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 ist die Formel, die zum Berechnen des Werts shared_buffers verwendet wird memoryGib * 16384.
Bei virtuellen Computern mit mehr als 2 GiB ist 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 |
| 64 GiB | 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 |
Gemeinsamer_Speicher_Typ
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | Wählt die für den Hauptspeicherbereich gemeinsam genutzte Speicherimplementierung aus. |
| Datentyp | enumeration |
| Standardwert | mmap |
| Zulässige Werte | mmap |
| Parametertyp | schreibgeschützt |
| Dokumentation | geteilte_Speicherart |
subtransaction_buffers
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | Legt die Größe des dedizierten Pufferpools fest, der für den Untertransaktionscache verwendet wird. Geben Sie 0 an, damit dieser Wert als Bruchteil von shared_buffers bestimmt wird. |
| Datentyp | integer |
| Standardwert | 1024 |
| Zulässige Werte | 0-131072 |
| Parametertyp | Statisch |
| Dokumentation | subtransaction_buffers |
temporäre Puffer
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | Legt die maximale Anzahl temporärer Puffer fest, die von jeder Sitzung verwendet werden. |
| Datentyp | integer |
| Standardwert | 1024 |
| Zulässige Werte | 100-1073741823 |
| Parametertyp | dynamic |
| Dokumentation | temp_buffers |
Transaktionspuffer
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | Legt die Größe des dedizierten Pufferpools fest, der für den Transaktionsstatuscache verwendet wird. Geben Sie 0 an, damit dieser Wert als Bruchteil von shared_buffers bestimmt wird. |
| Datentyp | integer |
| Standardwert | 1024 |
| Zulässige Werte | 0-131072 |
| Parametertyp | Statisch |
| Dokumentation | Transaktionspuffer |
Vacuum-Puffer-Nutzungsgrenze
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | Legt die Pufferpoolgröße für VACUUM, ANALYZE und autovacuum fest |
| Datentyp | integer |
| Standardwert | 2048 |
| Zulässige Werte | 0-16777216 |
| Parametertyp | dynamic |
| Dokumentation | vacuum_buffer_usage_limit |
work_mem
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | Legt den maximalen Arbeitsspeicher fest, der für Abfragearbeitsbereiche verwendet werden soll. Dieser Arbeitsspeicher kann von den einzelnen internen Sortiervorgängen und Hashtabellen verwendet werden, bevor Sie zu temporären Datenträgerdateien wechseln. |
| Datentyp | integer |
| Standardwert | 4096 |
| Zulässige Werte | 4096-2097151 |
| Parametertyp | dynamic |
| Dokumentation | work_mem |
Description
Der work_mem Parameter 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 verringern, temporäre Daten auf den Datenträger zu schreiben.
Wichtige Punkte
-
Privater Verbindungsspeicher:
work_memist Teil des privaten Speichers, den jede Datenbanksitzung verwendet. Dieser Speicher unterscheidet sich von dem freigegebenen Speicherbereich, dershared_buffersverwendet wird. -
Abfragespezifische Verwendung: Nicht alle Sitzungen oder Abfragen verwenden
work_mem. Bei einfachen Abfragen wieSELECT 1ist es unwahrscheinlich, dass siework_membenötigen. Komplexere Abfragen mit Vorgängen wie Sortieren oder Hashing können jedoch einen oder mehrere Abschnitte vonwork_memnutzen. -
Parallele Vorgänge: Bei Abfragen, die mehrere parallele Back-Ends umfassen, kann jedes Back-End potenziell einen oder mehrere Abschnitte von
work_memverwenden.
Überwachung und Anpassung des Parameters work_mem
Es ist wichtig, die Leistung Ihres Systems kontinuierlich zu überwachen und bei Bedarf anzupassen work_mem , in erster Linie, wenn Abfrageausführungszeiten im Zusammenhang mit Sortier- oder Hashingvorgä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 der potenzielle Bedarf,
work_memzu erhöhen, besteht. - Anleitungen zur Problembehandlung: Verwenden Sie die Registerkarte "Hoch temporäre Dateien " in den Anleitungen zur Problembehandlung, um problematische Abfragen zu identifizieren.
Granulare Anpassung
Während Sie den work_mem Parameter verwalten, ist es oft effizienter, einen granularen Anpassungsansatz zu übernehmen, anstatt einen globalen Wert festzulegen. Dieser Ansatz stellt sicher, dass Sie den Speicher sorgfältig basierend auf den spezifischen Anforderungen der Prozesse und Benutzer allokieren. Außerdem wird das Risiko minimiert, dass Probleme mit nicht genügend Arbeitsspeicher auftreten. Hier erfahren Sie, wie Sie vorgehen können:
Benutzerebene: Wenn ein bestimmter Benutzer in erster Linie an Aggregations- oder Berichterstellungsaufgaben beteiligt ist, die arbeitsspeicherintensiv sind, sollten Sie den Wert für diesen
work_memBenutzer anpassen. Verwenden Sie denALTER ROLEBefehl, um die Leistung der Benutzervorgänge zu verbessern.Funktions-/Prozedurebene: Wenn bestimmte Funktionen oder Prozeduren erhebliche temporäre Dateien generieren, kann die Erhöhung des
work_memWerts auf der spezifischen Funktions- oder Prozedurebene von Vorteil sein. Verwenden Sie denALTER FUNCTION- oder denALTER PROCEDURE-Befehl, um diesen Vorgängen gezielt mehr Arbeitsspeicher zuzuweisen.Datenbankebene: Ändern sie
work_memauf Datenbankebene, wenn nur bestimmte Datenbanken eine hohe Anzahl temporärer Dateien generieren.Globales Niveau: Wenn eine Analyse Ihres Systems zeigt, dass die meisten Abfragen kleine temporäre Dateien erzeugen, während nur wenige große erzeugt werden, könnte es ratsam sein, den
work_memWert 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 sie den erhöhtenwork_memWert verarbeiten kann.
Bestimmen des minimalen work_mem Werts für Sortiervorgänge
Um den Minimalwert work_mem für eine bestimmte Abfrage zu ermitteln, insbesondere eines, das temporäre Datenträgerdateien während des Sortiervorgangs generiert, sollten Sie zunächst die temporäre Dateigröße berücksichtigen, die während der Abfrageausführung generiert wurde. Beispiel: Wenn eine Abfrage eine temporäre 20 MB-Datei generiert:
- Stellen Sie mithilfe von psql oder Ihrem bevorzugten PostgreSQL-Client eine Verbindung mit Ihrer Datenbank her.
- Legen Sie einen Anfangswert
work_memfest, der etwas höher als 20 MB ist, um zusätzliche Header bei der Verarbeitung im Arbeitsspeicher zu berücksichtigen. Verwenden Sie einen Befehl wie:SET work_mem TO '25MB'. - Führen Sie
EXPLAIN ANALYZEdie 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, erhöhen Sie denwork_memWert schrittweise und testen Sie erneut, bis"quicksort Memory"angezeigt wird. Das Auftreten von"quicksort Memory"signalisiert, 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
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | Legt den maximalen Arbeitsspeicher für die einzelnen Autovacuum-Arbeitsprozesse fest. |
| Datentyp | integer |
| Standardwert | -1 |
| Zulässige Werte | -1-2097151 |
| Parametertyp | dynamic |
| Dokumentation | autovacuum_work_mem |
commit_timestamp_buffers
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | Legt die Größe des dedizierten Pufferpools fest, der für den Commit-Zeitstempelcache verwendet wird. Geben Sie 0 an, damit dieser Wert als Bruchteil von shared_buffers bestimmt wird. |
| Datentyp | integer |
| Standardwert | 1024 |
| Zulässige Werte | 0-131072 |
| Parametertyp | Statisch |
| Dokumentation | commit_timestamp_buffers |
dynamischer_geteilt-Speicher_Typ
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | 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
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | Mehrfaches von work_mem, das für Hashtabellen verwendet werden soll. |
| Datentyp | NUMERIC |
| Standardwert | 2 |
| Zulässige Werte | 1-1000 |
| Parametertyp | dynamic |
| Dokumentation | hash_mem_multiplier |
huge_pages
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | Verwendung riesiger Seiten unter Linux oder Windows. |
| Datentyp | enumeration |
| Standardwert | try |
| Zulässige Werte | on,off,try |
| Parametertyp | Statisch |
| Dokumentation | huge_pages |
Description
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 riesiger Seiten kann Leistungsvorteile bieten, die 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 riesige Seiten nur für den freigegebenen Speicherbereich verwenden. Ein erheblicher Teil des gemeinsamen Speicherbereichs wird für geteilte Puffer zugewiesen.
Ein weiterer Vorteil besteht darin, dass große Seiten den Austausch des freigegebenen Speicherbereichs auf den Datenträger verhindern, wodurch die Leistung weiter stabilisiert wird.
Recommendations
- 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 sie erwarten, dass sie auf einen Server skaliert werden, der dies tut, behalten Sie die
huge_pagesEinstellungTRYfür einen nahtlosen Übergang und eine optimale Leistung bei.
Azure-spezifische Hinweise
Für Server mit vier oder mehr vCores werden riesige Seiten automatisch vom zugrunde liegenden Betriebssystem zugeordnet. Das Feature ist für Server mit weniger als vier vCores nicht verfügbar. Die Anzahl der riesigen Seiten wird automatisch angepasst, wenn alle Einstellungen für gemeinsam genutzten Speicher geändert werden, einschließlich Änderungen an shared_buffers.
huge_page_size
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | 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 |
io_combine_limit
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | Grenzwert für die Größe von Datenlese- und Schreibvorgängen. |
| Datentyp | integer |
| Standardwert | 16 |
| Zulässige Werte | 16 |
| Parametertyp | schreibgeschützt |
| Dokumentation | io_combine_limit |
logical_decoding_work_mem
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | Legt den maximalen Arbeitsspeicher fest, der für die logische Decodierung verwendet werden soll. Dieser Arbeitsspeicher kann von jedem internen Neuanordnungspuffer verwendet werden, bevor ein Überlauf auf den Datenträger erfolgt. |
| Datentyp | integer |
| Standardwert | 65536 |
| Zulässige Werte | 64-2147483647 |
| Parametertyp | dynamic |
| Dokumentation | logical_decoding_work_mem |
maintenance_work_mem
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | Legt den maximalen Arbeitsspeicher fest, der für Wartungsvorgänge verwendet werden soll. Dazu gehören Vorgänge wie VAKUUM und CREATE INDEX. |
| Datentyp | integer |
| Standardwert | Hängt von Ressourcen (virtuelle Kerne, RAM oder Speicherplatz) ab, die dem Server zugeordnet sind. |
| Zulässige Werte | 1024-2097151 |
| Parametertyp | dynamic |
| Dokumentation | maintenance_work_mem |
Description
maintenance_work_mem ist ein Konfigurationsparameter in PostgreSQL. Sie bestimmt die Menge des Arbeitsspeichers, der für Wartungsvorgänge 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 Aufgaben vorbehalten, die die Datenbankstruktur verwalten und optimieren.
! [HINWEIS] Das Festlegen
maintenance_work_memauf übermäßig aggressive Werte kann in regelmäßigen Abständen zu einem Speicherfehler im System führen. Es ist äußerst wichtig zu verstehen, wie viel Arbeitsspeicher auf dem Server verfügbar ist, und die Anzahl der gleichzeitigen Vorgänge, die Speicher für die zuvor beschriebenen Aufgaben zuweisen können, bevor Änderungen an diesem Parameter vorgenommen werden.
Wichtige Punkte
-
Speicherbegrenzung des Vakuums: Wenn Sie die Bereinigung von toten Tupeln beschleunigen möchten, indem Sie die
maintenance_work_memerhöhen, beachten Sie, dassVACUUMintegrierte Einschränkungen für das Sammeln von toten Tupel-IDs aufweist. Es kann nur bis zu 1 GB Arbeitsspeicher für diesen Prozess verwenden. -
Trennung des Speichers für autovacuum: Sie können die
autovacuum_work_memEinstellung verwenden, um den Speicher zu steuern, den autovacuum-Vorgänge unabhängig voneinander verwenden. 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 beeinträchtigen.
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.
Jedes Mal, wenn Sie das einer Instanz zugewiesene Produkt ändern, 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 | 99.328 KiB |
| 4 GiB | 157.696 KiB |
| 8 GiB | 216.064 KiB |
| 16 GiB | 274.432 KiB |
| 32GiB | 332.800 KiB |
| 48 GiB | 367.616 KiB |
| 64 GiB | 392.192 KiB |
| 80 GiB | 410.624 KiB |
| 128 GB | 450.560 KiB |
| 160 GiB | 468.992 KiB |
| 192 GiB | 484.352 KiB |
| 256 GiB | 508.928 KiB |
| 384 GiB | 542.720 KiB |
| 432 GiB | 552.960 KiB |
| 672 GiB | 590.848 KiB |
max_prepared_transactions
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | Legt die maximale Anzahl gleichzeitig vorbereiteter Transaktionen fest. |
| Datentyp | integer |
| Standardwert | 0 |
| Zulässige Werte | 0-262143 |
| Parametertyp | Statisch |
| Dokumentation | max_prepared_transactions |
max_stack_depth
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | 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
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | Die Menge des beim Start reservierten dynamischen gemeinsam genutzten Speichers. |
| Datentyp | integer |
| Standardwert | 0 |
| Zulässige Werte | 0 |
| Parametertyp | schreibgeschützt |
| Dokumentation | min_dynamic_shared_memory |
multixact_member_buffers
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | Legt die Größe des dedizierten Pufferpools fest, der für den MultiXact-Membercache verwendet wird. |
| Datentyp | integer |
| Standardwert | 32 |
| Zulässige Werte | 16-131072 |
| Parametertyp | Statisch |
| Dokumentation | multixact_member_buffers |
multixact_offset_buffers
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | Legt die Größe des dedizierten Pufferpools fest, der für den MultiXact-Offsetcache verwendet wird. |
| Datentyp | integer |
| Standardwert | 16 |
| Zulässige Werte | 16-131072 |
| Parametertyp | Statisch |
| Dokumentation | multixact_offset_buffers |
Benachrichtigungs-Puffer
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | Legt die Größe des dedizierten Pufferpools fest, der für den LISTEN/NOTIFY-Nachrichtencache verwendet wird. |
| Datentyp | integer |
| Standardwert | 16 |
| Zulässige Werte | 16-131072 |
| Parametertyp | Statisch |
| Dokumentation | notify_buffers |
serialisierbare Puffer
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | Legt die Größe des dedizierten Pufferpools fest, der für den serialisierbaren Transaktionscache verwendet wird. |
| Datentyp | integer |
| Standardwert | 32 |
| Zulässige Werte | 16-131072 |
| Parametertyp | Statisch |
| Dokumentation | serializable_buffers |
shared_buffers
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | Legt die Anzahl der vom Server verwendeten freigegebenen Speicherpuffer fest. |
| Datentyp | integer |
| Standardwert | Hängt von Ressourcen (virtuelle Kerne, RAM oder Speicherplatz) ab, die dem Server zugeordnet sind. |
| Zulässige Werte | 16-1073741823 |
| Parametertyp | Statisch |
| Dokumentation | shared_buffers |
Description
Der shared_buffers Konfigurationsparameter bestimmt die Menge des Systemspeichers, der der PostgreSQL-Datenbank zur Pufferung von Daten zugeordnet ist. Sie 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 zeitraubender Lesevorgang vom Datenträger wird umgangen. Geteilte Puffer dienen als Vermittler zwischen den Datenbankprozessen und dem Datenträger und verringern 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 shared_buffers Serverparameter dieser Instanz.
Jedes Mal, wenn Sie das einer Instanz zugewiesene Produkt ändern, 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 ist die Formel, die zum Berechnen des Werts shared_buffers verwendet wird memoryGib * 16384.
Bei virtuellen Computern mit mehr als 2 GiB ist 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 |
| 64 GiB | 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 |
Gemeinsamer_Speicher_Typ
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | Wählt die für den Hauptspeicherbereich gemeinsam genutzte Speicherimplementierung aus. |
| Datentyp | enumeration |
| Standardwert | mmap |
| Zulässige Werte | mmap |
| Parametertyp | schreibgeschützt |
| Dokumentation | geteilte_Speicherart |
subtransaction_buffers
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | Legt die Größe des dedizierten Pufferpools fest, der für den Untertransaktionscache verwendet wird. Geben Sie 0 an, damit dieser Wert als Bruchteil von shared_buffers bestimmt wird. |
| Datentyp | integer |
| Standardwert | 1024 |
| Zulässige Werte | 0-131072 |
| Parametertyp | Statisch |
| Dokumentation | subtransaction_buffers |
temporäre Puffer
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | Legt die maximale Anzahl temporärer Puffer fest, die von jeder Sitzung verwendet werden. |
| Datentyp | integer |
| Standardwert | 1024 |
| Zulässige Werte | 100-1073741823 |
| Parametertyp | dynamic |
| Dokumentation | temp_buffers |
Transaktionspuffer
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | Legt die Größe des dedizierten Pufferpools fest, der für den Transaktionsstatuscache verwendet wird. Geben Sie 0 an, damit dieser Wert als Bruchteil von shared_buffers bestimmt wird. |
| Datentyp | integer |
| Standardwert | 1024 |
| Zulässige Werte | 0-131072 |
| Parametertyp | Statisch |
| Dokumentation | Transaktionspuffer |
Vacuum-Puffer-Nutzungsgrenze
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | Legt die Pufferpoolgröße für VACUUM, ANALYZE und autovacuum fest |
| Datentyp | integer |
| Standardwert | 2048 |
| Zulässige Werte | 0-16777216 |
| Parametertyp | dynamic |
| Dokumentation | vacuum_buffer_usage_limit |
work_mem
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | Legt den maximalen Arbeitsspeicher fest, der für Abfragearbeitsbereiche verwendet werden soll. Dieser Arbeitsspeicher kann von den einzelnen internen Sortiervorgängen und Hashtabellen verwendet werden, bevor Sie zu temporären Datenträgerdateien wechseln. |
| Datentyp | integer |
| Standardwert | 4096 |
| Zulässige Werte | 4096-2097151 |
| Parametertyp | dynamic |
| Dokumentation | work_mem |
Description
Der work_mem Parameter 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 verringern, temporäre Daten auf den Datenträger zu schreiben.
Wichtige Punkte
-
Privater Verbindungsspeicher:
work_memist Teil des privaten Speichers, den jede Datenbanksitzung verwendet. Dieser Speicher unterscheidet sich von dem freigegebenen Speicherbereich, dershared_buffersverwendet wird. -
Abfragespezifische Verwendung: Nicht alle Sitzungen oder Abfragen verwenden
work_mem. Bei einfachen Abfragen wieSELECT 1ist es unwahrscheinlich, dass siework_membenötigen. Komplexere Abfragen mit Vorgängen wie Sortieren oder Hashing können jedoch einen oder mehrere Abschnitte vonwork_memnutzen. -
Parallele Vorgänge: Bei Abfragen, die mehrere parallele Back-Ends umfassen, kann jedes Back-End potenziell einen oder mehrere Abschnitte von
work_memverwenden.
Überwachung und Anpassung des Parameters work_mem
Es ist wichtig, die Leistung Ihres Systems kontinuierlich zu überwachen und bei Bedarf anzupassen work_mem , in erster Linie, wenn Abfrageausführungszeiten im Zusammenhang mit Sortier- oder Hashingvorgä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 der potenzielle Bedarf,
work_memzu erhöhen, besteht. - Anleitungen zur Problembehandlung: Verwenden Sie die Registerkarte "Hoch temporäre Dateien " in den Anleitungen zur Problembehandlung, um problematische Abfragen zu identifizieren.
Granulare Anpassung
Während Sie den work_mem Parameter verwalten, ist es oft effizienter, einen granularen Anpassungsansatz zu übernehmen, anstatt einen globalen Wert festzulegen. Dieser Ansatz stellt sicher, dass Sie den Speicher sorgfältig basierend auf den spezifischen Anforderungen der Prozesse und Benutzer allokieren. Außerdem wird das Risiko minimiert, dass Probleme mit nicht genügend Arbeitsspeicher auftreten. Hier erfahren Sie, wie Sie vorgehen können:
Benutzerebene: Wenn ein bestimmter Benutzer in erster Linie an Aggregations- oder Berichterstellungsaufgaben beteiligt ist, die arbeitsspeicherintensiv sind, sollten Sie den Wert für diesen
work_memBenutzer anpassen. Verwenden Sie denALTER ROLEBefehl, um die Leistung der Benutzervorgänge zu verbessern.Funktions-/Prozedurebene: Wenn bestimmte Funktionen oder Prozeduren erhebliche temporäre Dateien generieren, kann die Erhöhung des
work_memWerts auf der spezifischen Funktions- oder Prozedurebene von Vorteil sein. Verwenden Sie denALTER FUNCTION- oder denALTER PROCEDURE-Befehl, um diesen Vorgängen gezielt mehr Arbeitsspeicher zuzuweisen.Datenbankebene: Ändern sie
work_memauf Datenbankebene, wenn nur bestimmte Datenbanken eine hohe Anzahl temporärer Dateien generieren.Globales Niveau: Wenn eine Analyse Ihres Systems zeigt, dass die meisten Abfragen kleine temporäre Dateien erzeugen, während nur wenige große erzeugt werden, könnte es ratsam sein, den
work_memWert 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 sie den erhöhtenwork_memWert verarbeiten kann.
Bestimmen des minimalen work_mem Werts für Sortiervorgänge
Um den Minimalwert work_mem für eine bestimmte Abfrage zu ermitteln, insbesondere eines, das temporäre Datenträgerdateien während des Sortiervorgangs generiert, sollten Sie zunächst die temporäre Dateigröße berücksichtigen, die während der Abfrageausführung generiert wurde. Beispiel: Wenn eine Abfrage eine temporäre 20 MB-Datei generiert:
- Stellen Sie mithilfe von psql oder Ihrem bevorzugten PostgreSQL-Client eine Verbindung mit Ihrer Datenbank her.
- Legen Sie einen Anfangswert
work_memfest, der etwas höher als 20 MB ist, um zusätzliche Header bei der Verarbeitung im Arbeitsspeicher zu berücksichtigen. Verwenden Sie einen Befehl wie:SET work_mem TO '25MB'. - Führen Sie
EXPLAIN ANALYZEdie 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, erhöhen Sie denwork_memWert schrittweise und testen Sie erneut, bis"quicksort Memory"angezeigt wird. Das Auftreten von"quicksort Memory"signalisiert, 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
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | Legt den maximalen Arbeitsspeicher für die einzelnen Autovacuum-Arbeitsprozesse fest. |
| Datentyp | integer |
| Standardwert | -1 |
| Zulässige Werte | -1-2097151 |
| Parametertyp | dynamic |
| Dokumentation | autovacuum_work_mem |
dynamischer_geteilt-Speicher_Typ
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | 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
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | Mehrfaches von work_mem, das für Hashtabellen verwendet werden soll. |
| Datentyp | NUMERIC |
| Standardwert | 2 |
| Zulässige Werte | 1-1000 |
| Parametertyp | dynamic |
| Dokumentation | hash_mem_multiplier |
huge_pages
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | 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 | Statisch |
| Dokumentation | huge_pages |
Description
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 riesiger Seiten kann Leistungsvorteile bieten, die 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 riesige Seiten nur für den freigegebenen Speicherbereich verwenden. Ein erheblicher Teil des gemeinsamen Speicherbereichs wird für geteilte Puffer zugewiesen.
Ein weiterer Vorteil besteht darin, dass große Seiten den Austausch des freigegebenen Speicherbereichs auf den Datenträger verhindern, wodurch die Leistung weiter stabilisiert wird.
Recommendations
- 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 sie erwarten, dass sie auf einen Server skaliert werden, der dies tut, behalten Sie die
huge_pagesEinstellungTRYfür einen nahtlosen Übergang und eine optimale Leistung bei.
Azure-spezifische Hinweise
Für Server mit vier oder mehr vCores werden riesige Seiten automatisch vom zugrunde liegenden Betriebssystem zugeordnet. Das Feature ist für Server mit weniger als vier vCores nicht verfügbar. Die Anzahl der riesigen Seiten wird automatisch angepasst, wenn alle Einstellungen für gemeinsam genutzten Speicher geändert werden, einschließlich Änderungen an shared_buffers.
huge_page_size
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | 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
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | Legt den maximalen Arbeitsspeicher fest, der für die logische Decodierung verwendet werden soll. |
| Datentyp | integer |
| Standardwert | 65536 |
| Zulässige Werte | 64-2147483647 |
| Parametertyp | dynamic |
| Dokumentation | logical_decoding_work_mem |
maintenance_work_mem
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | 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 | dynamic |
| Dokumentation | maintenance_work_mem |
Description
maintenance_work_mem ist ein Konfigurationsparameter in PostgreSQL. Sie bestimmt die Menge des Arbeitsspeichers, der für Wartungsvorgänge 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 Aufgaben vorbehalten, die die Datenbankstruktur verwalten und optimieren.
! [HINWEIS] Das Festlegen
maintenance_work_memauf übermäßig aggressive Werte kann in regelmäßigen Abständen zu einem Speicherfehler im System führen. Es ist äußerst wichtig zu verstehen, wie viel Arbeitsspeicher auf dem Server verfügbar ist, und die Anzahl der gleichzeitigen Vorgänge, die Speicher für die zuvor beschriebenen Aufgaben zuweisen können, bevor Änderungen an diesem Parameter vorgenommen werden.
Wichtige Punkte
-
Speicherbegrenzung des Vakuums: Wenn Sie die Bereinigung von toten Tupeln beschleunigen möchten, indem Sie die
maintenance_work_memerhöhen, beachten Sie, dassVACUUMintegrierte Einschränkungen für das Sammeln von toten Tupel-IDs aufweist. Es kann nur bis zu 1 GB Arbeitsspeicher für diesen Prozess verwenden. -
Trennung des Speichers für autovacuum: Sie können die
autovacuum_work_memEinstellung verwenden, um den Speicher zu steuern, den autovacuum-Vorgänge unabhängig voneinander verwenden. 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 beeinträchtigen.
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.
Jedes Mal, wenn Sie das einer Instanz zugewiesene Produkt ändern, 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 | 99.328 KiB |
| 4 GiB | 157.696 KiB |
| 8 GiB | 216.064 KiB |
| 16 GiB | 274.432 KiB |
| 32GiB | 332.800 KiB |
| 48 GiB | 367.616 KiB |
| 64 GiB | 392.192 KiB |
| 80 GiB | 410.624 KiB |
| 128 GB | 450.560 KiB |
| 160 GiB | 468.992 KiB |
| 192 GiB | 484.352 KiB |
| 256 GiB | 508.928 KiB |
| 384 GiB | 542.720 KiB |
| 432 GiB | 552.960 KiB |
| 672 GiB | 590.848 KiB |
max_prepared_transactions
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | 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 | Statisch |
| Dokumentation | max_prepared_transactions |
max_stack_depth
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | 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
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | Die Menge des beim Start reservierten dynamischen gemeinsam genutzten Speichers. |
| Datentyp | integer |
| Standardwert | 0 |
| Zulässige Werte | 0 |
| Parametertyp | schreibgeschützt |
| Dokumentation | min_dynamic_shared_memory |
shared_buffers
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | 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 | Statisch |
| Dokumentation | shared_buffers |
Description
Der shared_buffers Konfigurationsparameter bestimmt die Menge des Systemspeichers, der der PostgreSQL-Datenbank zur Pufferung von Daten zugeordnet ist. Sie 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 zeitraubender Lesevorgang vom Datenträger wird umgangen. Geteilte Puffer dienen als Vermittler zwischen den Datenbankprozessen und dem Datenträger und verringern 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 shared_buffers Serverparameter dieser Instanz.
Jedes Mal, wenn Sie das einer Instanz zugewiesene Produkt ändern, 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 ist die Formel, die zum Berechnen des Werts shared_buffers verwendet wird memoryGib * 16384.
Bei virtuellen Computern mit mehr als 2 GiB ist 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 |
| 64 GiB | 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 |
Gemeinsamer_Speicher_Typ
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | Wählt die für den Hauptspeicherbereich gemeinsam genutzte Speicherimplementierung aus. |
| Datentyp | enumeration |
| Standardwert | mmap |
| Zulässige Werte | mmap |
| Parametertyp | schreibgeschützt |
| Dokumentation | geteilte_Speicherart |
temporäre Puffer
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | 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 | dynamic |
| Dokumentation | temp_buffers |
Vacuum-Puffer-Nutzungsgrenze
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | Legt die Pufferpoolgröße für VACUUM, ANALYZE und autovacuum fest |
| Datentyp | integer |
| Standardwert | 256 |
| Zulässige Werte | 0-16777216 |
| Parametertyp | dynamic |
| Dokumentation | vacuum_buffer_usage_limit |
work_mem
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | 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 | dynamic |
| Dokumentation | work_mem |
Description
Der work_mem Parameter 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 verringern, temporäre Daten auf den Datenträger zu schreiben.
Wichtige Punkte
-
Privater Verbindungsspeicher:
work_memist Teil des privaten Speichers, den jede Datenbanksitzung verwendet. Dieser Speicher unterscheidet sich von dem freigegebenen Speicherbereich, dershared_buffersverwendet wird. -
Abfragespezifische Verwendung: Nicht alle Sitzungen oder Abfragen verwenden
work_mem. Bei einfachen Abfragen wieSELECT 1ist es unwahrscheinlich, dass siework_membenötigen. Komplexere Abfragen mit Vorgängen wie Sortieren oder Hashing können jedoch einen oder mehrere Abschnitte vonwork_memnutzen. -
Parallele Vorgänge: Bei Abfragen, die mehrere parallele Back-Ends umfassen, kann jedes Back-End potenziell einen oder mehrere Abschnitte von
work_memverwenden.
Überwachung und Anpassung des Parameters work_mem
Es ist wichtig, die Leistung Ihres Systems kontinuierlich zu überwachen und bei Bedarf anzupassen work_mem , in erster Linie, wenn Abfrageausführungszeiten im Zusammenhang mit Sortier- oder Hashingvorgä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 der potenzielle Bedarf,
work_memzu erhöhen, besteht. - Anleitungen zur Problembehandlung: Verwenden Sie die Registerkarte "Hoch temporäre Dateien " in den Anleitungen zur Problembehandlung, um problematische Abfragen zu identifizieren.
Granulare Anpassung
Während Sie den work_mem Parameter verwalten, ist es oft effizienter, einen granularen Anpassungsansatz zu übernehmen, anstatt einen globalen Wert festzulegen. Dieser Ansatz stellt sicher, dass Sie den Speicher sorgfältig basierend auf den spezifischen Anforderungen der Prozesse und Benutzer allokieren. Außerdem wird das Risiko minimiert, dass Probleme mit nicht genügend Arbeitsspeicher auftreten. Hier erfahren Sie, wie Sie vorgehen können:
Benutzerebene: Wenn ein bestimmter Benutzer in erster Linie an Aggregations- oder Berichterstellungsaufgaben beteiligt ist, die arbeitsspeicherintensiv sind, sollten Sie den Wert für diesen
work_memBenutzer anpassen. Verwenden Sie denALTER ROLEBefehl, um die Leistung der Benutzervorgänge zu verbessern.Funktions-/Prozedurebene: Wenn bestimmte Funktionen oder Prozeduren erhebliche temporäre Dateien generieren, kann die Erhöhung des
work_memWerts auf der spezifischen Funktions- oder Prozedurebene von Vorteil sein. Verwenden Sie denALTER FUNCTION- oder denALTER PROCEDURE-Befehl, um diesen Vorgängen gezielt mehr Arbeitsspeicher zuzuweisen.Datenbankebene: Ändern sie
work_memauf Datenbankebene, wenn nur bestimmte Datenbanken eine hohe Anzahl temporärer Dateien generieren.Globales Niveau: Wenn eine Analyse Ihres Systems zeigt, dass die meisten Abfragen kleine temporäre Dateien erzeugen, während nur wenige große erzeugt werden, könnte es ratsam sein, den
work_memWert 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 sie den erhöhtenwork_memWert verarbeiten kann.
Bestimmen des minimalen work_mem Werts für Sortiervorgänge
Um den Minimalwert work_mem für eine bestimmte Abfrage zu ermitteln, insbesondere eines, das temporäre Datenträgerdateien während des Sortiervorgangs generiert, sollten Sie zunächst die temporäre Dateigröße berücksichtigen, die während der Abfrageausführung generiert wurde. Beispiel: Wenn eine Abfrage eine temporäre 20 MB-Datei generiert:
- Stellen Sie mithilfe von psql oder Ihrem bevorzugten PostgreSQL-Client eine Verbindung mit Ihrer Datenbank her.
- Legen Sie einen Anfangswert
work_memfest, der etwas höher als 20 MB ist, um zusätzliche Header bei der Verarbeitung im Arbeitsspeicher zu berücksichtigen. Verwenden Sie einen Befehl wie:SET work_mem TO '25MB'. - Führen Sie
EXPLAIN ANALYZEdie 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, erhöhen Sie denwork_memWert schrittweise und testen Sie erneut, bis"quicksort Memory"angezeigt wird. Das Auftreten von"quicksort Memory"signalisiert, 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
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | Legt den maximalen Arbeitsspeicher für die einzelnen Autovacuum-Arbeitsprozesse fest. |
| Datentyp | integer |
| Standardwert | -1 |
| Zulässige Werte | -1-2097151 |
| Parametertyp | dynamic |
| Dokumentation | autovacuum_work_mem |
dynamischer_geteilt-Speicher_Typ
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | 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
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | Mehrfaches von work_mem, das für Hashtabellen verwendet werden soll. |
| Datentyp | NUMERIC |
| Standardwert | 2 |
| Zulässige Werte | 1-1000 |
| Parametertyp | dynamic |
| Dokumentation | hash_mem_multiplier |
huge_pages
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | 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 | Statisch |
| Dokumentation | huge_pages |
Description
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 riesiger Seiten kann Leistungsvorteile bieten, die 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 riesige Seiten nur für den freigegebenen Speicherbereich verwenden. Ein erheblicher Teil des gemeinsamen Speicherbereichs wird für geteilte Puffer zugewiesen.
Ein weiterer Vorteil besteht darin, dass große Seiten den Austausch des freigegebenen Speicherbereichs auf den Datenträger verhindern, wodurch die Leistung weiter stabilisiert wird.
Recommendations
- 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 sie erwarten, dass sie auf einen Server skaliert werden, der dies tut, behalten Sie die
huge_pagesEinstellungTRYfür einen nahtlosen Übergang und eine optimale Leistung bei.
Azure-spezifische Hinweise
Für Server mit vier oder mehr vCores werden riesige Seiten automatisch vom zugrunde liegenden Betriebssystem zugeordnet. Das Feature ist für Server mit weniger als vier vCores nicht verfügbar. Die Anzahl der riesigen Seiten wird automatisch angepasst, wenn alle Einstellungen für gemeinsam genutzten Speicher geändert werden, einschließlich Änderungen an shared_buffers.
huge_page_size
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | 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
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | Legt den maximalen Arbeitsspeicher fest, der für die logische Decodierung verwendet werden soll. |
| Datentyp | integer |
| Standardwert | 65536 |
| Zulässige Werte | 64-2147483647 |
| Parametertyp | dynamic |
| Dokumentation | logical_decoding_work_mem |
maintenance_work_mem
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | 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 | dynamic |
| Dokumentation | maintenance_work_mem |
Description
maintenance_work_mem ist ein Konfigurationsparameter in PostgreSQL. Sie bestimmt die Menge des Arbeitsspeichers, der für Wartungsvorgänge 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 Aufgaben vorbehalten, die die Datenbankstruktur verwalten und optimieren.
! [HINWEIS] Das Festlegen
maintenance_work_memauf übermäßig aggressive Werte kann in regelmäßigen Abständen zu einem Speicherfehler im System führen. Es ist äußerst wichtig zu verstehen, wie viel Arbeitsspeicher auf dem Server verfügbar ist, und die Anzahl der gleichzeitigen Vorgänge, die Speicher für die zuvor beschriebenen Aufgaben zuweisen können, bevor Änderungen an diesem Parameter vorgenommen werden.
Wichtige Punkte
-
Speicherbegrenzung des Vakuums: Wenn Sie die Bereinigung von toten Tupeln beschleunigen möchten, indem Sie die
maintenance_work_memerhöhen, beachten Sie, dassVACUUMintegrierte Einschränkungen für das Sammeln von toten Tupel-IDs aufweist. Es kann nur bis zu 1 GB Arbeitsspeicher für diesen Prozess verwenden. -
Trennung des Speichers für autovacuum: Sie können die
autovacuum_work_memEinstellung verwenden, um den Speicher zu steuern, den autovacuum-Vorgänge unabhängig voneinander verwenden. 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 beeinträchtigen.
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.
Jedes Mal, wenn Sie das einer Instanz zugewiesene Produkt ändern, 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 | 99.328 KiB |
| 4 GiB | 157.696 KiB |
| 8 GiB | 216.064 KiB |
| 16 GiB | 274.432 KiB |
| 32GiB | 332.800 KiB |
| 48 GiB | 367.616 KiB |
| 64 GiB | 392.192 KiB |
| 80 GiB | 410.624 KiB |
| 128 GB | 450.560 KiB |
| 160 GiB | 468.992 KiB |
| 192 GiB | 484.352 KiB |
| 256 GiB | 508.928 KiB |
| 384 GiB | 542.720 KiB |
| 432 GiB | 552.960 KiB |
| 672 GiB | 590.848 KiB |
max_prepared_transactions
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | 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 | Statisch |
| Dokumentation | max_prepared_transactions |
max_stack_depth
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | 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
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | Die Menge des beim Start reservierten dynamischen gemeinsam genutzten Speichers. |
| Datentyp | integer |
| Standardwert | 0 |
| Zulässige Werte | 0 |
| Parametertyp | schreibgeschützt |
| Dokumentation | min_dynamic_shared_memory |
shared_buffers
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | 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 | Statisch |
| Dokumentation | shared_buffers |
Description
Der shared_buffers Konfigurationsparameter bestimmt die Menge des Systemspeichers, der der PostgreSQL-Datenbank zur Pufferung von Daten zugeordnet ist. Sie 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 zeitraubender Lesevorgang vom Datenträger wird umgangen. Geteilte Puffer dienen als Vermittler zwischen den Datenbankprozessen und dem Datenträger und verringern 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 shared_buffers Serverparameter dieser Instanz.
Jedes Mal, wenn Sie das einer Instanz zugewiesene Produkt ändern, 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 ist die Formel, die zum Berechnen des Werts shared_buffers verwendet wird memoryGib * 16384.
Bei virtuellen Computern mit mehr als 2 GiB ist 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 |
| 64 GiB | 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 |
Gemeinsamer_Speicher_Typ
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | Wählt die für den Hauptspeicherbereich gemeinsam genutzte Speicherimplementierung aus. |
| Datentyp | enumeration |
| Standardwert | mmap |
| Zulässige Werte | mmap |
| Parametertyp | schreibgeschützt |
| Dokumentation | geteilte_Speicherart |
temporäre Puffer
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | 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 | dynamic |
| Dokumentation | temp_buffers |
work_mem
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | 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 | dynamic |
| Dokumentation | work_mem |
Description
Der work_mem Parameter 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 verringern, temporäre Daten auf den Datenträger zu schreiben.
Wichtige Punkte
-
Privater Verbindungsspeicher:
work_memist Teil des privaten Speichers, den jede Datenbanksitzung verwendet. Dieser Speicher unterscheidet sich von dem freigegebenen Speicherbereich, dershared_buffersverwendet wird. -
Abfragespezifische Verwendung: Nicht alle Sitzungen oder Abfragen verwenden
work_mem. Bei einfachen Abfragen wieSELECT 1ist es unwahrscheinlich, dass siework_membenötigen. Komplexere Abfragen mit Vorgängen wie Sortieren oder Hashing können jedoch einen oder mehrere Abschnitte vonwork_memnutzen. -
Parallele Vorgänge: Bei Abfragen, die mehrere parallele Back-Ends umfassen, kann jedes Back-End potenziell einen oder mehrere Abschnitte von
work_memverwenden.
Überwachung und Anpassung des Parameters work_mem
Es ist wichtig, die Leistung Ihres Systems kontinuierlich zu überwachen und bei Bedarf anzupassen work_mem , in erster Linie, wenn Abfrageausführungszeiten im Zusammenhang mit Sortier- oder Hashingvorgä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 der potenzielle Bedarf,
work_memzu erhöhen, besteht. - Anleitungen zur Problembehandlung: Verwenden Sie die Registerkarte "Hoch temporäre Dateien " in den Anleitungen zur Problembehandlung, um problematische Abfragen zu identifizieren.
Granulare Anpassung
Während Sie den work_mem Parameter verwalten, ist es oft effizienter, einen granularen Anpassungsansatz zu übernehmen, anstatt einen globalen Wert festzulegen. Dieser Ansatz stellt sicher, dass Sie den Speicher sorgfältig basierend auf den spezifischen Anforderungen der Prozesse und Benutzer allokieren. Außerdem wird das Risiko minimiert, dass Probleme mit nicht genügend Arbeitsspeicher auftreten. Hier erfahren Sie, wie Sie vorgehen können:
Benutzerebene: Wenn ein bestimmter Benutzer in erster Linie an Aggregations- oder Berichterstellungsaufgaben beteiligt ist, die arbeitsspeicherintensiv sind, sollten Sie den Wert für diesen
work_memBenutzer anpassen. Verwenden Sie denALTER ROLEBefehl, um die Leistung der Benutzervorgänge zu verbessern.Funktions-/Prozedurebene: Wenn bestimmte Funktionen oder Prozeduren erhebliche temporäre Dateien generieren, kann die Erhöhung des
work_memWerts auf der spezifischen Funktions- oder Prozedurebene von Vorteil sein. Verwenden Sie denALTER FUNCTION- oder denALTER PROCEDURE-Befehl, um diesen Vorgängen gezielt mehr Arbeitsspeicher zuzuweisen.Datenbankebene: Ändern sie
work_memauf Datenbankebene, wenn nur bestimmte Datenbanken eine hohe Anzahl temporärer Dateien generieren.Globales Niveau: Wenn eine Analyse Ihres Systems zeigt, dass die meisten Abfragen kleine temporäre Dateien erzeugen, während nur wenige große erzeugt werden, könnte es ratsam sein, den
work_memWert 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 sie den erhöhtenwork_memWert verarbeiten kann.
Bestimmen des minimalen work_mem Werts für Sortiervorgänge
Um den Minimalwert work_mem für eine bestimmte Abfrage zu ermitteln, insbesondere eines, das temporäre Datenträgerdateien während des Sortiervorgangs generiert, sollten Sie zunächst die temporäre Dateigröße berücksichtigen, die während der Abfrageausführung generiert wurde. Beispiel: Wenn eine Abfrage eine temporäre 20 MB-Datei generiert:
- Stellen Sie mithilfe von psql oder Ihrem bevorzugten PostgreSQL-Client eine Verbindung mit Ihrer Datenbank her.
- Legen Sie einen Anfangswert
work_memfest, der etwas höher als 20 MB ist, um zusätzliche Header bei der Verarbeitung im Arbeitsspeicher zu berücksichtigen. Verwenden Sie einen Befehl wie:SET work_mem TO '25MB'. - Führen Sie
EXPLAIN ANALYZEdie 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, erhöhen Sie denwork_memWert schrittweise und testen Sie erneut, bis"quicksort Memory"angezeigt wird. Das Auftreten von"quicksort Memory"signalisiert, 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
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | Legt den maximalen Arbeitsspeicher für die einzelnen Autovacuum-Arbeitsprozesse fest. |
| Datentyp | integer |
| Standardwert | -1 |
| Zulässige Werte | -1-2097151 |
| Parametertyp | dynamic |
| Dokumentation | autovacuum_work_mem |
dynamischer_geteilt-Speicher_Typ
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | 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
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | Mehrfaches von work_mem, das für Hashtabellen verwendet werden soll. |
| Datentyp | NUMERIC |
| Standardwert | 1 |
| Zulässige Werte | 1-1000 |
| Parametertyp | dynamic |
| Dokumentation | hash_mem_multiplier |
huge_pages
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | 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 | Statisch |
| Dokumentation | huge_pages |
Description
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 riesiger Seiten kann Leistungsvorteile bieten, die 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 riesige Seiten nur für den freigegebenen Speicherbereich verwenden. Ein erheblicher Teil des gemeinsamen Speicherbereichs wird für geteilte Puffer zugewiesen.
Ein weiterer Vorteil besteht darin, dass große Seiten den Austausch des freigegebenen Speicherbereichs auf den Datenträger verhindern, wodurch die Leistung weiter stabilisiert wird.
Recommendations
- 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 sie erwarten, dass sie auf einen Server skaliert werden, der dies tut, behalten Sie die
huge_pagesEinstellungTRYfür einen nahtlosen Übergang und eine optimale Leistung bei.
Azure-spezifische Hinweise
Für Server mit vier oder mehr vCores werden riesige Seiten automatisch vom zugrunde liegenden Betriebssystem zugeordnet. Das Feature ist für Server mit weniger als vier vCores nicht verfügbar. Die Anzahl der riesigen Seiten wird automatisch angepasst, wenn alle Einstellungen für gemeinsam genutzten Speicher geändert werden, einschließlich Änderungen an shared_buffers.
huge_page_size
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | 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
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | Legt den maximalen Arbeitsspeicher fest, der für die logische Decodierung verwendet werden soll. |
| Datentyp | integer |
| Standardwert | 65536 |
| Zulässige Werte | 64-2147483647 |
| Parametertyp | dynamic |
| Dokumentation | logical_decoding_work_mem |
maintenance_work_mem
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | 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 | dynamic |
| Dokumentation | maintenance_work_mem |
Description
maintenance_work_mem ist ein Konfigurationsparameter in PostgreSQL. Sie bestimmt die Menge des Arbeitsspeichers, der für Wartungsvorgänge 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 Aufgaben vorbehalten, die die Datenbankstruktur verwalten und optimieren.
! [HINWEIS] Das Festlegen
maintenance_work_memauf übermäßig aggressive Werte kann in regelmäßigen Abständen zu einem Speicherfehler im System führen. Es ist äußerst wichtig zu verstehen, wie viel Arbeitsspeicher auf dem Server verfügbar ist, und die Anzahl der gleichzeitigen Vorgänge, die Speicher für die zuvor beschriebenen Aufgaben zuweisen können, bevor Änderungen an diesem Parameter vorgenommen werden.
Wichtige Punkte
-
Speicherbegrenzung des Vakuums: Wenn Sie die Bereinigung von toten Tupeln beschleunigen möchten, indem Sie die
maintenance_work_memerhöhen, beachten Sie, dassVACUUMintegrierte Einschränkungen für das Sammeln von toten Tupel-IDs aufweist. Es kann nur bis zu 1 GB Arbeitsspeicher für diesen Prozess verwenden. -
Trennung des Speichers für autovacuum: Sie können die
autovacuum_work_memEinstellung verwenden, um den Speicher zu steuern, den autovacuum-Vorgänge unabhängig voneinander verwenden. 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 beeinträchtigen.
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.
Jedes Mal, wenn Sie das einer Instanz zugewiesene Produkt ändern, 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 | 99.328 KiB |
| 4 GiB | 157.696 KiB |
| 8 GiB | 216.064 KiB |
| 16 GiB | 274.432 KiB |
| 32GiB | 332.800 KiB |
| 48 GiB | 367.616 KiB |
| 64 GiB | 392.192 KiB |
| 80 GiB | 410.624 KiB |
| 128 GB | 450.560 KiB |
| 160 GiB | 468.992 KiB |
| 192 GiB | 484.352 KiB |
| 256 GiB | 508.928 KiB |
| 384 GiB | 542.720 KiB |
| 432 GiB | 552.960 KiB |
| 672 GiB | 590.848 KiB |
max_prepared_transactions
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | 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 | Statisch |
| Dokumentation | max_prepared_transactions |
max_stack_depth
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | 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
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | Die Menge des beim Start reservierten dynamischen gemeinsam genutzten Speichers. |
| Datentyp | integer |
| Standardwert | 0 |
| Zulässige Werte | 0 |
| Parametertyp | schreibgeschützt |
| Dokumentation | min_dynamic_shared_memory |
shared_buffers
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | 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 | Statisch |
| Dokumentation | shared_buffers |
Description
Der shared_buffers Konfigurationsparameter bestimmt die Menge des Systemspeichers, der der PostgreSQL-Datenbank zur Pufferung von Daten zugeordnet ist. Sie 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 zeitraubender Lesevorgang vom Datenträger wird umgangen. Geteilte Puffer dienen als Vermittler zwischen den Datenbankprozessen und dem Datenträger und verringern 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 shared_buffers Serverparameter dieser Instanz.
Jedes Mal, wenn Sie das einer Instanz zugewiesene Produkt ändern, 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 ist die Formel, die zum Berechnen des Werts shared_buffers verwendet wird memoryGib * 16384.
Bei virtuellen Computern mit mehr als 2 GiB ist 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 |
| 64 GiB | 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 |
Gemeinsamer_Speicher_Typ
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | Wählt die für den Hauptspeicherbereich gemeinsam genutzte Speicherimplementierung aus. |
| Datentyp | enumeration |
| Standardwert | mmap |
| Zulässige Werte | mmap |
| Parametertyp | schreibgeschützt |
| Dokumentation | geteilte_Speicherart |
temporäre Puffer
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | 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 | dynamic |
| Dokumentation | temp_buffers |
work_mem
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | 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 | dynamic |
| Dokumentation | work_mem |
Description
Der work_mem Parameter 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 verringern, temporäre Daten auf den Datenträger zu schreiben.
Wichtige Punkte
-
Privater Verbindungsspeicher:
work_memist Teil des privaten Speichers, den jede Datenbanksitzung verwendet. Dieser Speicher unterscheidet sich von dem freigegebenen Speicherbereich, dershared_buffersverwendet wird. -
Abfragespezifische Verwendung: Nicht alle Sitzungen oder Abfragen verwenden
work_mem. Bei einfachen Abfragen wieSELECT 1ist es unwahrscheinlich, dass siework_membenötigen. Komplexere Abfragen mit Vorgängen wie Sortieren oder Hashing können jedoch einen oder mehrere Abschnitte vonwork_memnutzen. -
Parallele Vorgänge: Bei Abfragen, die mehrere parallele Back-Ends umfassen, kann jedes Back-End potenziell einen oder mehrere Abschnitte von
work_memverwenden.
Überwachung und Anpassung des Parameters work_mem
Es ist wichtig, die Leistung Ihres Systems kontinuierlich zu überwachen und bei Bedarf anzupassen work_mem , in erster Linie, wenn Abfrageausführungszeiten im Zusammenhang mit Sortier- oder Hashingvorgä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 der potenzielle Bedarf,
work_memzu erhöhen, besteht. - Anleitungen zur Problembehandlung: Verwenden Sie die Registerkarte "Hoch temporäre Dateien " in den Anleitungen zur Problembehandlung, um problematische Abfragen zu identifizieren.
Granulare Anpassung
Während Sie den work_mem Parameter verwalten, ist es oft effizienter, einen granularen Anpassungsansatz zu übernehmen, anstatt einen globalen Wert festzulegen. Dieser Ansatz stellt sicher, dass Sie den Speicher sorgfältig basierend auf den spezifischen Anforderungen der Prozesse und Benutzer allokieren. Außerdem wird das Risiko minimiert, dass Probleme mit nicht genügend Arbeitsspeicher auftreten. Hier erfahren Sie, wie Sie vorgehen können:
Benutzerebene: Wenn ein bestimmter Benutzer in erster Linie an Aggregations- oder Berichterstellungsaufgaben beteiligt ist, die arbeitsspeicherintensiv sind, sollten Sie den Wert für diesen
work_memBenutzer anpassen. Verwenden Sie denALTER ROLEBefehl, um die Leistung der Benutzervorgänge zu verbessern.Funktions-/Prozedurebene: Wenn bestimmte Funktionen oder Prozeduren erhebliche temporäre Dateien generieren, kann die Erhöhung des
work_memWerts auf der spezifischen Funktions- oder Prozedurebene von Vorteil sein. Verwenden Sie denALTER FUNCTION- oder denALTER PROCEDURE-Befehl, um diesen Vorgängen gezielt mehr Arbeitsspeicher zuzuweisen.Datenbankebene: Ändern sie
work_memauf Datenbankebene, wenn nur bestimmte Datenbanken eine hohe Anzahl temporärer Dateien generieren.Globales Niveau: Wenn eine Analyse Ihres Systems zeigt, dass die meisten Abfragen kleine temporäre Dateien erzeugen, während nur wenige große erzeugt werden, könnte es ratsam sein, den
work_memWert 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 sie den erhöhtenwork_memWert verarbeiten kann.
Bestimmen des minimalen work_mem Werts für Sortiervorgänge
Um den Minimalwert work_mem für eine bestimmte Abfrage zu ermitteln, insbesondere eines, das temporäre Datenträgerdateien während des Sortiervorgangs generiert, sollten Sie zunächst die temporäre Dateigröße berücksichtigen, die während der Abfrageausführung generiert wurde. Beispiel: Wenn eine Abfrage eine temporäre 20 MB-Datei generiert:
- Stellen Sie mithilfe von psql oder Ihrem bevorzugten PostgreSQL-Client eine Verbindung mit Ihrer Datenbank her.
- Legen Sie einen Anfangswert
work_memfest, der etwas höher als 20 MB ist, um zusätzliche Header bei der Verarbeitung im Arbeitsspeicher zu berücksichtigen. Verwenden Sie einen Befehl wie:SET work_mem TO '25MB'. - Führen Sie
EXPLAIN ANALYZEdie 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, erhöhen Sie denwork_memWert schrittweise und testen Sie erneut, bis"quicksort Memory"angezeigt wird. Das Auftreten von"quicksort Memory"signalisiert, 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
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | Legt den maximalen Arbeitsspeicher für die einzelnen Autovacuum-Arbeitsprozesse fest. |
| Datentyp | integer |
| Standardwert | -1 |
| Zulässige Werte | -1-2097151 |
| Parametertyp | dynamic |
| Dokumentation | autovacuum_work_mem |
dynamischer_geteilt-Speicher_Typ
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | 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
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | Mehrfaches von work_mem, das für Hashtabellen verwendet werden soll. |
| Datentyp | NUMERIC |
| Standardwert | 1 |
| Zulässige Werte | 1-1000 |
| Parametertyp | dynamic |
| Dokumentation | hash_mem_multiplier |
huge_pages
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | 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 | Statisch |
| Dokumentation | huge_pages |
Description
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 riesiger Seiten kann Leistungsvorteile bieten, die 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 riesige Seiten nur für den freigegebenen Speicherbereich verwenden. Ein erheblicher Teil des gemeinsamen Speicherbereichs wird für geteilte Puffer zugewiesen.
Ein weiterer Vorteil besteht darin, dass große Seiten den Austausch des freigegebenen Speicherbereichs auf den Datenträger verhindern, wodurch die Leistung weiter stabilisiert wird.
Recommendations
- 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 sie erwarten, dass sie auf einen Server skaliert werden, der dies tut, behalten Sie die
huge_pagesEinstellungTRYfür einen nahtlosen Übergang und eine optimale Leistung bei.
Azure-spezifische Hinweise
Für Server mit vier oder mehr vCores werden riesige Seiten automatisch vom zugrunde liegenden Betriebssystem zugeordnet. Das Feature ist für Server mit weniger als vier vCores nicht verfügbar. Die Anzahl der riesigen Seiten wird automatisch angepasst, wenn alle Einstellungen für gemeinsam genutzten Speicher geändert werden, einschließlich Änderungen an shared_buffers.
logical_decoding_work_mem
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | Legt den maximalen Arbeitsspeicher fest, der für die logische Decodierung verwendet werden soll. |
| Datentyp | integer |
| Standardwert | 65536 |
| Zulässige Werte | 64-2147483647 |
| Parametertyp | dynamic |
| Dokumentation | logical_decoding_work_mem |
maintenance_work_mem
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | 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 | dynamic |
| Dokumentation | maintenance_work_mem |
Description
maintenance_work_mem ist ein Konfigurationsparameter in PostgreSQL. Sie bestimmt die Menge des Arbeitsspeichers, der für Wartungsvorgänge 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 Aufgaben vorbehalten, die die Datenbankstruktur verwalten und optimieren.
! [HINWEIS] Das Festlegen
maintenance_work_memauf übermäßig aggressive Werte kann in regelmäßigen Abständen zu einem Speicherfehler im System führen. Es ist äußerst wichtig zu verstehen, wie viel Arbeitsspeicher auf dem Server verfügbar ist, und die Anzahl der gleichzeitigen Vorgänge, die Speicher für die zuvor beschriebenen Aufgaben zuweisen können, bevor Änderungen an diesem Parameter vorgenommen werden.
Wichtige Punkte
-
Speicherbegrenzung des Vakuums: Wenn Sie die Bereinigung von toten Tupeln beschleunigen möchten, indem Sie die
maintenance_work_memerhöhen, beachten Sie, dassVACUUMintegrierte Einschränkungen für das Sammeln von toten Tupel-IDs aufweist. Es kann nur bis zu 1 GB Arbeitsspeicher für diesen Prozess verwenden. -
Trennung des Speichers für autovacuum: Sie können die
autovacuum_work_memEinstellung verwenden, um den Speicher zu steuern, den autovacuum-Vorgänge unabhängig voneinander verwenden. 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 beeinträchtigen.
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.
Jedes Mal, wenn Sie das einer Instanz zugewiesene Produkt ändern, 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 | 99.328 KiB |
| 4 GiB | 157.696 KiB |
| 8 GiB | 216.064 KiB |
| 16 GiB | 274.432 KiB |
| 32GiB | 332.800 KiB |
| 48 GiB | 367.616 KiB |
| 64 GiB | 392.192 KiB |
| 80 GiB | 410.624 KiB |
| 128 GB | 450.560 KiB |
| 160 GiB | 468.992 KiB |
| 192 GiB | 484.352 KiB |
| 256 GiB | 508.928 KiB |
| 384 GiB | 542.720 KiB |
| 432 GiB | 552.960 KiB |
| 672 GiB | 590.848 KiB |
max_prepared_transactions
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | 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 | Statisch |
| Dokumentation | max_prepared_transactions |
max_stack_depth
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | Legt die maximale Stapeltiefe in Kilobyte fest. |
| Datentyp | integer |
| Standardwert | 2048 |
| Zulässige Werte | 2048 |
| Parametertyp | schreibgeschützt |
| Dokumentation | max_stack_depth |
shared_buffers
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | 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 | Statisch |
| Dokumentation | shared_buffers |
Description
Der shared_buffers Konfigurationsparameter bestimmt die Menge des Systemspeichers, der der PostgreSQL-Datenbank zur Pufferung von Daten zugeordnet ist. Sie 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 zeitraubender Lesevorgang vom Datenträger wird umgangen. Geteilte Puffer dienen als Vermittler zwischen den Datenbankprozessen und dem Datenträger und verringern 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 shared_buffers Serverparameter dieser Instanz.
Jedes Mal, wenn Sie das einer Instanz zugewiesene Produkt ändern, 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 ist die Formel, die zum Berechnen des Werts shared_buffers verwendet wird memoryGib * 16384.
Bei virtuellen Computern mit mehr als 2 GiB ist 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 |
| 64 GiB | 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 |
Gemeinsamer_Speicher_Typ
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | Wählt die für den Hauptspeicherbereich gemeinsam genutzte Speicherimplementierung aus. |
| Datentyp | enumeration |
| Standardwert | mmap |
| Zulässige Werte | mmap |
| Parametertyp | schreibgeschützt |
| Dokumentation | geteilte_Speicherart |
temporäre Puffer
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | 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 | dynamic |
| Dokumentation | temp_buffers |
work_mem
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | 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 | dynamic |
| Dokumentation | work_mem |
Description
Der work_mem Parameter 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 verringern, temporäre Daten auf den Datenträger zu schreiben.
Wichtige Punkte
-
Privater Verbindungsspeicher:
work_memist Teil des privaten Speichers, den jede Datenbanksitzung verwendet. Dieser Speicher unterscheidet sich von dem freigegebenen Speicherbereich, dershared_buffersverwendet wird. -
Abfragespezifische Verwendung: Nicht alle Sitzungen oder Abfragen verwenden
work_mem. Bei einfachen Abfragen wieSELECT 1ist es unwahrscheinlich, dass siework_membenötigen. Komplexere Abfragen mit Vorgängen wie Sortieren oder Hashing können jedoch einen oder mehrere Abschnitte vonwork_memnutzen. -
Parallele Vorgänge: Bei Abfragen, die mehrere parallele Back-Ends umfassen, kann jedes Back-End potenziell einen oder mehrere Abschnitte von
work_memverwenden.
Überwachung und Anpassung des Parameters work_mem
Es ist wichtig, die Leistung Ihres Systems kontinuierlich zu überwachen und bei Bedarf anzupassen work_mem , in erster Linie, wenn Abfrageausführungszeiten im Zusammenhang mit Sortier- oder Hashingvorgä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 der potenzielle Bedarf,
work_memzu erhöhen, besteht. - Anleitungen zur Problembehandlung: Verwenden Sie die Registerkarte "Hoch temporäre Dateien " in den Anleitungen zur Problembehandlung, um problematische Abfragen zu identifizieren.
Granulare Anpassung
Während Sie den work_mem Parameter verwalten, ist es oft effizienter, einen granularen Anpassungsansatz zu übernehmen, anstatt einen globalen Wert festzulegen. Dieser Ansatz stellt sicher, dass Sie den Speicher sorgfältig basierend auf den spezifischen Anforderungen der Prozesse und Benutzer allokieren. Außerdem wird das Risiko minimiert, dass Probleme mit nicht genügend Arbeitsspeicher auftreten. Hier erfahren Sie, wie Sie vorgehen können:
Benutzerebene: Wenn ein bestimmter Benutzer in erster Linie an Aggregations- oder Berichterstellungsaufgaben beteiligt ist, die arbeitsspeicherintensiv sind, sollten Sie den Wert für diesen
work_memBenutzer anpassen. Verwenden Sie denALTER ROLEBefehl, um die Leistung der Benutzervorgänge zu verbessern.Funktions-/Prozedurebene: Wenn bestimmte Funktionen oder Prozeduren erhebliche temporäre Dateien generieren, kann die Erhöhung des
work_memWerts auf der spezifischen Funktions- oder Prozedurebene von Vorteil sein. Verwenden Sie denALTER FUNCTION- oder denALTER PROCEDURE-Befehl, um diesen Vorgängen gezielt mehr Arbeitsspeicher zuzuweisen.Datenbankebene: Ändern sie
work_memauf Datenbankebene, wenn nur bestimmte Datenbanken eine hohe Anzahl temporärer Dateien generieren.Globales Niveau: Wenn eine Analyse Ihres Systems zeigt, dass die meisten Abfragen kleine temporäre Dateien erzeugen, während nur wenige große erzeugt werden, könnte es ratsam sein, den
work_memWert 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 sie den erhöhtenwork_memWert verarbeiten kann.
Bestimmen des minimalen work_mem Werts für Sortiervorgänge
Um den Minimalwert work_mem für eine bestimmte Abfrage zu ermitteln, insbesondere eines, das temporäre Datenträgerdateien während des Sortiervorgangs generiert, sollten Sie zunächst die temporäre Dateigröße berücksichtigen, die während der Abfrageausführung generiert wurde. Beispiel: Wenn eine Abfrage eine temporäre 20 MB-Datei generiert:
- Stellen Sie mithilfe von psql oder Ihrem bevorzugten PostgreSQL-Client eine Verbindung mit Ihrer Datenbank her.
- Legen Sie einen Anfangswert
work_memfest, der etwas höher als 20 MB ist, um zusätzliche Header bei der Verarbeitung im Arbeitsspeicher zu berücksichtigen. Verwenden Sie einen Befehl wie:SET work_mem TO '25MB'. - Führen Sie
EXPLAIN ANALYZEdie 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, erhöhen Sie denwork_memWert schrittweise und testen Sie erneut, bis"quicksort Memory"angezeigt wird. Das Auftreten von"quicksort Memory"signalisiert, 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
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | Legt den maximalen Arbeitsspeicher für die einzelnen Autovacuum-Arbeitsprozesse fest. |
| Datentyp | integer |
| Standardwert | -1 |
| Zulässige Werte | -1-2097151 |
| Parametertyp | dynamic |
| Dokumentation | autovacuum_work_mem |
dynamischer_geteilt-Speicher_Typ
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | 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
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | Mehrfaches von work_mem, das für Hashtabellen verwendet werden soll. |
| Datentyp | NUMERIC |
| Standardwert | 1 |
| Zulässige Werte | 1-1000 |
| Parametertyp | dynamic |
| Dokumentation | hash_mem_multiplier |
huge_pages
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | 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 | Statisch |
| Dokumentation | huge_pages |
Description
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 riesiger Seiten kann Leistungsvorteile bieten, die 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 riesige Seiten nur für den freigegebenen Speicherbereich verwenden. Ein erheblicher Teil des gemeinsamen Speicherbereichs wird für geteilte Puffer zugewiesen.
Ein weiterer Vorteil besteht darin, dass große Seiten den Austausch des freigegebenen Speicherbereichs auf den Datenträger verhindern, wodurch die Leistung weiter stabilisiert wird.
Recommendations
- 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 sie erwarten, dass sie auf einen Server skaliert werden, der dies tut, behalten Sie die
huge_pagesEinstellungTRYfür einen nahtlosen Übergang und eine optimale Leistung bei.
Azure-spezifische Hinweise
Für Server mit vier oder mehr vCores werden riesige Seiten automatisch vom zugrunde liegenden Betriebssystem zugeordnet. Das Feature ist für Server mit weniger als vier vCores nicht verfügbar. Die Anzahl der riesigen Seiten wird automatisch angepasst, wenn alle Einstellungen für gemeinsam genutzten Speicher geändert werden, einschließlich Änderungen an shared_buffers.
maintenance_work_mem
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | 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 | dynamic |
| Dokumentation | maintenance_work_mem |
Description
maintenance_work_mem ist ein Konfigurationsparameter in PostgreSQL. Sie bestimmt die Menge des Arbeitsspeichers, der für Wartungsvorgänge 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 Aufgaben vorbehalten, die die Datenbankstruktur verwalten und optimieren.
! [HINWEIS] Das Festlegen
maintenance_work_memauf übermäßig aggressive Werte kann in regelmäßigen Abständen zu einem Speicherfehler im System führen. Es ist äußerst wichtig zu verstehen, wie viel Arbeitsspeicher auf dem Server verfügbar ist, und die Anzahl der gleichzeitigen Vorgänge, die Speicher für die zuvor beschriebenen Aufgaben zuweisen können, bevor Änderungen an diesem Parameter vorgenommen werden.
Wichtige Punkte
-
Speicherbegrenzung des Vakuums: Wenn Sie die Bereinigung von toten Tupeln beschleunigen möchten, indem Sie die
maintenance_work_memerhöhen, beachten Sie, dassVACUUMintegrierte Einschränkungen für das Sammeln von toten Tupel-IDs aufweist. Es kann nur bis zu 1 GB Arbeitsspeicher für diesen Prozess verwenden. -
Trennung des Speichers für autovacuum: Sie können die
autovacuum_work_memEinstellung verwenden, um den Speicher zu steuern, den autovacuum-Vorgänge unabhängig voneinander verwenden. 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 beeinträchtigen.
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.
Jedes Mal, wenn Sie das einer Instanz zugewiesene Produkt ändern, 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 | 99.328 KiB |
| 4 GiB | 157.696 KiB |
| 8 GiB | 216.064 KiB |
| 16 GiB | 274.432 KiB |
| 32GiB | 332.800 KiB |
| 48 GiB | 367.616 KiB |
| 64 GiB | 392.192 KiB |
| 80 GiB | 410.624 KiB |
| 128 GB | 450.560 KiB |
| 160 GiB | 468.992 KiB |
| 192 GiB | 484.352 KiB |
| 256 GiB | 508.928 KiB |
| 384 GiB | 542.720 KiB |
| 432 GiB | 552.960 KiB |
| 672 GiB | 590.848 KiB |
max_prepared_transactions
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | 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 | Statisch |
| Dokumentation | max_prepared_transactions |
max_stack_depth
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | Legt die maximale Stapeltiefe in Kilobyte fest. |
| Datentyp | integer |
| Standardwert | 2048 |
| Zulässige Werte | 2048 |
| Parametertyp | schreibgeschützt |
| Dokumentation | max_stack_depth |
shared_buffers
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | 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 | Statisch |
| Dokumentation | shared_buffers |
Description
Der shared_buffers Konfigurationsparameter bestimmt die Menge des Systemspeichers, der der PostgreSQL-Datenbank zur Pufferung von Daten zugeordnet ist. Sie 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 zeitraubender Lesevorgang vom Datenträger wird umgangen. Geteilte Puffer dienen als Vermittler zwischen den Datenbankprozessen und dem Datenträger und verringern 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 shared_buffers Serverparameter dieser Instanz.
Jedes Mal, wenn Sie das einer Instanz zugewiesene Produkt ändern, 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 ist die Formel, die zum Berechnen des Werts shared_buffers verwendet wird memoryGib * 16384.
Bei virtuellen Computern mit mehr als 2 GiB ist 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 |
| 64 GiB | 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 |
Gemeinsamer_Speicher_Typ
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | Wählt die für den Hauptspeicherbereich gemeinsam genutzte Speicherimplementierung aus. |
| Datentyp | enumeration |
| Standardwert | mmap |
| Zulässige Werte | mmap |
| Parametertyp | schreibgeschützt |
| Dokumentation | geteilte_Speicherart |
temporäre Puffer
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | 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 | dynamic |
| Dokumentation | temp_buffers |
work_mem
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | 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 | dynamic |
| Dokumentation | work_mem |
Description
Der work_mem Parameter 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 verringern, temporäre Daten auf den Datenträger zu schreiben.
Wichtige Punkte
-
Privater Verbindungsspeicher:
work_memist Teil des privaten Speichers, den jede Datenbanksitzung verwendet. Dieser Speicher unterscheidet sich von dem freigegebenen Speicherbereich, dershared_buffersverwendet wird. -
Abfragespezifische Verwendung: Nicht alle Sitzungen oder Abfragen verwenden
work_mem. Bei einfachen Abfragen wieSELECT 1ist es unwahrscheinlich, dass siework_membenötigen. Komplexere Abfragen mit Vorgängen wie Sortieren oder Hashing können jedoch einen oder mehrere Abschnitte vonwork_memnutzen. -
Parallele Vorgänge: Bei Abfragen, die mehrere parallele Back-Ends umfassen, kann jedes Back-End potenziell einen oder mehrere Abschnitte von
work_memverwenden.
Überwachung und Anpassung des Parameters work_mem
Es ist wichtig, die Leistung Ihres Systems kontinuierlich zu überwachen und bei Bedarf anzupassen work_mem , in erster Linie, wenn Abfrageausführungszeiten im Zusammenhang mit Sortier- oder Hashingvorgä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 der potenzielle Bedarf,
work_memzu erhöhen, besteht. - Anleitungen zur Problembehandlung: Verwenden Sie die Registerkarte "Hoch temporäre Dateien " in den Anleitungen zur Problembehandlung, um problematische Abfragen zu identifizieren.
Granulare Anpassung
Während Sie den work_mem Parameter verwalten, ist es oft effizienter, einen granularen Anpassungsansatz zu übernehmen, anstatt einen globalen Wert festzulegen. Dieser Ansatz stellt sicher, dass Sie den Speicher sorgfältig basierend auf den spezifischen Anforderungen der Prozesse und Benutzer allokieren. Außerdem wird das Risiko minimiert, dass Probleme mit nicht genügend Arbeitsspeicher auftreten. Hier erfahren Sie, wie Sie vorgehen können:
Benutzerebene: Wenn ein bestimmter Benutzer in erster Linie an Aggregations- oder Berichterstellungsaufgaben beteiligt ist, die arbeitsspeicherintensiv sind, sollten Sie den Wert für diesen
work_memBenutzer anpassen. Verwenden Sie denALTER ROLEBefehl, um die Leistung der Benutzervorgänge zu verbessern.Funktions-/Prozedurebene: Wenn bestimmte Funktionen oder Prozeduren erhebliche temporäre Dateien generieren, kann die Erhöhung des
work_memWerts auf der spezifischen Funktions- oder Prozedurebene von Vorteil sein. Verwenden Sie denALTER FUNCTION- oder denALTER PROCEDURE-Befehl, um diesen Vorgängen gezielt mehr Arbeitsspeicher zuzuweisen.Datenbankebene: Ändern sie
work_memauf Datenbankebene, wenn nur bestimmte Datenbanken eine hohe Anzahl temporärer Dateien generieren.Globales Niveau: Wenn eine Analyse Ihres Systems zeigt, dass die meisten Abfragen kleine temporäre Dateien erzeugen, während nur wenige große erzeugt werden, könnte es ratsam sein, den
work_memWert 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 sie den erhöhtenwork_memWert verarbeiten kann.
Bestimmen des minimalen work_mem Werts für Sortiervorgänge
Um den Minimalwert work_mem für eine bestimmte Abfrage zu ermitteln, insbesondere eines, das temporäre Datenträgerdateien während des Sortiervorgangs generiert, sollten Sie zunächst die temporäre Dateigröße berücksichtigen, die während der Abfrageausführung generiert wurde. Beispiel: Wenn eine Abfrage eine temporäre 20 MB-Datei generiert:
- Stellen Sie mithilfe von psql oder Ihrem bevorzugten PostgreSQL-Client eine Verbindung mit Ihrer Datenbank her.
- Legen Sie einen Anfangswert
work_memfest, der etwas höher als 20 MB ist, um zusätzliche Header bei der Verarbeitung im Arbeitsspeicher zu berücksichtigen. Verwenden Sie einen Befehl wie:SET work_mem TO '25MB'. - Führen Sie
EXPLAIN ANALYZEdie 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, erhöhen Sie denwork_memWert schrittweise und testen Sie erneut, bis"quicksort Memory"angezeigt wird. Das Auftreten von"quicksort Memory"signalisiert, 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
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | Legt den maximalen Arbeitsspeicher für die einzelnen Autovacuum-Arbeitsprozesse fest. |
| Datentyp | integer |
| Standardwert | -1 |
| Zulässige Werte | -1-2097151 |
| Parametertyp | dynamic |
| Dokumentation | autovacuum_work_mem |
dynamischer_geteilt-Speicher_Typ
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | 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
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | 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 | Statisch |
| Dokumentation | huge_pages |
Description
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 riesiger Seiten kann Leistungsvorteile bieten, die 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 riesige Seiten nur für den freigegebenen Speicherbereich verwenden. Ein erheblicher Teil des gemeinsamen Speicherbereichs wird für geteilte Puffer zugewiesen.
Ein weiterer Vorteil besteht darin, dass große Seiten den Austausch des freigegebenen Speicherbereichs auf den Datenträger verhindern, wodurch die Leistung weiter stabilisiert wird.
Recommendations
- 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 sie erwarten, dass sie auf einen Server skaliert werden, der dies tut, behalten Sie die
huge_pagesEinstellungTRYfür einen nahtlosen Übergang und eine optimale Leistung bei.
Azure-spezifische Hinweise
Für Server mit vier oder mehr vCores werden riesige Seiten automatisch vom zugrunde liegenden Betriebssystem zugeordnet. Das Feature ist für Server mit weniger als vier vCores nicht verfügbar. Die Anzahl der riesigen Seiten wird automatisch angepasst, wenn alle Einstellungen für gemeinsam genutzten Speicher geändert werden, einschließlich Änderungen an shared_buffers.
maintenance_work_mem
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | 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 | dynamic |
| Dokumentation | maintenance_work_mem |
Description
maintenance_work_mem ist ein Konfigurationsparameter in PostgreSQL. Sie bestimmt die Menge des Arbeitsspeichers, der für Wartungsvorgänge 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 Aufgaben vorbehalten, die die Datenbankstruktur verwalten und optimieren.
! [HINWEIS] Das Festlegen
maintenance_work_memauf übermäßig aggressive Werte kann in regelmäßigen Abständen zu einem Speicherfehler im System führen. Es ist äußerst wichtig zu verstehen, wie viel Arbeitsspeicher auf dem Server verfügbar ist, und die Anzahl der gleichzeitigen Vorgänge, die Speicher für die zuvor beschriebenen Aufgaben zuweisen können, bevor Änderungen an diesem Parameter vorgenommen werden.
Wichtige Punkte
-
Speicherbegrenzung des Vakuums: Wenn Sie die Bereinigung von toten Tupeln beschleunigen möchten, indem Sie die
maintenance_work_memerhöhen, beachten Sie, dassVACUUMintegrierte Einschränkungen für das Sammeln von toten Tupel-IDs aufweist. Es kann nur bis zu 1 GB Arbeitsspeicher für diesen Prozess verwenden. -
Trennung des Speichers für autovacuum: Sie können die
autovacuum_work_memEinstellung verwenden, um den Speicher zu steuern, den autovacuum-Vorgänge unabhängig voneinander verwenden. 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 beeinträchtigen.
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.
Jedes Mal, wenn Sie das einer Instanz zugewiesene Produkt ändern, 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 | 99.328 KiB |
| 4 GiB | 157.696 KiB |
| 8 GiB | 216.064 KiB |
| 16 GiB | 274.432 KiB |
| 32GiB | 332.800 KiB |
| 48 GiB | 367.616 KiB |
| 64 GiB | 392.192 KiB |
| 80 GiB | 410.624 KiB |
| 128 GB | 450.560 KiB |
| 160 GiB | 468.992 KiB |
| 192 GiB | 484.352 KiB |
| 256 GiB | 508.928 KiB |
| 384 GiB | 542.720 KiB |
| 432 GiB | 552.960 KiB |
| 672 GiB | 590.848 KiB |
max_prepared_transactions
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | 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 | Statisch |
| Dokumentation | max_prepared_transactions |
max_stack_depth
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | Legt die maximale Stapeltiefe in Kilobyte fest. |
| Datentyp | integer |
| Standardwert | 2048 |
| Zulässige Werte | 2048 |
| Parametertyp | schreibgeschützt |
| Dokumentation | max_stack_depth |
shared_buffers
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | 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 | Statisch |
| Dokumentation | shared_buffers |
Description
Der shared_buffers Konfigurationsparameter bestimmt die Menge des Systemspeichers, der der PostgreSQL-Datenbank zur Pufferung von Daten zugeordnet ist. Sie 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 zeitraubender Lesevorgang vom Datenträger wird umgangen. Geteilte Puffer dienen als Vermittler zwischen den Datenbankprozessen und dem Datenträger und verringern 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 shared_buffers Serverparameter dieser Instanz.
Jedes Mal, wenn Sie das einer Instanz zugewiesene Produkt ändern, 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 ist die Formel, die zum Berechnen des Werts shared_buffers verwendet wird memoryGib * 16384.
Bei virtuellen Computern mit mehr als 2 GiB ist 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 |
| 64 GiB | 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 |
temporäre Puffer
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | 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 | dynamic |
| Dokumentation | temp_buffers |
work_mem
| Merkmal | Wert |
|---|---|
| Kategorie | Ressourcennutzung/Speicher |
| Description | 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 | dynamic |
| Dokumentation | work_mem |
Description
Der work_mem Parameter 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 verringern, temporäre Daten auf den Datenträger zu schreiben.
Wichtige Punkte
-
Privater Verbindungsspeicher:
work_memist Teil des privaten Speichers, den jede Datenbanksitzung verwendet. Dieser Speicher unterscheidet sich von dem freigegebenen Speicherbereich, dershared_buffersverwendet wird. -
Abfragespezifische Verwendung: Nicht alle Sitzungen oder Abfragen verwenden
work_mem. Bei einfachen Abfragen wieSELECT 1ist es unwahrscheinlich, dass siework_membenötigen. Komplexere Abfragen mit Vorgängen wie Sortieren oder Hashing können jedoch einen oder mehrere Abschnitte vonwork_memnutzen. -
Parallele Vorgänge: Bei Abfragen, die mehrere parallele Back-Ends umfassen, kann jedes Back-End potenziell einen oder mehrere Abschnitte von
work_memverwenden.
Überwachung und Anpassung des Parameters work_mem
Es ist wichtig, die Leistung Ihres Systems kontinuierlich zu überwachen und bei Bedarf anzupassen work_mem , in erster Linie, wenn Abfrageausführungszeiten im Zusammenhang mit Sortier- oder Hashingvorgä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 der potenzielle Bedarf,
work_memzu erhöhen, besteht. - Anleitungen zur Problembehandlung: Verwenden Sie die Registerkarte "Hoch temporäre Dateien " in den Anleitungen zur Problembehandlung, um problematische Abfragen zu identifizieren.
Granulare Anpassung
Während Sie den work_mem Parameter verwalten, ist es oft effizienter, einen granularen Anpassungsansatz zu übernehmen, anstatt einen globalen Wert festzulegen. Dieser Ansatz stellt sicher, dass Sie den Speicher sorgfältig basierend auf den spezifischen Anforderungen der Prozesse und Benutzer allokieren. Außerdem wird das Risiko minimiert, dass Probleme mit nicht genügend Arbeitsspeicher auftreten. Hier erfahren Sie, wie Sie vorgehen können:
Benutzerebene: Wenn ein bestimmter Benutzer in erster Linie an Aggregations- oder Berichterstellungsaufgaben beteiligt ist, die arbeitsspeicherintensiv sind, sollten Sie den Wert für diesen
work_memBenutzer anpassen. Verwenden Sie denALTER ROLEBefehl, um die Leistung der Benutzervorgänge zu verbessern.Funktions-/Prozedurebene: Wenn bestimmte Funktionen oder Prozeduren erhebliche temporäre Dateien generieren, kann die Erhöhung des
work_memWerts auf der spezifischen Funktions- oder Prozedurebene von Vorteil sein. Verwenden Sie denALTER FUNCTION- oder denALTER PROCEDURE-Befehl, um diesen Vorgängen gezielt mehr Arbeitsspeicher zuzuweisen.Datenbankebene: Ändern sie
work_memauf Datenbankebene, wenn nur bestimmte Datenbanken eine hohe Anzahl temporärer Dateien generieren.Globales Niveau: Wenn eine Analyse Ihres Systems zeigt, dass die meisten Abfragen kleine temporäre Dateien erzeugen, während nur wenige große erzeugt werden, könnte es ratsam sein, den
work_memWert 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 sie den erhöhtenwork_memWert verarbeiten kann.
Bestimmen des minimalen work_mem Werts für Sortiervorgänge
Um den Minimalwert work_mem für eine bestimmte Abfrage zu ermitteln, insbesondere eines, das temporäre Datenträgerdateien während des Sortiervorgangs generiert, sollten Sie zunächst die temporäre Dateigröße berücksichtigen, die während der Abfrageausführung generiert wurde. Beispiel: Wenn eine Abfrage eine temporäre 20 MB-Datei generiert:
- Stellen Sie mithilfe von psql oder Ihrem bevorzugten PostgreSQL-Client eine Verbindung mit Ihrer Datenbank her.
- Legen Sie einen Anfangswert
work_memfest, der etwas höher als 20 MB ist, um zusätzliche Header bei der Verarbeitung im Arbeitsspeicher zu berücksichtigen. Verwenden Sie einen Befehl wie:SET work_mem TO '25MB'. - Führen Sie
EXPLAIN ANALYZEdie 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, erhöhen Sie denwork_memWert schrittweise und testen Sie erneut, bis"quicksort Memory"angezeigt wird. Das Auftreten von"quicksort Memory"signalisiert, 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.