Optimal PostgreSQL-ydeevne afhænger af korrekt definerede operativsystemparametre. Dårligt konfigurerede OS-kerneindstillinger kan resultere i dårlig databaseserverydelse. Derfor er det bydende nødvendigt, at disse indstillinger konfigureres i henhold til databaseserveren og dens arbejdsbelastning. I dette indlæg vil vi diskutere nogle vigtige Linux-kerneparametre, der kan påvirke databaseserverens ydeevne, og hvordan man konfigurerer dem.
SHMMAX / SHMALL
SHMMAX er en kerneparameter, der bruges til at bestemme den maksimale størrelse af et enkelt delt hukommelsessegment, som en Linux-proces kan tildele. Før version 9.2 brugte PostgreSQL System V (SysV), som kræver SHMMAX-indstillingen. Efter 9.2 skiftede PostgreSQL til POSIX delt hukommelse. Så nu kræves færre bytes af System V delt hukommelse.
Før version 9.3 var SHMMAX den vigtigste kerneparameter. SHMMAX-værdien er angivet i bytes.
Tilsvarende SHMALL er en anden kerneparameter, der bruges til at bestemme
systemdækkende mængde af delte hukommelsessider. Brug kommandoen for at se de aktuelle SHMMAX-, SHMALL- eller SHMMIN-værdier ipcs.
SHM* Detaljer - 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* Detaljer - 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 bruger System V IPC at tildele delt hukommelse. Denne parameter er en af de vigtigste kerneparametre. Når du modtager følgende fejlmeddelelser, betyder det, at du har en ældre version af PostgreSQL, og din SHMMAX-værdi er meget lav. Brugere forventes at justere og øge værdien i henhold til den delte hukommelse, de har til hensigt at bruge.
Mulige fejlkonfigurationsfejl
Hvis SHMMAX ikke er konfigureret korrekt, kan du modtage en fejl, når du forsøger at initialisere en PostgreSQL-klynge ved hjælp af kommandoen initdb.
initdb fejl
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
Ligeledes kan du modtage en fejl, når du starter PostgreSQL-serveren ved hjælp af kommandoen pg_ctl.
pg_ctl Fejl
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.
Forstå forskellene i definitioner
At definere SHMMAX/SHMALL-parametrene er lidt anderledes på Linux og MacOS X:
- Linux: kernel.shmmax, kernel.shmall
- MacOS X: kern.sysv.shmmax, kern.sysv.shmall
Team sysctl kan bruges til midlertidigt at ændre værdien. For at indstille konstante værdier skal du tilføje en post til /etc/sysctl.conf. Detaljer er nedenfor.
Ændring af kerneindstillinger på 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Ændring af kerneparametre på 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 -> 16777216Glem ikke: For at gøre ændringer permanente skal du tilføje disse værdier til /etc/sysctl.conf
Kæmpe sider
Linux bruger 4 KB hukommelsessider som standard, BSD bruger XNUMX KB hukommelsessider. Super Pages, og på Windows - Store sider. En side er et stykke RAM, der er allokeret til en proces. En proces kan have flere sider afhængigt af hukommelseskrav. Jo mere hukommelse en proces kræver, jo flere sider tildeles den. OS vedligeholder en sideallokeringstabel for processer. Jo mindre sidestørrelsen er, jo større tabellen er, jo længere tid tager det at finde en side i den sidetabel. Store sider gør det derfor muligt at bruge store mængder hukommelse med reduceret overhead; færre sidevisninger, færre sidefejl, hurtigere læse/skrivehandlinger over større buffere. Resultatet er forbedret ydeevne.
PostgreSQL understøtter kun store sider på Linux. Som standard bruger Linux 4 KB hukommelsessider, så i tilfælde, hvor der er for mange hukommelsesoperationer, er det nødvendigt at indstille større sider. Ydeevneforbedringer observeres ved brug af store sider på 2 MB og op til 1 GB. Den store sidestørrelse kan indstilles ved opstart. Du kan nemt kontrollere de store sideparametre og deres brug på din Linux-maskine ved hjælp af kommandoen kat /proc/meminfo | grep -i enorm.
Få information om store sider (kun 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 kBI dette eksempel, selvom den store sidestørrelse er sat til 2048 (2 MB), er det samlede antal store sider sat til 0. Det betyder, at store sider er deaktiveret.
Script til at bestemme antallet af store sider
Dette simple script returnerer det nødvendige antal store sider. Kør scriptet på din Linux-server, mens PostgreSQL kører. Sørg for, at for miljøvariablen $PGDATA PostgreSQL-datamappe er angivet.
Få det antal påkrævede store sider
#!/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: $hpScript-output ser således ud:
Script output
Pid: 12737
VmPeak: 180932 kB
Hugepagesize: 2048 kB
Set Huge Pages: 88Den anbefalede værdi for store sider er 88, så du bør indstille den til 88.
Installation af store sider
sysctl -w vm.nr_hugepages=88Tjek store sider nu, du vil se, at store sider ikke bruges (HugePages_Free = HugePages_Total).
Store sider genbesøgt (kun 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 kBIndstil nu huge_pages parameteren til "on" i $PGDATA/postgresql.conf og genstart serveren.
Endnu en gang information om store sider (kun 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 kBNu kan du se, at meget få store sider bliver brugt. Lad os nu prøve at tilføje nogle data til databasen.
Nogle databaseoperationer for at genbruge store sider
postgres=# CREATE TABLE foo(a INTEGER);
CREATE TABLE
postgres=# INSERT INTO foo VALUES(generate_Series(1,10000000));
INSERT 0 10000000Lad os se, om vi bruger flere store sider nu end før.
Mere info på store sider (kun 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 kBNu kan du se, at de fleste af de store sider bliver brugt.
Bemærk: Den estimerede værdi for HugePages, der bruges her, er meget lav, hvilket ikke er en normal værdi for en maskine, der kører et produktmiljø. Anslå venligst det nødvendige antal sider til dit system og indstil dem i overensstemmelse hermed baseret på belastning og ressourcer.
vm.bytte
vm.bytte er en anden kerneparameter, der kan påvirke databasens ydeevne. Denne mulighed bruges til at kontrollere adfærden af swappiness (bytte sider ind og ud af hukommelsen) på Linux. Værdien går fra 0 til 100. Den bestemmer, hvor meget hukommelse der skal bladres eller udskrives. Nul betyder ingen udveksling og 100 betyder aggressiv udveksling.
Du kan opnå god ydeevne ved at indstille lavere værdier.
At sætte dette til 0 på nyere kerner kan få OOM Killer (Linux's hukommelsesrensningsproces) til at dræbe processen. Så det er sikkert at sætte den til 1, hvis du vil minimere bytte. Standardværdien i Linux er 60. En højere værdi får MMU (memory management unit) til at bruge mere swap-plads end RAM, mens en lavere værdi holder flere data/kode i hukommelsen.
En lavere værdi er et godt bud på forbedret ydeevne i PostgreSQL.
vm.overcommit_memory / vm.overcommit_ratio
Programmer tilegner sig hukommelse og frigiver den, når den ikke længere er nødvendig. Men i nogle tilfælde får applikationen for meget hukommelse og frigiver den ikke. Dette kan forårsage en OOM-dræber. Her er de mulige parameterværdier vm.overcommit_memory med en beskrivelse for hver:
- Heuristisk overcommit (standard); kernebaseret heuristik
- Tillad alligevel overcommit
- Overdriv det ikke, overskrid ikke overcommit-forholdet.
link:
vm.overcommit_ratio — procentdel af RAM tilgængelig for overbelastning. En værdi på 50 % på et system med 2 GB RAM kan allokere op til 3 GB RAM.
En værdi på 2 for vm.overcommit_memory giver bedre ydeevne for PostgreSQL. Denne værdi maksimerer serverprocessens RAM-forbrug uden nogen væsentlig risiko for at blive dræbt af OOM-dræberprocessen. Applikationen vil være i stand til at genindlæse, men kun inden for grænserne for overløb, hvilket reducerer risikoen for, at en OOM-morder dræber processen. Derfor giver en værdi på 2 bedre ydeevne end standardværdien på 0. Pålideligheden kan dog forbedres ved at sikre, at hukommelsen uden for rækkevidde ikke overbelastes. Dette eliminerer risikoen for, at processen bliver dræbt af en OOM-morder.
På systemer uden ombytning kan der opstå et problem med vm.overcommit_memory lig med 2.
vm.dirty_background_ratio / vm.dirty_background_bytes
vm.dirty_background_ratio er procentdelen af hukommelsen fyldt med beskidte sider, der skal skrives til disken. Flytning til disk sker i baggrunden. Værdien af denne parameter går fra 0 til 100; dog kan en værdi under 5 være ineffektiv, og nogle kerner understøtter den ikke. 10 er standard på de fleste Linux-systemer. Du kan forbedre ydeevnen for skriveintensive operationer med en mindre faktor, hvilket vil betyde, at Linux vil skylle beskidte sider i baggrunden.
Du skal indstille værdien vm.dirty_background_bytes afhængig af kørehastigheden.
Der er ingen "gode" værdier for disse to parametre, da begge er hardwareafhængige. Indstilling af vm.dirty_background_ratio til 5 og vm.dirty_background_bytes til 25 % af diskhastigheden forbedrer imidlertid ydeevnen til ~25 % i de fleste tilfælde.
vm.dirty_ratio/dirty_bytes
Det er det samme som vm.dirty_background_ratio/dirty_background_bytes, bortset fra at nulstillingen udføres i en arbejdersession, hvilket blokerer applikationen. Derfor bør vm.dirty_ratio være højere end vm.dirty_background_ratio. Dette sikrer, at baggrundsprocesser starter tidligere for at undgå at blokere applikationen så meget som muligt. Du kan justere forskellen mellem disse to forhold afhængigt af diskens I/O-belastning.
Total
Du kan justere andre indstillinger for at forbedre ydeevnen, men forbedringerne vil være minimale, og du vil ikke se den store fordel. Vi skal huske, at ikke alle muligheder gælder for alle typer applikationer. Nogle apps fungerer bedre, når vi justerer nogle indstillinger, og nogle gør det ikke. Du skal finde den rigtige balance mellem at konfigurere disse indstillinger til din forventede arbejdsbyrde og applikationstype, og du skal også overveje OS-adfærd, når du tuner. Konfiguration af kerneparametre er ikke så let som at konfigurere databaseparametre; det er sværere at komme med anbefalinger.
Kilde: www.habr.com