Optimal ytelse for PostgreSQL avhenger av riktig konfigurerte parametere for operativsystemet. Dårlig justerte kjerneparametere kan føre til redusert ytelse for databaseserveren. Derfor er det avgjørende at disse parameterne er konfigurert i samsvar med databaseserveren og dens arbeidsmengde. I dette innlegget vil vi diskutere noen viktige Linux kjerneparametere som kan påvirke ytelsen til databaseserveren og hvordan de kan justeres.
SHMMAX / SHMALL
SHMMAX — er en kjerneparameter som benyttes for å definere maksimal størrelse på et enkelt segment av delt minne (shared memory) som en Linux-prosess kan tildele. Frem til versjon 9.2 brukte PostgreSQL System V (SysV), som krevde innstilling av SHMMAX. Etter 9.2 skiftet PostgreSQL til POSIX-delt minne. Så nå kreves det færre bytes av System V delt minne.
Frem til versjon 9.3 var SHMMAX den viktigste kjerneparameteren. Verdien av SHMMAX angis i bytes.
Tilsvarende, SHMALL — er en annen kjerneparameter som brukes for å definere
det totale antallet sider av delt minne (shared memory). For å se nåværende verdier av SHMMAX, SHMALL eller SHMMIN, bruk kommandoen ipcs.
SHM* Detaljer — Linux
$ ipcs -lm
------ Grense for Delt Minne --------
maks antall segmenter = 4096
maks segmentstørrelse (kbytes) = 1073741824
maks totalt delt minne (kbytes) = 17179869184
min segmentstørrelse (bytes) = 1SHM* Detaljer — MacOS X
$ ipcs -M
IPC-status fra as of Thu Aug 16 22:20:35 PKT 2018
shminfo:
shmmax: 16777216 (maks delt minnesegment størrelse)
shmmin: 1 (min delt minnesegment størrelse)
shmmni: 32 (maks antall identifikatorer for delt minne)
shmseg: 8 (maks antall segmenter av delt minne per prosess)
shmall: 1024 (maks mengde delt minne i sider)
PostgreSQL bruker System V IPC for å tildele delt minne. Denne parameteren er en av de viktigste kjerneparameterne. Hver gang du får følgende feilmeldinger, betyr det at du har en eldre versjon av PostgreSQL og at du har en veldig lav verdi for SHMMAX. Det forventes at brukere justerer og øker verdien i henhold til det delte minnet de planlegger å bruke.
Mulige feil ved feilkonfigurering
Hvis SHMMAX er feil konfigurert, kan du få en feil når du forsøker å initialisere PostgreSQL-klyngen ved hjelp av kommandoen initdb.
initdb Feil
DETALJ: Den mislykkede systemkallet var shmget(key=1, size=2072576, 03600).
HINT: Denne feilen betyr vanligvis at PostgreSQLs forespørsel om et segment av delt minne oversteg kjernens SHMMAX-parameter.
Du kan enten redusere forespørselstørrelsen eller omkonfigurere kjernen med større SHMMAX. For å redusere forespørselstørrelsen (for tiden 2072576 bytes),
reduser PostgreSQLs bruk av delt minne, kanskje ved å redusere shared_buffers eller max_connections.
Hvis forespørselstørrelsen allerede er liten, er det mulig at den er mindre enn kjernens SHMMIN-parameter,
i så fall må forespørselstørrelsen heves eller SHMMIN omkonfigureres.
PostgreSQL-dokumentasjonen inneholder mer informasjon om konfigurasjon av delt minne. barneprosess avsluttet med avslutningskode 1
På samme måte kan du få en feil ved oppstart av PostgreSQL-serveren ved å bruke kommandoen pg_ctl.
pg_ctl-feil
DETALJ: Den mislykkede systemanropet var shmget(key=5432001, size=14385152, 03600).
HINT: Denne feilen betyr vanligvis at PostgreSQLs forespørsel om et segment av delt minne oversteg kjernens SHMMAX-parameter.
Du kan enten redusere forespørselstørrelsen eller omkonfigurere kjernen med større SHMMAX.; For å redusere forespørselstørrelsen (for tiden 14385152 bytes), reduser PostgreSQLs bruk av delt minne, kanskje ved å redusere shared_buffers eller max_connections.
Hvis forespørselstørrelsen allerede er liten, er det mulig at den er mindre enn kjernens SHMMIN-parameter,
i så fall må forespørselstørrelsen heves eller SHMMIN omkonfigureres.
PostgreSQL-dokumentasjonen inneholder mer informasjon om konfigurasjon av delt minne.
Forstå forskjellene i definisjoner
Definisjonen av SHMMAX/SHMALL-parameterne varierer noe mellom Linux og MacOS X:
- Linux: kernel.shmmax, kernel.shmall
- MacOS X: kern.sysv.shmmax, kern.sysv.shmall
Laget sysctl kan brukes til midlertidig å endre verdien. For å sette permanente verdier, legg til en post i /etc/sysctl.conf. Detaljer er gitt nedenfor.
Endring av kjernens parametere 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 -> 16777216Endring av kjernens parametere 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 glem: for å gjøre endringene permanente, legg disse verdiene inn i /etc/sysctl.conf
Store sider (Huge Pages)
I Linux brukes som standard 4 KB minnesider, i BSD — Super Pages, og i Windows — Large Pages. En side er en del av RAM-en som tildeles en prosess. Prosessen kan ha flere sider avhengig av minnebehovene. Jo mer minne prosessen trenger, desto flere sider tildeles den. OSet opprettholder en sideallokerings-tabell for prosesser. Jo mindre størrelsen på en side, desto større blir tabellen, og desto mer tid tar det å finne en side i denne siden-tabellen. Derfor lar store sider deg bruke en stor mengde minne med redusert overhead; færre sidevisninger, færre sidefeil, raskere lese/skrive-operasjoner via større buffere. Som et resultat — forbedret ytelse.
PostgreSQL støtter store sider bare på Linux. Som standard bruker Linux 4 KB minnesider, så i tilfeller der det er for mange minneoperasjoner, må du sette sider av større størrelse. Det er ytelsesforbedringer ved å bruke store sider som er 2 MB og opp til 1 GB. Størrelsen på den store siden kan settes ved oppstart. Du kan enkelt sjekke parametrene for store sider og bruken deres på Linux-datamaskinen din ved å bruke kommandoen cat /proc/meminfo | grep -i huge.
Innhenting av informasjon om store sider (bare på Linux)
Merk: Dette er bare for Linux, for andre operativsystemer blir denne operasjonen ignorert$ 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 størrelsen på den store siden er satt til 2048 (2 MB), er det totale antallet store sider 0. Dette betyr at store sider er deaktivert.
Script for å bestemme antall store sider
Dette er et enkelt script som returnerer det nødvendige antallet store sider. Kjør scriptet på Linux-serveren din mens PostgreSQL kjører. Forsikre deg om at miljøvariabelen $PGDATA er satt til katalogen for PostgreSQL-data.
Henting av tallet for 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: $hpUtdataene fra scriptet ser slik ut:
Utdata fra scriptet
Pid: 12737
VmPeak: 180932 kB
Hugepagesize: 2048 kB
Set Huge Pages: 88Anbefalt verdi for store sider er 88, så du bør sette verdien til 88.
Sette store sider
sysctl -w vm.nr_hugepages=88Sjekk store sider nå, du vil se at store sider ikke er i bruk (HugePages_Free = HugePages_Total).
Igjen informasjon om store sider (bare på 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 kBNå setter du parameteren huge_pages til «on» i $PGDATA/postgresql.conf og starter serveren på nytt.
Og igjen informasjon om store sider (bare på 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 er i bruk. La oss nå prøve å legge til noen data i databasen.
Noen databasemanipuleringer for gjenbruk av 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 nå bruker flere store sider enn vi gjorde tidligere.
Ny informasjon om store sider (kun på 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 det meste av de store sidene brukes.
Merk: det anslåtte tallet for HugePages som brukes her, er ganske lavt, noe som ikke er normalt for en produksjonsmaskin. Vennligst vurder hvor mange sider som trengs for systemet ditt og sett dem deretter i henhold til lasten og ressursene.
vm.swappiness
vm.swappiness — er et annet kjernalternativ som kan påvirke databasenes ytelse. Denne parameteren brukes til å styre oppførselen til swap (swappiness) (bytte sider til og fra minnet) i Linux. Verdien varierer fra 0 til 100. Det angir hvor mye minne som vil bli dumpt eller byttet ut. Null betyr at bytting er deaktivert, mens 100 betyr aggressiv bytting.
Du kan oppnå god ytelse ved å sette lavere verdier.
Å sette verdien til 0 i nyere kjerner kan føre til at OOM Killer (minnerengjøringsprosessen i Linux) dreper prosessen. Derfor kan det trygt settes til 1 hvis du vil minimere bytting. Standardverdien i Linux er 60. Høyere verdi får MMU (minnekontrolleren) til å bruke mer swap plass enn RAM, mens lavere verdi beholder mer data/kode i minnet.
Lavere verdi er en god innsats for å forbedre ytelsen i PostgreSQL.
vm.overcommit_memory / vm.overcommit_ratio
Applikasjoner får minne og frigjør det når det ikke lenger er nødvendig. Men i noen tilfeller får applikasjonen altfor mye minne og frigjør det ikke. Dette kan utløse OOM killer. Her er mulige verdier for parameteren vm.overcommit_memory med beskrivelse for hver:
- Heuristisk overcommit (standard); kjernebassert heuristikk
- Tillat overcommit uansett
- Ikke overdrive, ikke overskrid overcommit-forholdet.
Lenke:
vm.overcommit_ratio — prosent av minnet som er tilgjengelig for overkompensering. Verdien 50% i et system med 2 GB RAM kan tildele opptil 3 GB RAM.
Verdien 2 for vm.overcommit_memory gir bedre ytelse for PostgreSQL. Denne verdien maksimerer bruken av RAM av serverprosessen uten betydelig risiko for å bli drept av OOM-killer-prosessen. Applikasjonen kan starte på nytt, men bare innenfor overkompensasjonen, noe som reduserer risikoen for at OOM-killer dreper prosessen. Dermed gir verdien 2 bedre ytelse enn standardverdien 0. Imidlertid kan påliteligheten forbedres da minnet utenfor den tillatte grensen ikke vil bli overkompensert. Dette eliminerer risikoen for at prosessen blir drept av OOM-killer.
I systemer uten sidefil kan det oppstå problemer 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. Skriving til disk skjer i bakgrunnen. Verdien av denne parameteren varierer fra 0 til 100; imidlertid kan verdier under 5 være ineffektive, og noen kjerner støtter dem ikke. 10 er standardverdien i de fleste Linux-systemer. Du kan forbedre ytelsen for skriveintensive operasjoner med en lavere ratio, noe som betyr at Linux vil skrive skitne sider i bakgrunnen.
Du må angi verdien vm.dirty_background_bytes avhengig av hastigheten på disken din.
Det finnes ingen “gode” verdier for disse to parameterne, da begge avhenger av maskinvaren. Imidlertid, ved å sette vm.dirty_background_ratio til 5 og vm.dirty_background_bytes til 25% av diskhastigheten, kan ytelsen økes med omtrent 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 skrivingen skjer i aktiv sesjon, og blokkerer applikasjonen. Derfor må vm.dirty_ratio være høyere enn vm.dirty_background_ratio. Dette sikrer at bakgrunnsprosesser starter tidligere for å unngå maksimal blokkering av applikasjonen. Du kan justere forskjellen mellom disse to forholdene avhengig av belastningen på disk I/O.
Resultat
Du kan konfigurere andre parametere for å øke ytelsen, men forbedringene vil være minimale og gevinstene vil ikke være betydelige. Vi må huske at ikke alle parametere gjelder for alle typer applikasjoner. Noen applikasjoner fungerer bedre når vi justerer visse parametere, mens andre ikke gjør det. Du må finne den riktige balansen mellom konfigurasjonene av disse parameterne for den forventede arbeidsbelastningen og typen applikasjon, og når du konfigurerer, må du også ta hensyn til oppførselen til operativsystemet. Å justere kjernerparametere er ikke så enkelt som å justere databaseparametere: her er det vanskeligere å gi anbefalinger.
Kilde: habr.com
Russian
Italian
German
Polish
Estonian
Albanian
Bulgarian
Croatian
Czech
Danish
Dutch
English
French
Hungarian
Latvian
Norwegian
Portuguese
Romanian
Slovak
Slovenian
Spanish
Swedish