Optimal PostgreSQL-ytelse avhenger av korrekt definerte operativsystemparametere. Dårlig konfigurerte OS-kjerneinnstillinger kan føre til dårlig databaseserverytelse. Derfor er det viktig at disse innstillingene konfigureres i henhold til databaseserveren og dens arbeidsbelastning. I dette innlegget vil vi diskutere noen viktige Linux-kjerneparametere som kan påvirke databaseserverytelsen og hvordan de konfigureres.
SHMMAX / SHMALL
SHMMAX er en kjerneparameter som brukes til å bestemme den maksimale størrelsen på et enkelt delt minnesegment som en Linux-prosess kan tildele. Før versjon 9.2 brukte PostgreSQL System V (SysV), som krever SHMMAX-innstillingen. Etter 9.2 byttet PostgreSQL til POSIX delt minne. Så nå kreves færre byte med System V delt minne.
Før versjon 9.3 var SHMMAX den viktigste kjerneparameteren. SHMMAX-verdien er spesifisert i byte.
På samme måte, SHMALL er en annen kjerneparameter som brukes til å bestemme
systemomfattende volum av delte minnesider. For å se gjeldende SHMMAX-, SHMALL- eller SHMMIN-verdier, bruk kommandoen 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 bruker System V IPC for å tildele delt minne. Denne parameteren er en av de viktigste kjerneparametrene. Når du mottar følgende feilmeldinger, betyr det at du har en eldre versjon av PostgreSQL og at SHMMAX-verdien din er veldig lav. Brukere forventes å justere og øke verdien i henhold til det delte minnet de har tenkt å bruke.
Mulige feilkonfigureringsfeil
Hvis SHMMAX ikke er riktig konfigurert, kan du få en feilmelding når du prøver å initialisere en PostgreSQL-klynge ved hjelp av kommandoen initdb.
initdb feil
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
På samme måte kan du få en feilmelding når du starter PostgreSQL-serveren med kommandoen pg_ctl.
pg_ctl Feil
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å forskjellene i definisjoner
Å definere SHMMAX/SHMALL-parametrene er litt annerledes på Linux og MacOS X:
- Linux: kernel.shmmax, kernel.shmall
- MacOS X: kern.sysv.shmmax, kern.sysv.shmall
Lag sysctl kan brukes til å endre verdien midlertidig. For å angi konstante verdier, legg til en oppføring i /etc/sysctl.conf. Detaljer er nedenfor.
Endre kjerneinnstillinger 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 -> 16777216Endre kjerneparametere 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 -> 16777216Ikke snakk: For å gjøre endringer permanent, legg til disse verdiene i /etc/sysctl.conf
Store sider
Linux bruker 4 KB minnesider som standard, BSD bruker XNUMX KB minnesider. Super sider, og på Windows - Store sider. En side er et stykke RAM som er allokert til en prosess. En prosess kan ha flere sider avhengig av minnekrav. Jo mer minne en prosess krever, jo flere sider tildeles den. OS vedlikeholder en sideallokeringstabell for prosesser. Jo mindre sidestørrelse, jo større tabell, jo lengre tid tar det å finne en side i den sidetabellen. Store sider gjør det derfor mulig å bruke store mengder minne med redusert overhead; færre sidevisninger, færre sidefeil, raskere lese-/skriveoperasjoner over større buffere. Resultatet er forbedret ytelse.
PostgreSQL støtter bare store sider på Linux. Som standard bruker Linux 4 KB minnesider, så i tilfeller der det er for mange minneoperasjoner, er det nødvendig å angi større sider. Ytelsesgevinster observeres ved bruk av store sider på 2 MB og opptil 1 GB. Den store sidestørrelsen kan stilles inn ved oppstart. Du kan enkelt sjekke de store sideparametrene og deres bruk på Linux-maskinen din ved å bruke kommandoen cat /proc/meminfo | grep -i enorm.
Få informasjon 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 eksemplet, selv om den store sidestørrelsen er satt til 2048 (2 MB), er det totale antallet store sider satt til 0. Dette betyr at store sider er deaktivert.
Skript for å bestemme antall store sider
Dette enkle skriptet returnerer det nødvendige antallet store sider. Kjør skriptet på Linux-serveren mens PostgreSQL kjører. Pass på at for miljøvariabelen $PGDATA PostgreSQL-datakatalogen er spesifisert.
Får antall nødvendige 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: $hpSkriptutgangen ser slik ut:
Skriptutgang
Pid: 12737
VmPeak: 180932 kB
Hugepagesize: 2048 kB
Set Huge Pages: 88Den anbefalte verdien for store sider er 88, så du bør sette den til 88.
Installere store sider
sysctl -w vm.nr_hugepages=88Sjekk store sider nå, du vil se at store sider ikke brukes (HugePages_Free = HugePages_Total).
Store sider besøkt på nytt (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 kBSett nå huge_pages-parameteren til "on" i $PGDATA/postgresql.conf og start serveren på nytt.
Nok en gang informasjon 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 kBNå kan du se at svært få store sider blir brukt. La oss nå prøve å legge til noen data til databasen.
Noen databaseoperasjoner for å resirkulere store sider
postgres=# CREATE TABLE foo(a INTEGER);
CREATE TABLE
postgres=# INSERT INTO foo VALUES(generate_Series(1,10000000));
INSERT 0 10000000La oss se om vi bruker flere store sider nå enn før.
Mer informasjon 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 kBNå kan du se at de fleste av de store sidene blir brukt.
Merk: Den estimerte verdien for HugePages brukt her er svært lav, som ikke er en normal verdi for en maskin som kjører et produktmiljø. Vennligst estimer det nødvendige antall sider for systemet ditt og sett dem deretter basert på belastning og ressurser.
vm.bytte
vm.bytte er en annen kjerneparameter som kan påvirke databaseytelsen. Dette alternativet brukes til å kontrollere atferden til swappiness (bytte sider inn og ut av minnet) i Linux. Verdien varierer fra 0 til 100. Den bestemmer hvor mye minne som skal søkes eller sides ut. Null betyr ingen utveksling og 100 betyr aggressiv utveksling.
Du kan få god ytelse ved å sette lavere verdier.
Å sette dette til 0 på nyere kjerner kan føre til at OOM Killer (Linux sin minnerenseprosess) dreper prosessen. Så det er trygt å sette den til 1 hvis du vil minimere bytte. Standardverdien i Linux er 60. En høyere verdi fører til at MMU (memory management unit) bruker mer swap-plass enn RAM, mens en lavere verdi holder mer data/kode i minnet.
En lavere verdi er en god innsats for forbedret ytelse i PostgreSQL.
vm.overcommit_memory / vm.overcommit_ratio
Applikasjoner skaffer seg minne og frigjør det når det ikke lenger er nødvendig. Men i noen tilfeller får applikasjonen for mye minne og slipper den ikke. Dette kan forårsake en OOM-morder. Her er de mulige parameterverdiene vm.overcommit_memory med en beskrivelse for hver:
- Heuristisk overcommit (standard); kjernebasert heuristikk
- Tillat overcommit uansett
- Ikke overdriv, ikke overskrid overcommit-forholdet.
link:
vm.overcommit_ratio — prosentandel av RAM tilgjengelig for overbelastning. En verdi på 50 % på et system med 2 GB RAM kan tildele opptil 3 GB RAM.
En verdi på 2 for vm.overcommit_memory gir bedre ytelse for PostgreSQL. Denne verdien maksimerer serverprosessens RAM-bruk uten noen betydelig risiko for å bli drept av OOM-killer-prosessen. Applikasjonen vil kunne lastes inn på nytt, men bare innenfor grensene for overløp, noe som reduserer risikoen for at en OOM-morder dreper prosessen. Derfor gir en verdi på 2 bedre ytelse enn standardverdien på 0. Pålitelighet kan imidlertid forbedres ved å sikre at minne utenfor rekkevidde ikke overbelastes. Dette eliminerer risikoen for at prosessen blir drept av en OOM-morder.
På systemer uten bytte kan det oppstå et problem med vm.overcommit_memory lik 2.
vm.dirty_background_ratio / vm.dirty_background_bytes
vm.dirty_background_ratio er prosentandelen av minnet fylt med skitne sider som må skrives til disk. Flush til disk skjer i bakgrunnen. Verdien av denne parameteren varierer fra 0 til 100; Imidlertid kan en verdi under 5 være ineffektiv, og noen kjerner støtter den ikke. 10 er standard på de fleste Linux-systemer. Du kan forbedre ytelsen for skriveintensive operasjoner med en mindre faktor, noe som vil bety at Linux vil skylle skitne sider i bakgrunnen.
Du må angi verdien vm.dirty_background_bytes avhengig av kjørehastigheten.
Det er ingen "gode" verdier for disse to parameterne da begge er maskinvareavhengige. Men å sette vm.dirty_background_ratio til 5 og vm.dirty_background_bytes til 25 % av diskhastigheten forbedrer ytelsen til ~25 % i de fleste tilfeller.
vm.dirty_ratio/dirty_bytes
Det er det samme som vm.dirty_background_ratio/dirty_background_bytes, bortsett fra at tilbakestillingen utføres i en arbeiderøkt, og blokkerer applikasjonen. Derfor bør vm.dirty_ratio være høyere enn vm.dirty_background_ratio. Dette sikrer at bakgrunnsprosesser starter tidligere for å unngå blokkering av applikasjonen så mye som mulig. Du kan justere forskjellen mellom disse to forholdene avhengig av disk I/O-belastningen.
Total
Du kan justere andre innstillinger for å forbedre ytelsen, men forbedringene vil være minimale og du vil ikke se mye nytte. Vi må huske at ikke alle alternativer gjelder for alle typer applikasjoner. Noen apper fungerer bedre når vi justerer noen innstillinger, og noen gjør det ikke. Du må finne den riktige balansen mellom å konfigurere disse innstillingene for din forventede arbeidsmengde og applikasjonstype, og du må også vurdere OS-atferd når du justerer. Konfigurering av kjerneparametere er ikke like enkelt som å konfigurere databaseparametere; det er vanskeligere å komme med anbefalinger.
Kilde: www.habr.com