Optimal PostgreSQL Leeschtung hänkt vu korrekt definéierte Betribssystemparameter of. Schlecht konfiguréiert OS Kernel Astellunge kënnen zu enger schlechter Datebankserverleistung féieren. Dofir ass et néideg datt dës Astellungen no dem Datebankserver a senger Aarbechtslaascht konfiguréiert sinn. An dësem Post wäerte mir e puer wichteg Linux Kernel Parameteren diskutéieren, déi d'Datebankserverleistung beaflosse kënnen a wéi se se konfiguréieren.
SHMMAX / SHMALL
SHMMAX ass e Kernelparameter deen benotzt gëtt fir d'maximal Gréisst vun engem eenzege Shared Memory Segment ze bestëmmen deen e Linux Prozess kann allocéieren. Virun der Versioun 9.2 huet PostgreSQL System V (SysV) benotzt, wat d'SHMMAX-Astellung erfuerdert. No 9.2 ass PostgreSQL op POSIX gedeelt Erënnerung gewiesselt. Also sinn elo manner Bytes vum System V gemeinsame Gedächtnis erfuerderlech.
Virun Versioun 9.3 war SHMMAX dee wichtegste Kernelparameter. De SHMMAX Wäert gëtt a Bytes spezifizéiert.
Ähnlech wéi SCHMALL ass en anere Kernelparameter benotzt fir ze bestëmmen
System-breet Volume vun gedeelt Erënnerung Säiten. Fir déi aktuell SHMMAX, SHMALL oder SHMMIN Wäerter ze gesinn, benotzt de Kommando ipcs.
SHM* Detailer - 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* Detailer - 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 benotzt System V IPC gemeinsam Erënnerung ze verdeelen. Dëse Parameter ass ee vun de wichtegste Kärparameter. Wann Dir déi folgend Fehlermeldungen kritt, heescht et datt Dir eng méi al Versioun vu PostgreSQL hutt an Ären SHMMAX Wäert ganz niddereg ass. D'Benotzer ginn erwaart de Wäert unzepassen an ze erhéijen no der gemeinsamer Erënnerung déi se wëlle benotzen.
Méiglech falsch Konfiguratiounsfehler
Wann SHMMAX net richteg konfiguréiert ass, kënnt Dir e Feeler kréien wann Dir probéiert e PostgreSQL Cluster mat dem Kommando ze initialiséieren initdb.
initdb Feeler
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
Och Dir kënnt e Feeler kréien wann Dir de PostgreSQL Server mat dem Kommando start pg_ctl.
pg_ctl Feeler
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.
D'Ënnerscheeder an Definitiounen ze verstoen
D'SHMMAX / SHMALL Parameteren definéieren ass liicht anescht op Linux a MacOS X:
- Linux: kernel.shmmax, kernel.shmall
- MacOS X: kern.sysv.shmmax, kern.sysv.shmall
Equipe sysctl ka benotzt ginn fir de Wäert temporär z'änneren. Fir konstante Wäerter ze setzen, füügt eng Entrée un /etc/sysctl.conf. Detailer sinn ënnert.
Änneren Kernel Astellungen op 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Änneren Kernel Parameteren op 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 -> 16777216Vergiess net: Fir Ännerungen permanent ze maachen, füügt dës Wäerter op /etc/sysctl.conf
Grouss Säiten
Linux benotzt 4 KB Erënnerung Säiten Par défaut, BSD benotzt XNUMX KB Erënnerung Säiten. Super Säiten, an op Windows - Grouss Säiten. Eng Säit ass e Stéck RAM dat un e Prozess zougewisen ass. E Prozess kann e puer Säiten hunn ofhängeg vun Erënnerung Ufuerderunge. Wat méi Erënnerung e Prozess erfuerdert, wat méi Säiten et zougedeelt gëtt. D'OS hält eng Säit Allocatiounstabell fir Prozesser. Wat méi kleng d'Säitgréisst ass, wat d'Tabelle méi grouss ass, wat méi laang et dauert fir eng Säit an där Säittabel ze fannen. Grouss Säiten erlaben dofir grouss Quantitéiten un Erënnerung mat reduzéierter Iwwerhead benotzt ginn; manner Säit Meenung, manner Säit Feeler, méi séier liesen / schreiwen Operatiounen iwwer méi grouss Puffer. D'Resultat ass eng verbessert Leeschtung.
PostgreSQL ënnerstëtzt nëmme grouss Säiten op Linux. Par défaut benotzt Linux 4 KB Erënnerung Säiten, also a Fäll wou et ze vill Erënnerung Operatiounen sinn, ass et néideg gréisser Säiten ze setzen. Leeschtungsgewënn ginn beobachtet wann Dir grouss Säiten vun 2 MB a bis zu 1 GB benotzt. Déi grouss Säit Gréisst kann op Boot Zäit gesat ginn. Dir kënnt einfach déi grouss Säit Parameteren an hir Notzung op Ärer Linux Maschinn iwwerpréiwen mat dem Kommando cat /proc/meminfo | grep -i grouss.
Informatioun iwwer grouss Säiten kréien (nëmmen 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 kBAn dësem Beispill, obwuel déi grouss Säit Gréisst op 2048 (2 MB) gesat ass, ass d'Gesamtzuel vu grousse Säiten op 0. Dat heescht, datt grouss Säiten behënnert sinn.
Skript fir d'Zuel vu grousse Säiten ze bestëmmen
Dëst einfache Skript gëtt déi erfuerderlech Zuel vu grousse Säiten zréck. Fëllt de Skript op Ärem Linux Server wärend PostgreSQL leeft. Vergewëssert Iech datt fir d'Ëmweltvariabel $PGDATA PostgreSQL Dateverzeichnis gëtt spezifizéiert.
Kréien d'Zuel vun néideg grouss Säiten
#!/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: $hpDe Skriptoutput gesäit esou aus:
Skript Ausgang
Pid: 12737
VmPeak: 180932 kB
Hugepagesize: 2048 kB
Set Huge Pages: 88De recommandéierte Wäert fir grouss Säiten ass 88, also sollt Dir et op 88 setzen.
Installéiere grouss Säiten
sysctl -w vm.nr_hugepages=88Kuckt elo grouss Säiten, Dir gesitt datt grouss Säiten net benotzt ginn (HugePages_Free = HugePages_Total).
Grouss Säiten iwwerpréift (nëmmen 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 kBSetzt elo den Huge_pages Parameter op "on" an $PGDATA/postgresql.conf an de Server nei starten.
Nach eng Kéier, Informatioun iwwer grouss Säiten (nëmmen 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 kBElo gesitt Dir datt ganz wéineg grouss Säite benotzt ginn. Loosst eis elo probéieren e puer Daten an d'Datebank ze addéieren.
E puer Datebankoperatiounen fir grouss Säiten ze recycléieren
postgres=# CREATE TABLE foo(a INTEGER);
CREATE TABLE
postgres=# INSERT INTO foo VALUES(generate_Series(1,10000000));
INSERT 0 10000000Mol kucken ob mir elo méi grouss Säite benotzen wéi virdrun.
Méi Informatioun iwwer grouss Säiten (nëmmen 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 kBElo gesitt Dir datt déi meescht grouss Säite benotzt ginn.
Notiz: De geschätzte Wäert fir HugePages déi hei benotzt gëtt ass ganz niddereg, wat keen normale Wäert ass fir eng Maschinn déi e Produktëmfeld leeft. W.e.g. schätzt déi erfuerderlech Unzuel u Säiten fir Äre System a setzt se deementspriechend op Basis vun der Belaaschtung a Ressourcen.
vm.swappiness
vm.swappiness ass en anere Kernelparameter deen d'Datebankleistung beaflosse kann. Dës Optioun gëtt benotzt fir d'Behuele vu Swappiness ze kontrolléieren (Säiten an an aus Erënnerung tauschen) am Linux. De Wäert läit tëscht 0 an 100. Et bestëmmt wéi vill Erënnerung paged oder paged aus. Null heescht keen Austausch an 100 heescht aggressiv Austausch.
Dir kënnt gutt Leeschtung kréien andeems Dir méi niddereg Wäerter setzt.
Wann Dir dëst op 0 op méi nei Kärelen setzt, kann OOM Killer (Linux Erënnerungsreinigungsprozess) de Prozess ëmbréngen. Also et ass sécher et op 1 ze setzen wann Dir Tauschen miniméiere wëllt. De Standardwäert am Linux ass 60. E méi héije Wäert bewierkt datt d'MMU (Memory Management Unit) méi Swap-Plaz benotzt wéi RAM, während e méi nidderegen Wäert méi Daten / Code an der Erënnerung hält.
E méi nidderegen Wäert ass eng gutt Wette fir eng verbessert Leeschtung am PostgreSQL.
vm.overcommit_memory / vm.overcommit_ratio
Uwendungen kréien Erënnerung a befreien se wann et net méi gebraucht gëtt. Awer an e puer Fäll kritt d'Applikatioun ze vill Erënnerung a verëffentlecht se net. Dëst kann en OOM Killer verursaachen. Hei sinn déi méiglech Parameter Wäerter vm.overcommit_memory mat enger Beschreiwung fir all:
- Heuristesch Iwwerbezuelung (Standard); kernel-baséiert heuristesch
- Erlaabt iwwerhaapt iwwerhaapt
- Iwwerdréit et net, iwwerschreift net d'Iwwerzeegungsverhältnis.
Referenz:
vm.overcommit_ratio - Prozentsaz vum RAM verfügbar fir Iwwerlaascht. E Wäert vun 50% op engem System mat 2 GB RAM kann bis zu 3 GB RAM allocéieren.
E Wäert vun 2 fir vm.overcommit_memory bitt besser Leeschtung fir PostgreSQL. Dëse Wäert maximéiert d'RAM Notzung vum Serverprozess ouni e wesentleche Risiko vum OOM Killerprozess ëmbruecht ze ginn. D'Applikatioun wäert fäeg sinn nei ze lueden, awer nëmmen bannent de Grenze vun der Iwwerschwemmung, wat de Risiko reduzéiert datt en OOM Killer de Prozess ëmbréngt. Dofir gëtt e Wäert vun 2 eng besser Leeschtung wéi de Standardwäert vun 0. Allerdéngs kann d'Zouverlässegkeet verbessert ginn andeems Dir suergt datt d'Erënnerung ausserhalb vun der Rei net iwwerlaascht ass. Dëst eliminéiert de Risiko datt de Prozess vun engem OOM Killer ëmbruecht gëtt.
Op Systemer ouni Tauscht kann e Problem mat vm.overcommit_memory gläich 2 optrieden.
vm.dirty_background_ratio / vm.dirty_background_bytes
vm.dirty_background_ratio ass de Prozentsaz vun der Erënnerung gefëllt mat dreckeg Säiten déi op Disk geschriwwe musse ginn. De Spull op Disk geschitt am Hannergrond. De Wäert vun dësem Parameter läit vun 0 bis 100; Ee Wäert ënner 5 kann awer net effikass sinn an e puer Kären ënnerstëtzen et net. 10 ass de Standard op de meeschte Linux Systemer. Dir kënnt d'Performance fir schreiwenintensiv Operatiounen duerch e méi klenge Faktor verbesseren, wat bedeit datt Linux dreckeg Säiten am Hannergrond spülen.
Dir musst de Wäert setzen vm.dirty_background_bytes ofhängeg vun der Geschwindegkeet vun Ärem Fuert.
Et gi keng "gutt" Wäerter fir dës zwee Parameter well béid Hardware ofhängeg sinn. Wéi och ëmmer, vm.dirty_background_ratio op 5 a vm.dirty_background_bytes op 25% vun der Scheifgeschwindegkeet ze setzen verbessert d'Performance op ~ 25% an de meeschte Fäll.
vm.dirty_ratio/dirty_bytes
Dëst ass d'selwecht wéi vm.dirty_background_ratio/dirty_background_bytes, ausser datt de Reset an enger Aarbechter Sessioun duerchgefouert gëtt, d'Applikatioun blockéiert. Dofir vm.dirty_ratio soll méi héich wéi vm.dirty_background_ratio. Dëst garantéiert datt Hannergrondprozesser méi fréi ufänken fir d'Applikatioun sou vill wéi méiglech ze blockéieren. Dir kënnt den Ënnerscheed tëscht dësen zwee Verhältnisser ajustéieren ofhängeg vun der Disk I/O Last.
D 'Resultat
Dir kënnt aner Astellungen upassen fir d'Performance ze verbesseren, awer d'Verbesserunge wäerte minimal sinn an Dir wäert net vill Virdeel gesinn. Mir mussen drun erënneren datt net all Optiounen fir all Zorte vun Uwendungen gëllen. E puer Apps funktionnéieren besser wa mir e puer Astellunge upassen, an e puer net. Dir musst de richtege Gläichgewiicht fannen tëscht der Konfiguratioun vun dësen Astellunge fir Är erwaart Aarbechtslaascht an Applikatiounstyp, an Dir musst och d'OS-Behuele beim Tuning berücksichtegen. Kernelparameter konfiguréieren ass net sou einfach wéi d'Datebankparameter konfiguréieren; et ass méi schwéier Empfehlungen ze maachen.
Source: will.com