Die optimale Leistung von PostgreSQL hängt von den richtig definierten Parametern des Betriebssystems ab. Schlecht konfigurierte Kernel-Parameter können die Leistung des Datenbankservers beeinträchtigen. Daher ist es unbedingt erforderlich, dass diese Parameter entsprechend dem Datenbankserver und seiner Arbeitslast konfiguriert werden. In diesem Beitrag erörtern wir einige wichtige Kernel-Parameter von Linux, die die Leistung des Datenbankservers beeinflussen können, sowie Möglichkeiten zu deren Konfiguration.
SHMMAX / SHMALL
SHMMAX ist ein Kernel-Parameter, der verwendet wird, um die maximale Größe eines Segments des gemeinsam genutzten Speichers (shared memory) zu bestimmen, die ein Linux-Prozess zuweisen kann. Bis Version 9.2 verwendete PostgreSQL System V (SysV), für das eine Konfiguration von SHMMAX erforderlich ist. Nach 9.2 wechselte PostgreSQL zu POSIX-gemeinsamem Speicher. Daher wird jetzt weniger Bytes an System V-gemeinsamem Speicher benötigt.
Bis Version 9.3 war SHMMAX der wichtigste Kernel-Parameter. Der Wert von SHMMAX wird in Bytes festgelegt.
Ähnlich, SHMALL ist ein weiterer Kernel-Parameter, der verwendet wird, um zu bestimmen,
den gesamten verfügbaren Seitenbedarf an gemeinsam genutztem Speicher (shared memory). Um die aktuellen Werte von SHMMAX, SHMALL oder SHMMIN anzuzeigen, verwenden Sie den Befehl ipcs.
SHM* Details — Linux
$ ipcs -lm
------ Gemeinsamer Speichergrenzen --------
max Anzahl der Segmente = 4096
max Segmentgröße (Kbytes) = 1073741824
max gesamter gemeinsam genutzter 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 (maximaler gemeinsam genutzter Speichersegmentgröße)
shmmin: 1 (minimaler gemeinsam genutzter Speichersegmentgröße)
shmmni: 32 (max Anzahl der gemeinsam genutzten Speicherbezeichner)
shmseg: 8 (max Anzahl der gemeinsam genutzten Speichersegmente pro Prozess)
shmall: 1024 (maximaler gemeinsamer Speicher in Seiten)
PostgreSQL verwendet System V IPC zur Zuweisung von gemeinsamem Speicher. Dieser Parameter gehört zu den wichtigsten Kernel-Parametern. Jedes Mal, wenn Sie die folgenden Fehlermeldungen erhalten, bedeutet dies, dass Sie eine ältere Version von PostgreSQL verwenden und einen sehr niedrigen Wert für SHMMAX haben. Es wird erwartet, dass die Benutzer den Wert entsprechend dem gemeinsam genutzten Speicher, den sie verwenden möchten, anpassen und erhöhen.
Mögliche Fehler bei falscher Konfiguration
Wenn SHMMAX falsch konfiguriert ist, kann es zu einem Fehler kommen, wenn Sie versuchen, einen PostgreSQL-Cluster mit dem Befehl zu initialisieren initdb.
initdb Fehler
DETAIL: Der fehlgeschlagene Systemaufruf war shmget(key=1, size=2072576, 03600).
HINWEIS: Dieser Fehler bedeutet normalerweise, dass die Anfrage von PostgreSQL nach einem gemeinsam genutzten Speichersegment den 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 den Speicherverbrauch von PostgreSQL, indem Sie möglicherweise shared_buffers oder max_connections verringern.
Wenn die Anforderungsgröße bereits klein ist, könnte es sein, dass sie kleiner ist als der SHMMIN-Wert Ihres Kernels,
in diesem Fall wäre es notwendig, die Anforderungsgröße zu erhöhen oder SHMMIN neu zu konfigurieren.
Die PostgreSQL-Dokumentation enthält weitere Informationen zur Konfiguration des Shared Memory. Der Kindprozess ist mit dem Exit-Code 1 abgestürzt.
Ähnlich können Sie einen Fehler beim Starten des PostgreSQL-Servers mit dem Befehl pg_ctl.
pg_ctl-Fehler
DETAILS: Der fehlgeschlagene Systemaufruf war shmget(key=5432001, size=14385152, 03600).
HINWEIS: Dieser Fehler bedeutet normalerweise, dass die Anfrage von PostgreSQL nach einem gemeinsam genutzten Speichersegment den 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 den Speicherverbrauch von PostgreSQL, möglicherweise indem Sie shared_buffers oder max_connections verringern.
Wenn die Anforderungsgröße bereits klein ist, könnte es sein, dass sie kleiner ist als der SHMMIN-Wert Ihres Kernels,
in diesem Fall wäre es notwendig, die Anforderungsgröße zu erhöhen oder SHMMIN neu zu konfigurieren.
Die PostgreSQL-Dokumentation enthält weitere Informationen zur Konfiguration des Shared Memory.
Verstehen der Unterschiede in den Definitionen
Die Definition der Parameter SHMMAX/SHMALL unterscheidet sich leicht zwischen 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 permanente Werte festzulegen, fügen Sie einen Eintrag in /etc/sysctl.confhinzu. Einzelheiten finden Sie weiter unten.
Änderung der Kernel-Parameter 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 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 die Änderungen dauerhaft zu machen, fügen Sie diese Werte zu /etc/sysctl.conf hinzu
Große Seiten (Huge Pages)
In Linux werden standardmäßig 4-GB-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 Seitentabelle für die Prozesse. Je kleiner die Seitengröße, desto größer die Tabelle, desto mehr Zeit wird benötigt, um die Seite in dieser Seitentabelle zu finden. Daher ermöglichen große Seiten die Nutzung großer Mengen von Speicher mit reduzierten Overheads; weniger Seitenaufrufe, weniger Seitenfehler, schnellere Lese-/Schreibvorgänge über große Puffer. Das Ergebnis ist eine verbesserte Leistung.
PostgreSQL unterstützt große Seiten nur unter Linux. Standardmäßig verwendet Linux 4 KB Speicherseiten. Daher muss bei einer hohen Anzahl an Speicheroperationen auf größere Seiten umgestellt werden. Es wird eine Leistungssteigerung beim Einsatz von großen Seiten mit 2 MB bis zu 1 GB beobachtet. Die Größe der großen Seite kann beim Booten festgelegt werden. Sie können die Einstellungen und die Nutzung großer Seiten auf Ihrem Linux-Computer leicht überprüfen, indem Sie den Befehl cat /proc/meminfo | grep -i huge.
Informationen über große Seiten abrufen (nur unter Linux)
Hinweis: Dies gilt nur für Linux, für andere Betriebssysteme 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 großer Seiten
Dies ist ein einfaches Skript, das die benötigte Anzahl großer Seiten zurückgibt. Führen Sie das Skript auf Ihrem Linux-Server aus, während PostgreSQL läuft. Stellen Sie sicher, dass die Umgebungsvariable $PGDATA auf das Datenverzeichnis von PostgreSQL gesetzt ist.
Die benötigte Anzahl großer Seiten abrufen
#!/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 Skripts sieht wie folgt aus:
Ausgabe des Skripts
Pid: 12737
VmPeak: 180932 kB
Hugepagesize: 2048 kB
Set Huge Pages: 88Der empfohlene Wert für große Seiten ist 88, daher sollten Sie den Wert 88 einstellen.
Große Seiten einstellen
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).
Erneut Informationen über große 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 nun die Einstellung huge_pages auf "on" in $PGDATA/postgresql.conf und starten Sie den Server neu.
Und wieder Informationen über große 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 sehr wenige große Seiten verwendet werden. Lassen Sie uns jetzt versuchen, einige Daten in die Datenbank einzufügen.
Einige Datenbankoperationen zur Verwaltung 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 sehen, 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 geschätzte Wert für HugePages ist sehr niedrig, was für ein Produktivsystem nicht normal ist. Bitte schätzen Sie die erforderliche Anzahl von Seiten für Ihr System und setzen Sie diese entsprechend abhängig von der Last und den Ressourcen.
vm.swappiness
vm.swappiness — das ist ein weiterer Kernelparameter, der die Datenbankleistung beeinflussen kann. Dieser Parameter wird verwendet, um das Verhalten der Swappiness (Auslagerung von Seiten in den Speicher und zurück) in Linux zu steuern. Der Wert reicht von 0 bis 100. Er bestimmt, wie viel Speicher ausgelagert wird oder ausgelagert werden kann. Null bedeutet Deaktivierung der Auslagerung, während 100 aggressives Auslagern bedeutet.
Sie können eine gute Leistung erzielen, indem Sie niedrigere Werte festlegen.
Das Setzen des Wertes 0 in neueren Kernen kann dazu führen, dass der OOM Killer (Speicherbereinigungsprozess in Linux) einen Prozess beendet. Daher kann sicher der Wert 1 gesetzt werden, wenn Sie die Auslagerung minimieren möchten. Der Standardwert in Linux beträgt 60. Ein höherer Wert zwingt die MMU (Memory Management Unit) dazu, mehr Auslagerungsraum als RAM zu verwenden, während ein niedrigerer Wert mehr Daten/code im Speicher hält.
Ein niedrigerer 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 erhält eine Anwendung jedoch zu viel Speicher und gibt ihn nicht frei. Dies kann den OOM-Killer auslösen. Hier sind mögliche Werte für den Parameter vm.overcommit_memory mit einer Beschreibung für jeden:
- Heuristisches Overcommit (Standard); kernelbasierte Heuristik
- Erlaube Overcommit in jedem Fall
- Übertreibe nicht, überschreite nicht den Overcommit-Verhältnis.
Link:
vm.overcommit_ratio — Prozentsatz des Arbeitsspeichers, der für übermäßige Nutzung 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 sorgt für eine bessere Leistung für PostgreSQL. Dieser Wert maximiert die Nutzung des Arbeitsspeichers durch den Serverprozess, ohne ein signifikantes Risiko, vom OOM-Killer getötet zu werden. Die Anwendung kann sich neu starten, jedoch nur innerhalb des Überverbrauchs, was das Risiko verringert, dass der OOM-Killer den Prozess tötet. Daher bietet der Wert 2 eine bessere Leistung als der Standardwert 0. Dennoch kann die Zuverlässigkeit verbessert werden, da der Speicher außerhalb des zulässigen Bereichs nicht überlastet wird. Dies schließt das Risiko aus, dass der Prozess vom OOM-Killer getötet wird.
In Systemen ohne Swap kann es zu Problemen mit vm.overcommit_memory gleich 2 kommen.
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 Datentransfer auf die Festplatte erfolgt im Hintergrund. Der Wert dieses Parameters liegt zwischen 0 und 100; ein Wert unter 5 kann jedoch ineffektiv sein, und einige Kernel unterstützen ihn nicht. 10 ist der Standardwert in den meisten Linux-Systemen. Sie können die Leistung bei schreibintensiven Operationen mit einem niedrigeren Verhältnis verbessern, was bedeutet, dass Linux schmutzige Seiten im Hintergrund ablegt.
Sie müssen den Wert einstellen vm.dirty_background_bytes abhängig von der Geschwindigkeit Ihrer Festplatte.
Für diese beiden Parameter gibt es keine "guten" Werte, da beide von der Hardware abhängen. Einsetzen von vm.dirty_background_ratio auf 5 und vm.dirty_background_bytes auf 25 % der Festplattengeschwindigkeit verbessert jedoch die Leistung um ~ 25 % in den meisten Fällen.
vm.dirty_ratio / dirty_bytes
Das ist dasselbe wie vm.dirty_background_ratio / dirty_background_bytes, mit dem Unterschied, dass der Reset im aktiven Zustand erfolgt, wodurch die Anwendung blockiert wird. Daher sollte vm.dirty_ratio höher sein als vm.dirty_background_ratio. Dies stellt sicher, dass Hintergrundprozesse früher gestartet werden, um eine maximale Blockierung der Anwendung zu vermeiden. Sie können die Differenz zwischen diesen beiden Verhältnissen je nach der Last des Festplattendatentransfers anpassen.
Fazit
Sie können andere Parameter zur Verbesserung der Leistung anpassen, aber die Verbesserungen werden minimal sein und einen besonderen Nutzen werden Sie nicht daraus ziehen. Wir müssen uns daran erinnern, dass nicht alle Parameter für alle Arten von Anwendungen relevant sind. Einige Anwendungen funktionieren besser, wenn wir bestimmte Parameter konfigurieren, andere dagegen nicht. Sie müssen das richtige Gleichgewicht zwischen der Konfiguration dieser Parameter für die erwartete Arbeitslast und den Typ der Anwendung finden, und bei der Anpassung sollte auch das Verhalten des Betriebssystems berücksichtigt werden. Die Konfiguration der Kernel-Parameter ist nicht so einfach wie die der Datenbankparameter: Hier ist es schwieriger, Empfehlungen abzugeben.
Quelle: habr.com
