Die optimale Leistung von PostgreSQL hängt von korrekt definierten Betriebssystemparametern ab. Schlecht konfigurierte Betriebssystemkerneleinstellungen können zu einer schlechten Leistung des Datenbankservers führen. Daher ist es unbedingt erforderlich, dass diese Einstellungen entsprechend dem Datenbankserver und seiner Arbeitslast konfiguriert werden. In diesem Beitrag besprechen wir einige wichtige Linux-Kernel-Parameter, die sich auf die Leistung des Datenbankservers auswirken können, und wie man sie konfiguriert.
SHMMAX / SHMALL
SHMMAX ist ein Kernel-Parameter, der verwendet wird, um die maximale Größe eines einzelnen gemeinsam genutzten Speichersegments zu bestimmen, das ein Linux-Prozess zuweisen kann. Vor Version 9.2 verwendete PostgreSQL System V (SysV), das die SHMMAX-Einstellung erfordert. Nach 9.2 wechselte PostgreSQL zum POSIX-Shared-Memory. Daher sind jetzt weniger Bytes des gemeinsam genutzten Speichers von System V erforderlich.
Vor Version 9.3 war SHMMAX der wichtigste Kernel-Parameter. Der SHMMAX-Wert wird in Bytes angegeben.
In ähnlicher Weise SCHMALL ist ein weiterer Kernel-Parameter, der zur Bestimmung verwendet wird
systemweites Volumen gemeinsam genutzter Speicherseiten. Um die aktuellen SHMMAX-, SHMALL- oder SHMMIN-Werte anzuzeigen, verwenden Sie den Befehl ipcs.
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) = 1SHM*-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 gemeinsamen Speicher zuzuweisen. Dieser Parameter ist einer der wichtigsten Kernel-Parameter. Wenn Sie die folgenden Fehlermeldungen erhalten, bedeutet dies, dass Sie eine ältere Version von PostgreSQL haben und Ihr SHMMAX-Wert sehr niedrig ist. Von Benutzern wird erwartet, dass sie 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, erhalten Sie möglicherweise eine Fehlermeldung, wenn Sie versuchen, einen PostgreSQL-Cluster mit dem Befehl zu initialisieren initdb.
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 es sein, dass Sie beim Starten des PostgreSQL-Servers mit dem Befehl eine Fehlermeldung erhalten pg_ctl.
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.
Die Unterschiede in den Definitionen verstehen
Die Definition der SHMMAX/SHMALL-Parameter unterscheidet sich geringfügig unter Linux und MacOS X:
- Linux: kernel.shmmax, kernel.shmall
- MacOS X: kern.sysv.shmmax, kern.sysv.shmall
Team sysctl kann verwendet werden, um den Wert vorübergehend zu ändern. Um konstante Werte festzulegen, fügen Sie einen Eintrag hinzu /etc/sysctl.conf. Einzelheiten finden Sie weiter unten.
Ändern der Kernel-Einstellungen 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 Kernel-Parameter unter Linux
# 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 -> 16777216Vergessen Sie nicht: Um Änderungen dauerhaft zu machen, fügen Sie diese Werte zu /etc/sysctl.conf hinzu
Riesige Seiten
Linux verwendet standardmäßig 4-KB-Speicherseiten, BSD verwendet XNUMX-KB-Speicherseiten. Super-Seiten, und unter Windows - Große Seiten. Eine Seite ist ein Teil des RAM, der einem Prozess zugewiesen ist. Ein Prozess kann je nach Speicherbedarf mehrere Seiten haben. Je mehr Speicher ein Prozess benötigt, desto mehr Seiten werden ihm zugewiesen. Das Betriebssystem verwaltet 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. Große Seiten ermöglichen daher die Nutzung großer Speichermengen bei geringerem Overhead; weniger Seitenaufrufe, weniger Seitenfehler, schnellere Lese-/Schreibvorgänge über größere Puffer. Das Ergebnis ist eine verbesserte Leistung.
PostgreSQL unterstützt unter Linux nur große Seiten. Standardmäßig verwendet Linux 4-KB-Speicherseiten. In Fällen, in denen zu viele Speichervorgänge ausgeführt werden, ist es daher erforderlich, größere Seiten festzulegen. Bei der Verwendung großer Seiten von 2 MB bis zu 1 GB werden Leistungssteigerungen beobachtet. Die große Seitengröße kann beim Booten eingestellt werden. Mit dem Befehl können Sie die großen Seitenparameter und deren Verwendung auf Ihrem Linux-Rechner ganz einfach überprüfen cat /proc/meminfo | grep -i riesig.
Informationen über große Seiten abrufen (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 kBObwohl in diesem Beispiel die große Seitengröße auf 2048 (2 MB) eingestellt ist, ist die Gesamtzahl der großen Seiten auf 0 gesetzt. Dies bedeutet, dass große Seiten deaktiviert sind.
Skript zur Ermittlung 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 dies für die Umgebungsvariable gilt $PGDATA Das PostgreSQL-Datenverzeichnis ist angegeben.
Ermitteln 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: $hpDie Skriptausgabe sieht folgendermaßen aus:
Skriptausgabe
Pid: 12737
VmPeak: 180932 kB
Hugepagesize: 2048 kB
Set Huge Pages: 88Der empfohlene Wert für große Seiten beträgt 88, daher sollten Sie ihn auf 88 einstellen.
Große Seiten installieren
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).
Große Seiten überarbeitet (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 kBSetzen Sie nun den Parameter huge_pages in $PGDATA/postgresql.conf auf „on“ und starten Sie den Server neu.
Nochmals 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 kBJetzt können Sie sehen, dass nur sehr wenige große Seiten verwendet werden. Versuchen wir nun, einige Daten zur Datenbank 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 10000000Mal sehen, ob wir jetzt mehr große Seiten als zuvor verwenden.
Weitere Informationen zu 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 kBJetzt können Sie sehen, dass die meisten großen Seiten verwendet werden.
Hinweis: Der hier verwendete geschätzte Wert für HugePages ist sehr niedrig, was kein normaler Wert für einen Computer ist, auf dem eine Produktumgebung ausgeführt wird. Bitte schätzen Sie die benötigte Seitenanzahl für Ihr System ab und stellen Sie diese je nach Auslastung und Ressourcen entsprechend ein.
vm.swappiness
vm.swappiness ist ein weiterer Kernel-Parameter, der sich auf die Datenbankleistung auswirken kann. Diese Option wird verwendet, um das Verhalten von Swappiness (Auslagern von Seiten in und aus dem Speicher) unter Linux zu steuern. Der Wert liegt zwischen 0 und 100. Er bestimmt, wie viel Speicher ausgelagert oder ausgelagert wird. Null bedeutet keinen Austausch und 100 bedeutet aggressiven Austausch.
Sie können eine gute Leistung erzielen, indem Sie niedrigere Werte einstellen.
Wenn Sie diesen Wert auf neueren Kerneln auf 0 setzen, kann dies dazu führen, dass OOM Killer (der Speicherbereinigungsprozess von Linux) den Prozess abbricht. Daher ist es sicher, den Wert auf 1 zu setzen, wenn Sie das Vertauschen minimieren möchten. Der Standardwert unter Linux ist 60. Ein höherer Wert führt dazu, dass die MMU (Speicherverwaltungseinheit) mehr Auslagerungsspeicher als RAM verwendet, während ein niedrigerer Wert mehr Daten/Code im Speicher behält.
Ein niedrigerer Wert ist eine gute Wahl für eine verbesserte Leistung in PostgreSQL.
vm.overcommit_memory / vm.overcommit_ratio
Anwendungen erwerben Speicher und geben ihn frei, wenn er nicht mehr benötigt wird. In manchen Fällen erhält die Anwendung jedoch zu viel Speicher und gibt ihn nicht frei. Dies kann zu einem OOM-Killer führen. Hier sind die möglichen Parameterwerte vm.overcommit_memory mit jeweils einer Beschreibung:
- Heuristisches Overcommit (Standard); Kernelbasierte Heuristik
- Overcommit trotzdem zulassen
- Übertreiben Sie es nicht und überschreiten Sie nicht das Overcommit-Verhältnis.
Link:
vm.overcommit_ratio – Prozentsatz des für Überlastung verfügbaren RAM. Ein Wert von 50 % auf einem System mit 2 GB RAM kann bis zu 3 GB RAM zuweisen.
Ein Wert von 2 für vm.overcommit_memory bietet eine bessere Leistung für PostgreSQL. Dieser Wert maximiert die RAM-Nutzung des Serverprozesses, ohne dass ein nennenswertes Risiko besteht, vom OOM-Killerprozess getötet zu werden. Die Anwendung kann neu geladen werden, jedoch nur innerhalb der Grenzen des Überlaufs, wodurch das Risiko verringert wird, dass ein OOM-Killer den Prozess abbricht. Daher bietet ein Wert von 2 eine bessere Leistung als der Standardwert von 0. Die Zuverlässigkeit kann jedoch verbessert werden, indem sichergestellt wird, dass der Speicher außerhalb des zulässigen Bereichs nicht überlastet wird. Dadurch wird das Risiko eliminiert, dass der Prozess durch einen OOM-Killer abgebrochen wird.
Auf Systemen ohne Swapping kann ein Problem auftreten, wenn vm.overcommit_memory gleich 2 ist.
vm.dirty_background_ratio / vm.dirty_background_bytes
vm.dirty_background_ratio ist der Prozentsatz des Speichers, der mit fehlerhaften Seiten gefüllt ist, die auf die Festplatte geschrieben werden müssen. Das Flushen auf die Festplatte erfolgt im Hintergrund. Der Wert dieses Parameters liegt zwischen 0 und 100; Ein Wert unter 5 ist jedoch möglicherweise unwirksam und wird von einigen Kerneln nicht unterstützt. 10 ist auf den meisten Linux-Systemen die Standardeinstellung. Sie können die Leistung für schreibintensive Vorgänge um einen kleineren Faktor verbessern, was bedeutet, dass Linux fehlerhafte Seiten im Hintergrund leert.
Sie müssen den Wert festlegen vm.dirty_background_bytes Abhängig von der Geschwindigkeit Ihres Laufwerks.
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, verbessert sich die Leistung in den meisten Fällen auf etwa 25 %.
vm.dirty_ratio/dirty_bytes
Dies ist das gleiche wie vm.dirty_background_ratio/dirty_background_bytes, mit der Ausnahme, dass das Zurücksetzen in einer Worker-Sitzung durchgeführt wird und die Anwendung blockiert. Daher sollte vm.dirty_ratio höher sein als vm.dirty_background_ratio. Dadurch wird sichergestellt, dass Hintergrundprozesse früher starten, um eine Blockierung der Anwendung möglichst zu vermeiden. Sie können den Unterschied zwischen diesen beiden Verhältnissen je nach Festplatten-E/A-Last anpassen.
Ergebnis
Sie können andere Einstellungen anpassen, um die Leistung zu verbessern, aber die Verbesserungen werden minimal sein und Sie werden keinen großen Nutzen sehen. Wir müssen bedenken, dass nicht alle Optionen für alle Arten von Anwendungen gelten. Einige Apps funktionieren besser, wenn wir einige Einstellungen anpassen, andere nicht. Sie müssen das richtige Gleichgewicht zwischen der Konfiguration dieser Einstellungen für Ihre erwartete Arbeitslast und Ihren Anwendungstyp finden und bei der Optimierung auch das Betriebssystemverhalten berücksichtigen. Das Konfigurieren von Kernel-Parametern ist nicht so einfach wie das Konfigurieren von Datenbankparametern; es ist schwieriger, Empfehlungen abzugeben.
Source: habr.com