Die optimale Leistung von PostgreSQL hängt von korrekt definierten Betriebssystemparametern ab. Schlecht konfigurierte Kernparameter des Betriebssystems können die Leistung des Datenbankservers beeinträchtigen. Daher ist es wichtig, diese Parameter an den Datenbankserver und dessen Arbeitslast anzupassen. In diesem Beitrag werden wir einige wichtige Linux-Kernelparameter besprechen, die die Leistung des Datenbankservers beeinflussen können, sowie Methoden zu deren Anpassung.
SHMMAX / SHMALL
SHMMAX ist ein Kernelparameter, der zum Festlegen der maximalen Größe eines Segments des gemeinsamen Speichers (shared memory) verwendet wird, das ein Linux-Prozess zuweisen kann. Bis zur Version 9.2 verwendete PostgreSQL System V (SysV), für das eine Anpassung von SHMMAX erforderlich ist. Nach Version 9.2 wechselte PostgreSQL zu POSIX-gemeinsamem Speicher. Daher wird jetzt weniger Bytes gemeinsam genutzter Speicher von System V benötigt.
Bis zur Version 9.3 war SHMMAX der wichtigste Kernelparameter. Der Wert von SHMMAX wird in Bytes festgelegt.
Ebenso SHMALL ist ein weiterer Kernelparameter, der zur Bestimmung
Der gesamte Speicherplatz für gemeinsam genutzten Speicher (shared memory). Um die aktuellen Werte für SHMMAX, SHMALL oder SHMMIN zu überprüfen, verwenden Sie den Befehl ipcs.
SHM* Details — Linux
$ ipcs -lm
------ Limits für gemeinsamen Speicher --------
max. Anzahl der Segmente = 4096
max. Segmentgröße (kbytes) = 1073741824
max. gesamter gemeinsamer Speicher (kbytes) = 17179869184
min. Segmentgröße (bytes) = 1SHM* Details — MacOS X
$ ipcs -M
IPC-Status von am Thu Aug 16 22:20:35 PKT 2018
shminfo:
shmmax: 16777216 (max. Größe des gemeinsamen Speichersegments)
shmmin: 1 (min. Größe des gemeinsamen Speichersegments)
shmmni: 32 (max. Anzahl der Identifikatoren für gemeinsamen Speicher)
shmseg: 8 (max. Anzahl der gemeinsam genutzten Segmente pro Prozess)
shmall: 1024 (max. Menge an gemeinsam genutztem Speicher in Seiten)
PostgreSQL verwendet System V IPC zur Zuweisung von gemeinsam genutztem Speicher. Dieser Parameter ist einer der wichtigsten Kernparameter. Jedes Mal, wenn Sie die folgenden Fehlermeldungen erhalten, bedeutet dies, dass Sie eine ältere Version von PostgreSQL verwenden und der Wert für SHMMAX sehr niedrig ist. Es wird erwartet, dass die Benutzer den Wert anpassen und entsprechend dem gemeinsam genutzten Speicher erhöhen, den sie verwenden möchten.
Mögliche Fehler durch falsche Konfiguration
Wenn SHMMAX falsch konfiguriert ist, kann es zu einem Fehler kommen, wenn Sie versuchen, einen PostgreSQL-Cluster mithilfe des Befehls initdb.
initdb Fehler
DETAIL: Der fehlgeschlagene Systemaufruf war shmget(key=1, size=2072576, 03600).
HINWEIS: Dieser Fehler bedeutet in der Regel, dass die Anfrage von PostgreSQL nach einem gemeinsamen Speichersegment das SHMMAX-Parameter Ihres Kernels überschreitet.
Sie können entweder die Anforderungsgröße reduzieren oder den Kernel mit einem größeren SHMMAX neu konfigurieren. Um die Anforderungsgröße (derzeit 2072576 Bytes) zu reduzieren,
reduzieren Sie die Nutzung des gemeinsamen Speichers von PostgreSQL, möglicherweise durch Reduzierung der shared_buffers oder max_connections.
Falls die Anforderungsgröße bereits klein ist, könnte sie möglicherweise kleiner sein als das SHMMIN-Parameter Ihres Kernels,
in diesem Fall ist es erforderlich, entweder die Anforderungsgröße zu erhöhen oder SHMMIN neu zu konfigurieren.
Die PostgreSQL-Dokumentation enthält weitere Informationen zur Konfiguration des gemeinsamen Speichers. Der Kindprozess wurde mit dem Fehlercode 1 beendet.
Ähnlich könnten Sie einen Fehler erhalten, wenn Sie den PostgreSQL-Server mit dem Befehl pg_ctl.
pg_ctl Fehler
DETAILS: Der fehlgeschlagene Systemaufruf war shmget(key=5432001, size=14385152, 03600).
HINWEIS: Dieser Fehler bedeutet in der Regel, dass die Anfrage von PostgreSQL nach einem gemeinsamen Speichersegment das SHMMAX-Parameter Ihres Kernels überschreitet.
Sie können entweder die Anforderungsgröße reduzieren oder den Kernel mit einem größeren SHMMAX neu konfigurieren. Um die Anforderungsgröße (derzeit 14385152 Bytes) zu reduzieren, reduzieren Sie die Nutzung des gemeinsamen Speichers von PostgreSQL, möglicherweise durch Reduzierung der shared_buffers oder max_connections.
Falls die Anforderungsgröße bereits klein ist, könnte sie möglicherweise kleiner sein als das SHMMIN-Parameter Ihres Kernels,
in diesem Fall ist es erforderlich, entweder die Anforderungsgröße zu erhöhen oder SHMMIN neu zu konfigurieren.
Die PostgreSQL-Dokumentation enthält weitere Informationen zur Konfiguration des gemeinsamen Speichers.
Verständnis der Unterschiede in den Definitionen
Die Definitionen der Parameter SHMMAX/SHMALL unterscheiden sich leicht zwischen Linux und MacOS X:
- Linux: kernel.shmmax, kernel.shmall
- MacOS X: kern.sysv.shmmax, kern.sysv.shmall
Der Befehl sysctl kann verwendet werden, um den Wert vorübergehend zu ändern. Um dauerhafte Werte zu setzen, fügen Sie einen Eintrag hinzu in /etc/sysctl.conf. Weitere Details finden Sie unten.
Änderung der Kernelparameter 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Änderung der Kernelparameter 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 die Änderungen dauerhaft zu machen, fügen Sie diese Werte in /etc/sysctl.conf ein
Große Seiten (Huge Pages)
In Linux werden standardmäßig 4 KB Speicherseiten verwendet, in BSD — Super Pages, und in Windows — Large Pages. Eine Seite ist ein Teil des Arbeitsspeichers, der einem Prozess zugewiesen ist. Ein Prozess kann je nach Speicheranforderungen mehrere Seiten haben. Je mehr Speicher ein Prozess benötigt, desto mehr Seiten werden ihm zugewiesen. Das Betriebssystem verwaltet eine Tabelle zur Zuweisung von Seiten für Prozesse. Je kleiner die Seiten, desto größer die Tabelle, was die Suche nach Seiten in dieser Seitentabelle zeitaufwändiger macht. Daher ermöglichen große Seiten die Nutzung von großen Speicherbereichen mit reduzierten Overheads: weniger Seitenaufrufe, weniger Seitenfehler, schnellere Lese-/Schreibvorgänge durch größere Puffer. Dies führt zu einer Leistungsverbesserung.
PostgreSQL unterstützt große Seiten nur unter Linux. Standardmäßig verwendet Linux 4 KB große Speicherseiten. Daher sollten bei einer hohen Anzahl an Speichervorgängen größere Seiten eingerichtet werden. Mit großen Seiten von 2 MB bis zu 1 GB kann eine Leistungssteigerung beobachtet werden. Die Größe der großen Seite kann beim Systemstart festgelegt werden. Sie können die Parameter für große Seiten und deren Nutzung auf Ihrem Linux-Rechner einfach mit dem folgenden Befehl überprüfen: cat /proc/meminfo | grep -i huge.
Informationen zu großen Seiten abrufen (nur unter Linux)
Hinweis: Dies gilt nur für Linux, bei anderen Betriebssystemen wird dieser Vorgang ignoriert$ 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 kBIn diesem Beispiel, obwohl die Größe der großen Seite auf 2048 (2 MB) eingestellt ist, hat die Gesamtzahl der großen Seiten den Wert 0. Das bedeutet, dass große Seiten deaktiviert sind.
Skript zur Bestimmung der Anzahl der großen Seiten
Dieses einfache Script gibt die benötigte Anzahl an großen Seiten zurück. Führen Sie das Script auf Ihrem Linux-Server aus, während PostgreSQL läuft. Stellen Sie sicher, dass die Umgebungsvariable $PGDATA auf das Datenverzeichnis von PostgreSQL gesetzt ist.
Ermittlung der Anzahl der benötigten 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 Ausgabe des Scripts sieht folgendermaßen aus:
Script-Ausgabe
Pid: 12737
VmPeak: 180932 kB
Hugepagesize: 2048 kB
Set Huge Pages: 88Der empfohlene Wert für große Seiten liegt bei 88, daher sollten Sie den Wert auf 88 setzen.
Einstellung der großen Seiten
sysctl -w vm.nr_hugepages=88Überprüfen Sie jetzt die großen Seiten, Sie werden sehen, dass große Seiten nicht verwendet werden (HugePages_Free = HugePages_Total).
Weitere Informationen zu großen Seiten (nur unter 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 jetzt die Option huge_pages auf 'on' in $PGDATA/postgresql.conf und starten Sie den Server neu.
Und wieder Informationen zu großen Seiten (nur unter 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. Lassen Sie uns nun versuchen, einige Daten in die Datenbank einzufügen.
Einige Datenbankoperationen zur Verwendung von großen Seiten
postgres=# CREATE TABLE foo(a INTEGER);
CREATE TABLE
postgres=# INSERT INTO foo VALUES(generate_Series(1,10000000));
INSERT 0 10000000Lassen Sie uns überprüfen, ob wir jetzt mehr große Seiten verwenden als zuvor.
Noch einmal Informationen zu großen Seiten (nur unter 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 ungefähre Wert für HugePages ist sehr niedrig und entspricht nicht den normalen Werten für eine Produktionsumgebung. Bitte schätzen Sie die erforderliche Anzahl von Seiten für Ihr System und konfigurieren Sie diese entsprechend basierend auf der Last und den Ressourcen.
vm.swappiness
vm.swappiness — ist ein weiterer Kernparameter, der die Leistung der Datenbank beeinflussen kann. Dieser Parameter steuert das Verhalten des Swappings (den Seitenwechsel in den Speicher und zurück) in Linux. Der Wert variiert von 0 bis 100. Er bestimmt, wie viel Speicher freigegeben oder ausgelagert wird. Null bedeutet, dass das Swapping deaktiviert ist, während 100 aggressives Swapping bedeutet.
Sie können eine gute Leistung erzielen, indem Sie niedrigere Werte einstellen.
Das Setzen des Wertes 0 in neueren Kernen kann dazu führen, dass der OOM Killer (Prozess zur Speicherbereinigung in Linux) Prozesse beendet. Daher kann ein Wert von 1 sicher gesetzt werden, wenn Sie das Swapping minimieren möchten. Der Standardwert in Linux beträgt 60. Ein höherer Wert sorgt dafür, dass die MMU (Memory Management Unit) mehr Swap-Raum als RAM verwendet, während ein niedrigerer Wert mehr Daten und Code im Speicher hält.
Ein geringerer Wert ist eine gute Wahl 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 kann es jedoch vorkommen, dass eine Anwendung zu viel Speicher zugewiesen bekommt und ihn nicht freigibt. Dies kann den OOM-Killer auslösen. Hier sind mögliche Werte für die Konfiguration: vm.overcommit_memory mit einer Beschreibung für jede:
- Heuristische Überbelegung (Standard); kernelbasierte Heuristik
- Überbelegung in jedem Fall zulassen
- Seien Sie vorsichtig, überschreiten Sie nicht den Überbelegungsfaktor.
Link:
vm.overcommit_ratio — der Prozentsatz des Arbeitsspeichers, der für eine Überbelegung zur Verfügung steht. 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 sorgt für eine bessere Leistung von PostgreSQL. Dieser Wert maximiert die Nutzung des Arbeitsspeichers durch den Serverprozess, ohne dass ein nennenswertes Risiko besteht, vom OOM-Killer beendet zu werden. Die Anwendung kann neu gestartet werden, aber nur innerhalb des Überverbrauchs, wodurch das Risiko verringert wird, dass der OOM-Killer den Prozess beendet. Daher bietet der Wert 2 eine bessere Leistung als der Standardwert 0. Dennoch kann die Zuverlässigkeit verbessert werden, indem vermieden wird, dass der Speicher über den zulässigen Bereich hinaus belastet wird. Das schließt das Risiko aus, dass der Prozess vom OOM-Killer beendet wird.
In Systemen ohne Swap kann es ein Problem mit vm.overcommit_memory gleich 2 geben.
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. Der Schreibprozess auf die Festplatte erfolgt im Hintergrund. Der Wert dieses Parameters variiert zwischen 0 und 100; jedoch kann ein Wert unter 5 ineffektiv sein, und einige Kernel unterstützen ihn möglicherweise nicht. 10 ist der Standardwert in den meisten Linux-Systemen. Sie können die Leistung bei schreibintensiven Vorgängen verbessern, indem Sie einen niedrigeren Wert verwenden, was bedeutet, dass Linux schmutzige Seiten im Hintergrund ablegen wird.
Sie müssen den Wert vm.dirty_background_bytes abhängig von der Geschwindigkeit Ihrer Festplatte einstellen.
Für diese beiden Parameter gibt es keine "guten" Werte, da beide von der Hardware abhängen. Allerdings verbessert das Setzen von vm.dirty_background_ratio auf 5 und vm.dirty_background_bytes auf 25 % der Festplattengeschwindigkeit die Leistung in den meisten Fällen um ~ 25 %.
vm.dirty_ratio / dirty_bytes
Das ist dasselbe wie vm.dirty_background_ratio / dirty_background_bytes, mit dem Unterschied, dass der Rückschreibvorgang während der Sitzung erfolgt und die Anwendung blockiert. Daher sollte vm.dirty_ratio höher sein als vm.dirty_background_ratio. Das gewährleistet, dass Hintergrundprozesse früher gestartet werden, um eine maximale Blockierung der Anwendung zu vermeiden. Sie können den Unterschied zwischen diesen beiden Verhältnissen je nach Last der Festplatten-E/A anpassen.
Zusammenfassung
Sie können weitere Parameter anpassen, um die Leistung zu steigern, allerdings werden die Verbesserungen minimal sein und einen besonderen Nutzen bringt es nicht. Wir sollten bedenken, dass nicht alle Parameter auf alle Anwendungsarten zutreffen. Einige Anwendungen profitieren von der Anpassung bestimmter Parameter, andere wiederum nicht. Sie müssen das richtige Gleichgewicht zwischen der Konfiguration dieser Parameter für die erwartete Arbeitslast und Art der Anwendung finden, während auch das Verhalten des Betriebssystems berücksichtigt werden muss. Die Anpassung der Kernel-Parameter ist nicht so einfach wie die der Datenbankparameter; hier ist es schwieriger, Empfehlungen zu geben.
Quelle: habr.com
