Optimale PostgreSQL-prestaasjes hinget ôf fan goed definieare bestjoeringssysteemparameters. Min konfigureare OS-kernelynstellingen kinne resultearje yn minne prestaasjes fan databaseserver. Dêrom is it ymperatyf dat dizze ynstellings wurde konfigureare neffens de databanktsjinner en har wurkdruk. Yn dit post sille wy wat wichtige Linux-kernelparameters beprate dy't de prestaasjes fan databaseservers kinne beynfloedzje en hoe't se se konfigurearje.
SHMMAX / SHMALL
SHMMAX is in kernelparameter dy't brûkt wurdt om de maksimale grutte te bepalen fan in inkeld dielde ûnthâldsegment dat in Linux-proses kin allocearje. Foarôfgeand oan ferzje 9.2 brûkte PostgreSQL System V (SysV), wat de SHMMAX-ynstelling fereasket. Nei 9.2 skeakele PostgreSQL oer nei POSIX dielde ûnthâld. Dat no binne minder bytes fan System V dielde ûnthâld nedich.
Foar ferzje 9.3 wie SHMMAX de wichtichste kernelparameter. De SHMMAX wearde wurdt oantsjutte yn bytes.
Lykwols, SHMALL is in oare kernel parameter brûkt om te bepalen
systeem-wide folume fan dielde ûnthâld siden. Om de hjoeddeistige SHMMAX-, SHMALL- of SHMMIN-wearden te besjen, brûk it kommando 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 brûkt Systeem V IPC om dielde ûnthâld te allocearjen. Dizze parameter is ien fan 'e wichtichste kernelparameters. Elke kear as jo de folgjende flaterberjochten ûntfange, betsjut dit dat jo in âldere ferzje fan PostgreSQL hawwe en jo SHMMAX-wearde heul leech is. Fan brûkers wurdt ferwachte dat se de wearde oanpasse en ferheegje neffens it dielde ûnthâld dat se fan doel binne te brûken.
Mooglike misconfiguration flaters
As SHMMAX net goed is ynsteld, kinne jo in flater krije as jo besykje in PostgreSQL-kluster te initialisearjen mei it kommando ynitdb.
initdb mislearring
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
Likegoed kinne jo in flater krije by it starten fan de PostgreSQL-tsjinner mei it kommando pg_ctl.
pg_ctl Mislearre
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.
Ferstean de ferskillen yn definysjes
It definiearjen fan de SHMMAX / SHMALL-parameters is wat oars op Linux en MacOS X:
- Linux: kernel.shmmax, kernel.shmall
- MacOS X: kern.sysv.shmmax, kern.sysv.shmall
team sysctl kin brûkt wurde om de wearde tydlik te feroarjen. Om konstante wearden yn te stellen, foegje in yngong ta /etc/sysctl.conf. Details binne hjirûnder.
Kernelynstellingen feroarje 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 -> 16777216Kernelparameters feroarje 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 -> 16777216Net ferjitte: Om wizigingen permanint te meitsjen, foegje dizze wearden ta oan /etc/sysctl.conf
Enorme siden
Linux brûkt standert 4 KB ûnthâld siden, BSD brûkt XNUMX KB ûnthâld siden. Super Pages, en op Windows - Grutte siden. In side is in stik RAM tawiisd oan in proses. In proses kin hawwe meardere siden ôfhinklik fan ûnthâld easken. Hoe mear ûnthâld in proses fereasket, hoe mear siden it wurdt tawiisd. It OS ûnderhâldt in side-allokaasjetabel foar prosessen. Hoe lytser de sidegrutte, hoe grutter de tabel, hoe langer it duorret om in side yn dy sidetabel te finen. Grutte siden kinne dêrom grutte hoemannichten ûnthâld wurde brûkt mei redusearre overhead; minder side views, minder side flaters, flugger lêzen / skriuwe operaasjes oer gruttere buffers. It resultaat is ferbettere prestaasjes.
PostgreSQL stipet allinich grutte siden op Linux. Standert brûkt Linux 4 KB ûnthâld siden, dus yn gefallen dêr't der tefolle ûnthâld operaasjes, is it nedich om te setten gruttere siden. Prestaasjewinsten wurde waarnommen by it brûken fan grutte siden fan 2 MB en oant 1 GB. De grutte sidegrutte kin ynsteld wurde by it opstarten. Jo kinne de grutte sideparameters en har gebrûk maklik kontrolearje op jo Linux-masine mei it kommando kat /proc/meminfo | grep -i grut.
Ynformaasje oer grutte siden krije (allinich 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 kBYn dit foarbyld, hoewol't de grutte sidegrutte is ynsteld op 2048 (2 MB), is it totale oantal grutte siden ynsteld op 0. Dit betsjut dat grutte siden binne útskeakele.
Skript foar it bepalen fan it oantal grutte siden
Dit ienfâldige skript jout it fereaske oantal grutte siden werom. Run it skript op jo Linux-tsjinner wylst PostgreSQL rint. Soargje derfoar dat foar de omjouwing fariabele $PGDATA PostgreSQL-gegevensmap is oantsjutte.
It oantal fereaske grutte siden krije
#!/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 skriptútfier sjocht der sa út:
Skriptútfier
Pid: 12737
VmPeak: 180932 kB
Hugepagesize: 2048 kB
Set Huge Pages: 88De oanrikkemandearre wearde foar grutte siden is 88, dus jo moatte it ynstelle op 88.
Ynstallaasje fan grutte siden
sysctl -w vm.nr_hugepages=88Kontrolearje no grutte siden, jo sille sjen dat grutte siden net brûkt wurde (HugePages_Free = HugePages_Total).
Grutte siden opnij besocht (allinich 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 kBStel no de parameter huge_pages op "oan" yn $PGDATA/postgresql.conf en start de server opnij.
Nochris ynformaasje oer grutte siden (allinich 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 kBNo kinne jo sjen dat hiel pear grutte siden wurde brûkt. Litte wy no besykje wat gegevens ta te foegjen oan de databank.
Guon databankoperaasjes om grutte siden te recyclearjen
postgres=# CREATE TABLE foo(a INTEGER);
CREATE TABLE
postgres=# INSERT INTO foo VALUES(generate_Series(1,10000000));
INSERT 0 10000000Litte wy sjen oft wy no mear grutte siden brûke as earder.
Mear ynfo oer grutte siden (allinich 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 kBNo kinne jo sjen dat de measte fan 'e grutte siden wurde brûkt.
Opmerking: De skatte wearde foar HugePages brûkt hjir is heul leech, wat gjin normale wearde is foar in masine dy't in produktomjouwing draait. Skat asjebleaft it fereaske oantal siden foar jo systeem en set se neffens de lading en boarnen yn.
vm.swapppiness
vm.swapppiness is in oare kernel parameter dy't kin beynfloedzje de prestaasjes fan de database. Dizze opsje wurdt brûkt om it gedrach fan swappiness te kontrolearjen (siden yn en út it ûnthâld wikselje) yn Linux. De wearde fariearret fan 0 oan 100. It bepaalt hoefolle ûnthâld wurdt paged of paged út. Nul betsjut gjin útwikseling en 100 betsjut agressive útwikseling.
Jo kinne goede prestaasjes krije troch legere wearden yn te stellen.
It ynstellen fan dit op 0 op nijere kernels kin OOM Killer (Linux syn ûnthâld skjinmeitsjen proses) deadzje it proses. It is dus feilich om it op 1 yn te stellen as jo ruilje wolle minimalisearje. De standertwearde yn Linux is 60. In hegere wearde feroarsaket dat de MMU (memory management unit) mear swapromte brûke as RAM, wylst in legere wearde mear gegevens / koade yn it ûnthâld hâldt.
In legere wearde is in goede weddenskip foar ferbettere prestaasjes yn PostgreSQL.
vm.overcommit_memory / vm.overcommit_ratio
Applikaasjes krije ûnthâld en jouwe it frij as it net mear nedich is. Mar yn guon gefallen krijt de applikaasje te folle ûnthâld en lit it net los. Dit kin in OOM-moardner feroarsaakje. Hjir binne de mooglike parameterwearden vm.overcommit_memory mei in beskriuwing foar elk:
- Heuristic overcommit (standert); kernel-basearre heuristyk
- Tastean overcommit dochs
- Net oerdriuwe, net boppe de overcommit ratio.
Referinsje:
vm.overcommit_ratio - persintaazje RAM beskikber foar overload. In wearde fan 50% op in systeem mei 2 GB RAM kin tawize oant 3 GB RAM.
In wearde fan 2 foar vm.overcommit_memory jout bettere prestaasjes foar PostgreSQL. Dizze wearde maksimalisearret it RAM-gebrûk fan it serverproses sûnder signifikant risiko om te fermoardzjen troch it OOM-killerproses. De applikaasje sil opnij laden kinne, mar allinich binnen de grinzen fan oerrin, wat it risiko ferminderet dat in OOM-moardner it proses fermoardzje. Dêrom jout in wearde fan 2 bettere prestaasjes as de standertwearde fan 0. De betrouberens kin lykwols ferbettere wurde troch te soargjen dat it ûnthâld bûten it berik net oerladen wurdt. Dit elimineert it risiko dat it proses wurdt fermoarde troch in OOM-moardner.
Op systemen sûnder wikseljen kin in probleem mei vm.overcommit_memory lyk oan 2 foarkomme.
vm.dirty_background_ratio / vm.dirty_background_bytes
vm.dirty_background_ratio is it persintaazje ûnthâld fol mei smoarge siden dy't moatte wurde skreaun op skiif. De flush nei skiif bart op 'e eftergrûn. De wearde fan dizze parameter fariearret fan 0 oant 100; in wearde ûnder 5 kin lykwols net effektyf wêze en guon kearnen stypje it net. 10 is de standert op de measte Linux-systemen. Jo kinne prestaasjes ferbetterje foar skriuw-yntinsive operaasjes troch in lytsere faktor, wat betsjuttet dat Linux smoarge siden op 'e eftergrûn sil spoelen.
Jo moatte de wearde ynstelle vm.dirty_background_bytes ôfhinklik fan de snelheid fan jo ryd.
D'r binne gjin "goede" wearden foar dizze twa parameters, om't beide hardware ôfhinklik binne. Lykwols, it ynstellen fan vm.dirty_background_ratio op 5 en vm.dirty_background_bytes op 25% fan 'e skiifsnelheid ferbettert prestaasjes oant ~ 25% yn 'e measte gefallen.
vm.dirty_ratio/dirty_bytes
Dit is itselde as vm.dirty_background_ratio/dirty_background_bytes, útsein dat de reset wurdt útfierd yn in arbeider sesje, blokkearje de applikaasje. Dêrom moat vm.dirty_ratio heger wêze as vm.dirty_background_ratio. Dit soarget derfoar dat eftergrûnprosessen earder begjinne om de applikaasje safolle mooglik te blokkearjen. Jo kinne oanpasse it ferskil tusken dizze twa ferhâldingen ôfhinklik fan de skiif I / O load.
It resultaat
Jo kinne oare ynstellingen oanpasse om prestaasjes te ferbetterjen, mar de ferbetteringen sille minimaal wêze en jo sille net folle foardiel sjen. Wy moatte betinke dat net alle opsjes jilde foar alle soarten applikaasjes. Guon apps wurkje better as wy guon ynstellings oanpasse, en guon net. Jo moatte it juste lykwicht fine tusken it konfigurearjen fan dizze ynstellings foar jo ferwachte wurkdruk en applikaasjetype, en jo moatte ek OS-gedrach beskôgje by it ôfstimmen. It konfigurearjen fan kernelparameters is net sa maklik as it konfigurearjen fan databankparameters; it is dreger om oanbefellings te meitsjen.
Boarne: www.habr.com