Share via

Serverparameter in Azure Database for PostgreSQL – Flexible Server

  • Artikel

GILT FÜR: Azure Database for PostgreSQL – Flexible Server

Azure Database for PostgreSQL bietet für jeden Server einen Satz konfigurierbarer Parameter. Weitere Informationen zu Postgres-Parametern finden Sie in der PostgreSQL-Dokumentation.

Parametertypen

Azure Database for PostgreSQL – Flexibler Server ist mit optimalen Standardwerten für die einzelnen Parameter vorkonfiguriert. Parameter werden in einen der folgenden Typen kategorisiert:

  • Statisch: Für diese Parameter ist ein Serverneustart erforderlich, um Änderungen zu implementieren.
  • Dynamisch: Diese Parameter können geändert werden, ohne dass die Serverinstanz neu gestartet werden muss. Änderungen gelten jedoch nur für neue Verbindungen, die nach der Änderung eingerichtet wurden.
  • Schreibgeschützt: Diese Parameter sind aufgrund ihrer kritischen Rolle bei der Aufrechterhaltung von Zuverlässigkeit, Sicherheit oder anderen betrieblichen Aspekten des Diensts nicht konfigurierbar.

Um den Parametertyp zu ermitteln, wechseln Sie zum Azure-Portal und öffnen Sie den Bereich Serverparameter. Die Parameter werden zur einfachen Identifizierung in Registerkarten gruppiert.

Parameteranpassung

Es stehen verschiedene Methoden und Ebenen zur Verfügung, um Ihre Parameter entsprechend Ihren spezifischen Anforderungen anzupassen.

Globale Ebene

Um Einstellungen global auf Instanz- oder Serverebene zu ändern, wechseln Sie zum Bereich Serverparameter im Azure-Portal. Sie können auch andere verfügbare Tools wie die Azure CLI, die REST-API, Azure Resource Manager-Vorlagen oder Partnertools verwenden.

Hinweis

Da Azure Database for PostgreSQL ein verwalteter Datenbankdienst ist, haben Benutzer keinen Host- oder Betriebssystemzugriff, um Konfigurationsdateien wie postgresql.conf anzuzeigen oder zu ändern. Der Inhalt der Dateien wird basierend auf den von Ihnen vorgenommenen Parameteränderungen automatisch aktualisiert.

Screenshot des Bereichs für Serverparameter im Azure-Portal.

Granulare Ebenen

Sie können Parameter auf granulareren Ebenen anpassen. Diese Anpassungen setzen global festgelegte Werte außer Kraft. Der Umfang und die Dauer hängen von der Ebene ab, auf der Sie sie festlegen:

  • Datenbankebene: Verwenden Sie den Befehl ALTER DATABASE für datenbankspezifische Konfigurationen.

  • Rollen- oder Benutzerebene: Verwenden Sie den Befehl ALTER USER für benutzerbezogene Einstellungen.

  • Funktions-, Prozedurebene: Beim Definieren einer Funktion oder Prozedur können Sie die Konfigurationsparameter angeben oder ändern, die festgelegt werden, wenn die Funktion aufgerufen wird.

  • Tabellenebene: Beispielsweise können Sie Parameter im Zusammenhang mit Autovacuum auf dieser Ebene ändern.

  • Sitzungsebene: Für die Dauer einer einzelnen Datenbanksitzung können Sie bestimmte Parameter anpassen. Diese Anpassung erleichtert PostgreSQL mit den folgenden SQL-Befehlen:

    • Mit dem Befehl SET nehmen Sie sitzungsspezifische Anpassungen vor. Diese Änderungen dienen während der aktuellen Sitzung als Standardeinstellungen. Der Zugriff auf diese Änderungen erfordert möglicherweise bestimmte SET-Berechtigungen, und die Einschränkungen für modifizierbare und schreibgeschützte Parameter, die oben beschrieben werden, gelten nicht. Die entsprechende SQL-Funktion ist set_config(setting_name, new_value, is_local).
    • Verwenden Sie den Befehl SHOW, um vorhandene Parametereinstellungen zu untersuchen. Die äquivalente SQL-Funktion ist current_setting(setting_name text).

Wichtige Parameter

In den folgenden Abschnitten werden einige der Parameter beschrieben.

shared_buffers

attribute Wert
Standardwert 25 % des gesamten RAM
Zulässiger Wert 10-75 % des gesamten RAM
Typ Statisch
Ebene Global
Azure-spezifische Hinweise Die Einstellung shared_buffers wird (ungefähr) linear skaliert, wenn sich die Anzahl virtueller Kerne in einem Tarif erhöht.

Beschreibung

Der Konfigurationsparameter shared_buffers bestimmt die Menge des Systemspeichers, der der PostgreSQL-Datenbank zur Pufferung von Daten zugeordnet ist. Er dient als zentraler Speicherpool, auf den alle Datenbankprozesse zugreifen können.

Wenn Daten benötigt werden, überprüft der Datenbankprozess zuerst den freigegebenen Puffer. Wenn die erforderlichen Daten vorhanden sind, werden sie schnell abgerufen, und ein zeitaufwändigerer Datenträgerlesevorgang wird umgangen. Durch die Vermittlung zwischen den Datenbankprozessen und dem Datenträger reduziert shared_buffers effektiv die Anzahl der erforderlichen E/A-Vorgänge.

huge_pages

attribute Wert
Standardwert TRY
Zulässiger Wert TRY, ON, OFF
type Statisch
Ebene Global
Azure-spezifische Hinweise Für Server mit vier oder mehr vCores werden große Seiten automatisch vom zugrunde liegenden Betriebssystem zugewiesen. Das Feature ist für Server mit weniger als vier vCores nicht verfügbar. Die Anzahl der großen Seiten wird automatisch angepasst, wenn Einstellungen für gemeinsam genutzten Speicher geändert werden, einschließlich Änderungen an shared_buffers.

Beschreibung

Große Seiten sind ein Feature, mit dem Arbeitsspeicher in größeren Blöcken verwaltet werden kann. Sie können in der Regel Blöcke von bis zu 2 MB verwalten, im Gegensatz zu den standardmäßigen 4-KB-Seiten.

Die Verwendung großer Seiten kann Leistungsvorteile bieten, welche die CPU effektiv auslagern:

  • Sie reduzieren den Aufwand in Zusammenhang mit den Speicherverwaltungsaufgaben, z. B. weniger Translation Lookaside Buffer (TLB)-Fehler.
  • Sie verkürzen die für die Speicherverwaltung benötigte Zeit.

Insbesondere können Sie in PostgreSQL große Seiten nur für den freigegebenen Speicherbereich verwenden. Ein erheblicher Teil des freigegebenen Speicherbereichs wird an freigegebene Puffer zugewiesen.

Ein weiterer Vorteil besteht darin, dass große Seiten den Austausch des freigegebenen Speicherbereichs auf den Datenträger verhindern und so die Leistung weiter stabilisieren.

Empfehlungen

  • Vermeiden Sie für Server mit erheblichen Speicherressourcen das Deaktivieren großer Seiten. Das Deaktivieren großer Seiten kann die Leistung beeinträchtigen.
  • Wenn Sie mit einem kleineren Server beginnen, der keine großen Seiten unterstützt, aber die Skalierung auf einen Server mit Unterstützung für große Seiten antizipieren, belassen Sie die Einstellung huge_pages auf TRY, um einen nahtlosen Übergang und optimale Leistung zu gewährleisten.

work_mem

attribute Wert
Standardwert 4MB
Zulässiger Wert 4MB-2GB
type Dynamisch
Ebene Global und granular

Beschreibung

Der Parameter work_mem in PostgreSQL steuert die Menge des Speichers, der bestimmten internen Vorgängen innerhalb des privaten Speicherbereichs jeder Datenbanksitzung zugeordnet ist. Beispiele für diese Vorgänge sind Sortieren und Hashing.

Im Gegensatz zu freigegebenen Puffern, die sich im freigegebenen Speicherbereich befinden, wird work_mem in einem privaten Speicherbereich pro Sitzung oder pro Abfrage zugewiesen. Indem Sie eine angemessene work_mem-Größe festlegen, können Sie die Effizienz dieser Vorgänge erheblich verbessern und die Notwendigkeit, temporäre Daten auf den Datenträger zu schreiben, verringern.

Wesentliche Punkte

  • Privater Verbindungsspeicher: work_mem ist Teil des privaten Speichers, den jede Datenbanksitzung verwendet. Dieser Speicher unterscheidet sich von dem freigegebenen Speicherbereich, den shared_buffers verwendet.
  • Abfragespezifische Verwendung: Nicht alle Sitzungen oder Abfragen verwenden work_mem. Für einfache Abfragen wie SELECT 1 ist work_mem wahrscheinlich nicht erforderlich. Komplexere Abfragen mit Vorgängen wie Sortieren oder Hashing können jedoch einen oder mehrere Abschnitte von work_mem nutzen.
  • Parallele Vorgänge: Bei Abfragen, die mehrere parallele Back-Ends umfassen, kann jedes Back-End potenziell einen oder mehrere Blöcke von work_mem verwenden.

Überwachen und Anpassen von work_mem

Es ist wichtig, die Leistung Ihres Systems kontinuierlich zu überwachen und work_mem nach Bedarf anzupassen, in erster Linie, wenn langsame Abfrageausführungszeiten im Zusammenhang mit Sortier- oder Hashvorgängen langsam sind. Im Folgenden finden Sie Möglichkeiten zum Überwachen der Leistung mithilfe von Tools, die im Azure-Portal verfügbar sind:

  • Einblick in die Abfrageleistung: Überprüfen Sie die wichtigsten Abfragen auf der Registerkarte temporärer Dateien, um Abfragen zu identifizieren, die temporäre Dateien generieren. Diese Situation deutet darauf hin, dass ein potenzieller Bedarf für die Erhöhung von work_mem vorhanden ist.
  • Anleitungen zur Problembehandlung: Verwenden Sie die Registerkarte Hohe Anzahl temporärer Dateien in den Anleitungen zur Problembehandlung, um problematische Abfragen zu identifizieren.
Granulare Anpassung

Beim Verwalten des work_mem-Parameters ist es oft effizienter, Anpassungen granular vorzunehmen, anstatt einen globalen Wert festzulegen. Dieser Ansatz stellt sicher, dass Sie Speicher bewusst basierend auf den spezifischen Anforderungen von Prozessen und Benutzern zuordnen. Außerdem wird das Risiko minimiert, dass Probleme aufgrund ungenügendem Arbeitsspeicher auftreten. Gehen Sie hierzu wie folgt vor:

  • Benutzerebene: Wenn ein bestimmter Benutzer in erster Linie an Aggregations- oder Berichterstellungsaufgaben beteiligt ist, die arbeitsspeicherintensiv sind, sollten Sie den work_mem-Wert für diesen Benutzer anpassen. Verwenden Sie den ALTER ROLE-Befehl, um die Leistung der Benutzervorgänge zu verbessern.

  • Funktions-/Prozedurebene: Wenn bestimmte Funktionen oder Prozeduren erhebliche Mengen temporärer Dateien generieren, kann die Erhöhung des work_mem-Wertes auf der Ebene der spezifischen Funktion oder Prozedur von Vorteil sein. Verwenden Sie den Befehl ALTER FUNCTION oder ALTER PROCEDURE, um diesen Vorgängen gezielt mehr Arbeitsspeicher zuzuweisen.

  • Datenbankebene: Ändern Sie work_mem auf Datenbankebene nur, wenn bestimmte Datenbanken eine hohe Anzahl temporärer Dateien generieren.

  • Globale Ebene: Wenn eine Analyse Ihres Systems zeigt, dass die meisten Abfragen kleine temporäre Dateien generieren, während nur wenige große Dateien erstellen, kann es sinnvoll sein, den work_mem-Wert global zu erhöhen. Diese Aktion erleichtert die meisten Abfragen zum Verarbeiten im Arbeitsspeicher, sodass Sie datenträgerbasierte Vorgänge vermeiden und die Effizienz verbessern können. Seien Sie jedoch immer vorsichtig und überwachen Sie die Speicherauslastung auf Ihrem Server, um sicherzustellen, dass der erhöhte work_mem-Wert verarbeitet werden kann.

Bestimmen des minimalen work_mem-Werts für Sortiervorgänge

Um den Mindestwert von work_mem für eine bestimmte Abfrage zu ermitteln, insbesondere wenn während des Sortiervorgangs temporäre Datenträgerdateien generiert werden, betrachten Sie zunächst die Größe der temporären Datei, die während der Abfrageausführung generiert wurde. Beispiel: Wenn eine Abfrage eine temporäre Datei mit 20 MB generiert:

  1. Stellen Sie mithilfe von psql oder Ihrem bevorzugten PostgreSQL-Client eine Verbindung mit Ihrer Datenbank her.
  2. Legen Sie einen anfänglichen work_mem-Wert etwas höher als 20 MB fest, um zusätzliche Header bei der Verarbeitung im Arbeitsspeicher zu berücksichtigen. Verwenden Sie z.B. folgenden Befehl: SET work_mem TO '25MB'.
  3. Führen Sie EXPLAIN ANALYZE für die problematische Abfrage in derselben Sitzung aus.
  4. Überprüfen Sie die Ausgabe für "Sort Method: quicksort Memory: xkB". Wenn es "external merge Disk: xkB" angibt, heben Sie den work_mem-Wert inkrementell an, und testen Sie ihn erneut, bis "quicksort Memory" angezeigt wird. Das Auftreten von "quicksort Memory"-Signalen, dass die Abfrage jetzt im Arbeitsspeicher ausgeführt wird.
  5. 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.

maintenance_work_mem

attribute Wert
Standardwert Abhängig vom Serverarbeitsspeicher
Zulässiger Wert 1MB-2GB
type Dynamisch
Ebene Global und granular

Beschreibung

maintenance_work_mem ist ein Konfigurationsparameter in PostgreSQL. Er bestimmt die Menge an Arbeitsspeicher, der den Wartungsvorgängen zugeordnet ist, z. B. VACUUM, CREATE INDEX und ALTER TABLE. Im Gegensatz zu work_mem, was sich auf die Speicherzuweisung für Abfragevorgänge auswirkt, ist maintenance_work_mem für Aufgaben reserviert, die die Datenbankstruktur verwalten und optimieren.

Wesentliche Punkte

  • Begrenzung des Vakuumspeichers: Wenn Sie die Bereinigung von toten Tupeln beschleunigen möchten, indem Sie maintenance_work_mem erhöhen, beachten Sie, dass über VACUUM eine integrierte Einschränkung für das Sammeln von toten Tupel-IDs verfügt. Es kann nur bis zu 1 GB Arbeitsspeicher für diesen Prozess verwenden.
  • Trennung des Arbeitsspeichers für Autovacuum: Sie können die Einstellung autovacuum_work_mem verwenden, um den für Autovacuum-Vorgänge verwendeten Arbeitsspeicher unabhängig zu nutzen. Diese Einstellung fungiert als Teilmenge von maintenance_work_mem. Sie können entscheiden, wie viel Arbeitsspeicher Autovacuum verwendet, ohne die Speicherzuweisung für andere Wartungsaufgaben und Datendefinitionsvorgänge zu beeinflussen.

Nächste Schritte

Informationen zu unterstützten PostgreSQL-Erweiterungen finden Sie unter PostgreSQL-Erweiterungen in Azure Database for PostgreSQL – Flexible Server.