👩🏽‍🏫 🛸 👾 Optimieren der Linux-Kernelparameter zur Optimierung von PostgreSQL 🥟 📀 💠

Die optimale Leistung von PostgreSQL hängt von korrekt definierten Betriebssystemparametern ab. Schlecht abgestimmte Betriebssystemkernparameter können die Leistung des Datenbankservers beeinträchtigen. Daher ist es unbedingt erforderlich, dass diese Parameter in Übereinstimmung mit dem Datenbankserver und seiner Arbeitslast konfiguriert werden. In diesem Beitrag werden einige wichtige Linux-Kernel-Parameter erläutert, die sich auf die Leistung des Datenbankservers auswirken können, sowie deren Optimierung.

SHMMAX / SHMALL

SHMMAX ist ein Kernel-Parameter, mit dem die maximale Größe eines einzelnen gemeinsam genutzten Speichersegments bestimmt wird, das ein Linux-Prozess zuweisen kann. Vor Version 9.2 verwendete PostgreSQL System V (SysV), für das eine SHMMAX-Konfiguration erforderlich ist. Nach 9.2 wechselte PostgreSQL zu POSIX Shared Memory. Daher sind jetzt weniger Bytes des gemeinsam genutzten System V-Speichers erforderlich.

Vor Version 9.3 war SHMMAX der wichtigste Kernelparameter. Der SHMMAX-Wert wird in Bytes angegeben.

In ähnlicher Weise ist SHMALL ein weiterer Kernel-Parameter, der zur Bestimmung verwendet wird
systemweite gemeinsam genutzte Speicherseiten. Verwenden Sie den Befehl ipcs , um die aktuellen SHMMAX-, SHMALL- oder SHMMIN- Werte anzuzeigen.

^{SHM * Details - Linux}

$ ipcs -lm ------ Shared Memory Limits -------- max number of segments = 4096 max seg size (kbytes) = 1073741824 max total shared memory (kbytes) = 17179869184 min seg size (bytes) = 1

^{SHM * Details - MacOS X.}

 $ ipcs -M IPC status from as of Thu Aug 16 22:20:35 PKT 2018 shminfo: shmmax: 16777216 (max shared memory segment size) shmmin: 1 (min shared memory segment size) shmmni: 32 (max number of shared memory identifiers) shmseg: 8 (max shared memory segments per process) shmall: 1024 (max amount of shared memory in pages)

PostgreSQL verwendet System V IPC , um gemeinsam genutzten Speicher zuzuweisen. Dieser Parameter ist einer der wichtigsten Kernelparameter. Wenn Sie die folgenden Fehlermeldungen erhalten, bedeutet dies, dass Sie eine ältere Version von PostgreSQL und einen sehr niedrigen SHMMAX-Wert haben. Es wird erwartet, dass Benutzer den Wert entsprechend dem gemeinsam genutzten Speicher, den sie verwenden möchten, anpassen und erhöhen.

Mögliche Fehlkonfigurationsfehler

Wenn SHMMAX nicht richtig konfiguriert ist, wird möglicherweise eine Fehlermeldung angezeigt, wenn Sie versuchen, einen PostgreSQL-Cluster mit dem Befehl initdb zu initialisieren.

^{Initdb-Fehler}

DETAIL: Failed system call was shmget(key=1, size=2072576, 03600).

HINT: This error usually means that PostgreSQL's request for a shared memory segment exceeded your kernel's SHMMAX parameter.
You can either reduce the request size or reconfigure the kernel with larger SHMMAX. To reduce the request size (currently 2072576 bytes),
reduce PostgreSQL's shared memory usage, perhaps by reducing shared_buffers or max_connections.

If the request size is already small, it's possible that it is less than your kernel's SHMMIN parameter,
in which case raising the request size or reconfiguring SHMMIN is called for.

The PostgreSQL documentation contains more information about shared memory configuration. child process exited with exit code 1

Ebenso kann beim Starten des PostgreSQL-Servers mit dem Befehl pg_ctl eine Fehlermeldung angezeigt werden .

^{pg_ctl Fehler}

DETAIL: Failed system call was shmget(key=5432001, size=14385152, 03600).

HINT: This error usually means that PostgreSQL's request for a shared memory segment exceeded your kernel's SHMMAX parameter.

You can either reduce the request size or reconfigure the kernel with larger SHMMAX.; To reduce the request size (currently 14385152 bytes), reduce PostgreSQL's shared memory usage, perhaps by reducing shared_buffers or max_connections.

If the request size is already small, it's possible that it is less than your kernel's SHMMIN parameter,
in which case raising the request size or reconfiguring SHMMIN is called for.

The PostgreSQL documentation contains more information about shared memory configuration.

Unterschiede in den Definitionen verstehen

Die Definition der SHMMAX / SHMALL-Parameter unterscheidet sich unter Linux und MacOS X geringfügig:

Linux: kernel.shmmax, kernel.shmall
MacOS X: kern.sysv.shmmax, kern.sysv.shmall

Mit dem Befehl sysctl können Sie einen Wert vorübergehend ändern. Fügen Sie zum Festlegen konstanter Werte einen Eintrag in /etc/sysctl.conf hinzu . Details sind unten angegeben.

^{Ändern Sie die Kerneleinstellungen unter MacOS X.}

 # Get the value of SHMMAX sudo sysctl kern.sysv.shmmax kern.sysv.shmmax: 4096 # Get the value of SHMALL sudo sysctl kern.sysv.shmall kern.sysv.shmall: 4096 # Set the value of SHMMAX sudo sysctl -w kern.sysv.shmmax=16777216 kern.sysv.shmmax: 4096 -> 16777216 # Set the value of SHMALL sudo sysctl -w kern.sysv.shmall=16777216 kern.sysv.shmall: 4096 -> 16777216

^{Ändern der Linux-Kernelparameter}

 # Get the value of SHMMAX sudo sysctl kernel.shmmax kernel.shmmax: 4096 # Get the value of SHMALL sudo sysctl kernel.shmall kernel.shmall: 4096 # Set the value of SHMMAX sudo sysctl -w kernel.shmmax=16777216 kernel.shmmax: 4096 -> 16777216 # Set the value of SHMALL sudo sysctl -w kernel.shmall=16777216 kernel.shmall: 4096 -> 16777216

_{Denken Sie daran : Um Änderungen dauerhaft zu machen, fügen Sie diese Werte zu /etc/sysctl.conf hinzu}

Große Seiten (riesige Seiten)

Linux verwendet standardmäßig 4K-Seiten, BSD verwendet Super Pages und Windows verwendet Large Pages . Eine Seite ist ein Stück RAM, das einem Prozess zugewiesen ist. Ein Prozess kann je nach Speicherbedarf mehrere Seiten umfassen. Je mehr Speicher ein Prozess benötigt, desto mehr Seiten wurden ihm zugewiesen. Das Betriebssystem unterstützt eine Seitenzuordnungstabelle für Prozesse. Je kleiner die Seitengröße, desto größer die Tabelle, desto länger dauert es, eine Seite in dieser Seitentabelle zu finden. Auf großen Seiten können Sie daher eine große Menge an Speicher mit reduziertem Overhead verwenden. weniger Seitenaufrufe, weniger Seitenfehler, schnellere Lese- / Schreibvorgänge durch große Puffer. Das Ergebnis ist eine verbesserte Leistung.

PostgreSQL unterstützt nur große Seiten unter Linux. Standardmäßig verwendet Linux 4 KB Speicherseiten. Wenn Sie also zu viele Speicheroperationen haben, müssen Sie größere Seiten installieren. Bei Verwendung großer Seiten mit 2 MB und bis zu 1 GB ergibt sich ein Leistungsgewinn. Beim Booten kann eine große Seitengröße eingestellt werden. Mit dem Befehl cat / proc / meminfo | können Sie die Parameter der großen Seite und ihre Verwendung auf Ihrem Linux-Computer einfach überprüfen grep -i riesig .

^{Informationen zu großen Seiten erhalten (nur Linux)}

 Note: This is only for Linux, for other OS this operation is ignored$ cat /proc/meminfo | grep -i huge AnonHugePages:        0 kB ShmemHugePages:       0 kB HugePages_Total:      0 HugePages_Free:       0 HugePages_Rsvd:       0 HugePages_Surp:       0 Hugepagesize:      2048 kB

In diesem Beispiel beträgt die Gesamtzahl der großen Seiten 0, obwohl die Größe großer Seiten auf 2048 (2 MB) festgelegt ist. Dies bedeutet, dass große Seiten deaktiviert sind.

Skript zur Bestimmung der Anzahl großer Seiten

Dieses einfache Skript gibt die erforderliche Anzahl großer Seiten zurück. Führen Sie das Skript auf Ihrem Linux-Server aus, während PostgreSQL ausgeführt wird. Stellen Sie sicher, dass das PostgreSQL-Datenverzeichnis für die Umgebungsvariable $ PGDATA festgelegt ist.

^{Abrufen der Anzahl der erforderlichen großen Seiten}

 #!/bin/bash pid=`head -1 $PGDATA/postmaster.pid` echo "Pid:           $pid" peak=`grep ^VmPeak /proc/$pid/status | awk '{ print $2 }'` echo "VmPeak:          $peak kB" hps=`grep ^Hugepagesize /proc/meminfo | awk '{ print $2 }'` echo "Hugepagesize:  $hps kB" hp=$((peak/hps)) echo Set Huge Pages:    $hp

Die Skriptausgabe lautet wie folgt:

^{Skriptausgabe}

 Pid:           12737 VmPeak:        180932 kB Hugepagesize:  2048 kB Set Huge Pages: 88

Der empfohlene Wert für große Seiten ist 88, daher sollten Sie ihn auf 88 setzen.

^{Installieren Sie große Seiten}

 sysctl -w vm.nr_hugepages=88

Überprüfen Sie jetzt große Seiten. Sie werden feststellen, dass keine großen Seiten verwendet werden (HugePages_Free = HugePages_Total).

^{Wieder Informationen zu großen Seiten (nur Linux)}

 $ cat /proc/meminfo | grep -i huge AnonHugePages:        0 kB ShmemHugePages:       0 kB HugePages_Total:     88 HugePages_Free:      88 HugePages_Rsvd:       0 HugePages_Surp:       0 Hugepagesize:      2048 kB

Setzen Sie nun large_pages auf $ PGDATA / postgresql.conf und starten Sie den Server neu.

^{Und wieder Informationen zu großen Seiten (nur Linux)}

 $ cat /proc/meminfo | grep -i huge AnonHugePages:        0 kB ShmemHugePages:       0 kB HugePages_Total:     88 HugePages_Free:      81 HugePages_Rsvd:       64 HugePages_Surp:       0 Hugepagesize:      2048 kB

Jetzt können Sie sehen, dass nur sehr wenige große Seiten verwendet werden. Versuchen wir nun, der Datenbank einige Daten hinzuzufügen.

^{Einige Datenbankoperationen zum Recycling großer Seiten}

 postgres=# CREATE TABLE foo(a INTEGER); CREATE TABLE postgres=# INSERT INTO foo VALUES(generate_Series(1,10000000)); INSERT 0 10000000

Mal sehen, ob wir jetzt mehr große Seiten als zuvor verwenden.

^{Nochmals Informationen auf großen Seiten (nur Linux)}

 $ cat /proc/meminfo | grep -i huge AnonHugePages:        0 kB ShmemHugePages:       0 kB HugePages_Total:     88 HugePages_Free:      18 HugePages_Rsvd:       1 HugePages_Surp:       0 Hugepagesize:      2048 kB

Jetzt können Sie sehen, dass die meisten großen Seiten verwendet werden.

_{Hinweis: Der ungefähre Wert für HugePages, der hier verwendet wird, ist sehr niedrig. Dies ist kein normaler Wert für eine Maschine in einer Lebensmittelumgebung.} _{Bitte bewerten Sie die erforderliche Anzahl von Seiten für Ihr System und stellen Sie sie je nach Auslastung und Ressourcen entsprechend ein.}

vm.swappiness

vm.swappiness ist ein weiterer Kernel-Parameter, der die Datenbankleistung beeinträchtigen kann. Dieser Parameter wird verwendet, um das Swappiness-Verhalten (Austauschen von Seiten in und aus dem Speicher) unter Linux zu steuern. Der Wert reicht von 0 bis 100. Er bestimmt, wie viel Speicher entladen oder entladen wird. Null bedeutet, den Austausch zu deaktivieren, und 100 bedeutet aggressiven Austausch.

Sie können eine gute Leistung erzielen, indem Sie niedrigere Werte einstellen.

Das Setzen des Werts auf 0 in neueren Kerneln kann dazu führen, dass OOM Killer (Linux-Speicherbereinigungsprozess) den Prozess beendet. Daher können Sie den Wert sicher auf 1 setzen, wenn Sie das Austauschen minimieren möchten. Der Standardwert unter Linux ist 60. Ein höherer Wert bewirkt, dass die MMU (Speicherverwaltungseinheit) mehr Paging-Speicherplatz als RAM verwendet, während ein niedrigerer Wert mehr Daten / Code im Speicher spart.

Ein niedrigerer Wert ist eine gute Wette zur Verbesserung der Leistung in PostgreSQL.

vm.overcommit_memory / vm.overcommit_ratio

Anwendungen erhalten Speicher und geben ihn frei, wenn er nicht mehr benötigt wird. In einigen Fällen erhält die Anwendung jedoch zu viel Speicher und gibt ihn nicht frei. Dies kann einen OOM-Killer verursachen. Hier sind die möglichen Werte für den Parameter vm.overcommit_memory mit einer Beschreibung für jeden:

Heuristisches Overcommit (Standard); kernbasierte Heuristik
Überbeanspruchung trotzdem zulassen
Übertreiben Sie es nicht, überschreiten Sie nicht das Overcommit-Verhältnis.

Link: https://www.kernel.org/doc/Documentation/vm/overcommit-accounting

vm.overcommit_ratio - Prozentsatz des RAM, der zum Überladen verfügbar ist. Ein Wert von 50% in einem System mit 2 GB RAM kann bis zu 3 GB RAM zuweisen.

Der Wert 2 für vm.overcommit_memory bietet eine bessere Leistung für PostgreSQL. Dieser Wert maximiert die RAM-Nutzung durch den Serverprozess, ohne dass ein erhebliches Risiko besteht, durch den OOM-Killerprozess getötet zu werden. Die Anwendung kann neu gestartet werden, jedoch nur im Rahmen der Mehrausgaben, wodurch das Risiko verringert wird, dass der OOM-Killer den Prozess abbricht. Daher ergibt ein Wert von 2 eine bessere Leistung als der Standardwert von 0. Die Zuverlässigkeit kann jedoch verbessert werden, indem sichergestellt wird, dass Speicher außerhalb des zulässigen Bereichs nicht überlastet wird. Dies eliminiert das Risiko, dass der Prozess vom OOM-Killer getötet wird.

Auf Systemen ohne Paging kann ein Problem mit vm.overcommit_memory gleich 2 auftreten.

https://www.postgresql.org/docs/current/static/kernel-resources.html#LINUX-MEMORY-OVERCOMMIT

vm.dirty_background_ratio / vm.dirty_background_bytes

vm.dirty_background_ratio ist der Prozentsatz des Speichers, der mit schmutzigen Seiten gefüllt ist, die auf die Festplatte geschrieben werden müssen. Im Hintergrund auf die Festplatte zurücksetzen. Der Wert dieses Parameters reicht von 0 bis 100; Ein Wert unter 5 kann jedoch ineffizient sein, und einige Kernel unterstützen ihn nicht. 10 ist der Standardwert auf den meisten Linux-Systemen. Sie können die Leistung für intensive Aufnahmevorgänge mit einer geringeren Rate verbessern, was bedeutet, dass Linux schmutzige Seiten im Hintergrund ablegt.

Sie müssen den Wert von vm.dirty_background_bytes abhängig von der Geschwindigkeit Ihrer Festplatte festlegen .

Für diese beiden Parameter gibt es keine „guten“ Werte, da beide hardwareabhängig sind. Wenn Sie jedoch vm.dirty_background_ratio auf 5 und vm.dirty_background_bytes auf 25% der Festplattengeschwindigkeit setzen, wird die Leistung in den meisten Fällen auf ~ 25% erhöht.

vm.dirty_ratio / dirty_bytes

Dies ist dasselbe wie vm.dirty_background_ratio / dirty_background_bytes , außer dass das Zurücksetzen in einer Arbeitssitzung durchgeführt wird, wodurch die Anwendung blockiert wird. Daher sollte vm.dirty_ratio höher sein als vm.dirty_background_ratio . Dadurch wird sichergestellt, dass Hintergrundprozesse früher gestartet werden, um zu vermeiden, dass die Anwendung so weit wie möglich blockiert wird. Sie können die Differenz zwischen diesen beiden Verhältnissen abhängig von der Festplatten-E / A-Last anpassen.

Zusammenfassung

Sie können andere Parameter konfigurieren, um die Produktivität zu steigern. Die Verbesserungen sind jedoch minimal und Sie erhalten nicht viel Nutzen. Wir müssen uns daran erinnern, dass nicht alle Parameter für alle Arten von Anwendungen gelten. Einige Anwendungen funktionieren besser, wenn wir einige Einstellungen konfigurieren, andere nicht. Sie müssen das richtige Gleichgewicht zwischen den Konfigurationen dieser Parameter für die erwartete Arbeitslast und den Anwendungstyp finden und beim Einrichten das Verhalten des Betriebssystems berücksichtigen. Das Konfigurieren von Kernelparametern ist nicht so einfach wie das Optimieren von Datenbankparametern: Es ist schwieriger, hier Ihre Empfehlungen abzugeben.

Optimieren der Linux-Kernelparameter zur Optimierung von PostgreSQL