Optimal ydeevne for PostgreSQL afhænger af korrekt definerede parametre i operativsystemet. Dårligt konfigurerede kerneparametre kan føre til nedsat ydeevne for databaseserveren. Derfor er det vigtigt, at disse parametre er tilpasset databaseserveren og dens arbejdsbelastning. I dette indlæg vil vi diskutere nogle vigtige Linux kerneparametre, der kan påvirke ydeevnen for databaseserveren og måder at konfigurere dem på.
SHMMAX / SHMALL
SHMMAX — er et kerneparameter, der bruges til at bestemme den maksimale størrelse af et enkelt segment af delt hukommelse (shared memory), som en Linux-proces kan allokere. Inden version 9.2 brugte PostgreSQL System V (SysV), som krævede konfiguration af SHMMAX. Efter 9.2 skiftede PostgreSQL til POSIX delt hukommelse. Så nu kræves der færre bytes af System V delt hukommelse.
Inden version 9.3 var SHMMAX det vigtigste kerneparameter. Værdien af SHMMAX angives i bytes.
På samme måde, SHMALL — er et andet kerneparameter, der bruges til at bestemme
den samlede mængde sider med delt hukommelse (shared memory). For at se de nuværende værdier for SHMMAX, SHMALL eller SHMMIN, brug kommandoen ipcs.
SHM* Detaljer — Linux
$ ipcs -lm
------ Begrænsninger for Delt Hukommelse --------
maks antal segmenter = 4096
maks segmentstørrelse (kbytes) = 1073741824
maks total delt hukommelse (kbytes) = 17179869184
min segmentstørrelse (bytes) = 1SHM* Detaljer — MacOS X
$ ipcs -M
IPC status fra per Thu Aug 16 22:20:35 PKT 2018
shminfo:
shmmax: 16777216 (maks delt hukommelsessegment størrelse)
shmmin: 1 (min delt hukommelsessegment størrelse)
shmmni: 32 (maks antal af delt hukommelsesidentifikatorer)
shmseg: 8 (maks antal delt hukommelsessegmenter pr. proces)
shmall: 1024 (maks mængde delt hukommelse i sider)
PostgreSQL bruger System V IPC til at allokere delt hukommelse. Dette parameter er en af de vigtigste kerneparametre. Hver gang du får følgende fejlmeddelelser, betyder det, at du har en ældre version af PostgreSQL og et meget lavt værdien af SHMMAX. Det forventes, at brugerne justerer og øger værdien i overensstemmelse med den delte hukommelse, de planlægger at bruge.
Mulige fejl ved forkert konfiguration
Hvis SHMMAX ikke er korrekt konfigureret, kan du få en fejl, når du forsøger at initialisere en PostgreSQL-klynge med kommandoen initdb.
initdb Fejl
DETAIL: Den fejlede systemopkald var shmget(key=1, size=2072576, 03600).
HINT: Denne fejl betyder normalt, at PostgreSQLs anmodning om et delt hukommelsessegment oversteg din kerne SHMMAX parameter.
Du kan enten reducere anmodningsstørrelsen eller omkonfigurere kernen med en større SHMMAX. For at reducere anmodningsstørrelsen (i øjeblikket 2072576 bytes),
reducer PostgreSQLs brugerdefinerede hukommelsesforbrug, muligvis ved at reducere shared_buffers eller max_connections.
Hvis anmodningsstørrelsen allerede er lille, er det muligt, at den er mindre end din kernes SHMMIN-parameter,
i hvilket tilfælde det er nødvendigt at hæve anmodningsstørrelsen eller omkonfigurere SHMMIN.
PostgreSQL-dokumentationen indeholder flere oplysninger om konfiguration af delt hukommelse. Barnprocessen afsluttede med exit-kode 1
På samme måde kan du få en fejl, når du starter PostgreSQL-serveren ved at bruge kommandoen pg_ctl.
pg_ctl Fejl
DETALJER: Den mislykkedes systemopkald var shmget(key=5432001, size=14385152, 03600).
HINT: Denne fejl betyder normalt, at PostgreSQLs anmodning om et delt hukommelsessegment oversteg din kerne SHMMAX parameter.
Du kan enten reducere anmodningsstørrelsen eller omkonfigurere kernen med en større SHMMAX.; For at reducere anmodningsstørrelsen (i øjeblikket 14385152 bytes), reducer PostgreSQLs brugerdefinerede hukommelsesforbrug, muligvis ved at reducere shared_buffers eller max_connections.
Hvis anmodningsstørrelsen allerede er lille, er det muligt, at den er mindre end din kernes SHMMIN-parameter,
i hvilket tilfælde det er nødvendigt at hæve anmodningsstørrelsen eller omkonfigurere SHMMIN.
PostgreSQL-dokumentationen indeholder flere oplysninger om konfiguration af delt hukommelse.
Forståelse af forskellene i definitionerne
Definitionen af SHMMAX/SHMALL-parameterne adskiller sig lidt i Linux og MacOS X:
- Linux: kernel.shmmax, kernel.shmall
- MacOS X: kern.sysv.shmmax, kern.sysv.shmalloc
Kommandoen sysctl kan bruges til midlertidigt at ændre værdien. For at indstille permanente værdier skal du tilføje en post i /etc/sysctl.conf. Flere detaljer er givet nedenfor.
Ændring af kernelparametre 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 kernelparametre 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 -> 16777216Husk at: for at gøre ændringerne permanente, skal du tilføje disse værdier til /etc/sysctl.conf
Store sider (Huge Pages)
I Linux bruges som standard hukommelsessider på 4 KB, i BSD — Super Pages, og i Windows — Large Pages. En side er en del af det direkte hukommelse, der er tildelt en proces. En proces kan have flere sider afhængigt af hukommelseskravene. Jo mere hukommelse processen kræver, jo flere sider tildeles den. OS understøtter en tildelingsoversigt for sider til processer. Jo mindre størrelsen på siden er, jo større er tabellen, og jo mere tid tager det at finde siden i denne sideoversigt. Derfor gør store sider det muligt at bruge store mængder hukommelse med reducerede omkostninger; færre sidevisninger, færre sidfejl, hurtigere læse-/skriveoperationer via større buffere. Som resultat — forbedring af ydeevnen.
PostgreSQL understøtter store sider kun på Linux. Som standard bruger Linux 4 KB hukommelsessider, så i tilfælde, hvor der er mange hukommelsesoperationer, er det nødvendigt at indstille større sider. Der kan observeres en præstationsforøgelse ved brug af store sider på 2 MB og op til 1 GB. Størrelsen på en stor side kan indstilles ved opstart. Du kan nemt kontrollere indstillingerne for store sider og deres anvendelse på din Linux-computer ved at bruge kommandoen cat /proc/meminfo | grep -i huge.
Hentning af information om store sider (kun på Linux)
Bemærk: Dette er kun for Linux, for andre OS ignoreres denne handling$ 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 størrelsen på den store side er indstillet til 2048 (2 MB), er det samlede antal store sider 0. Det betyder, at store sider er deaktiveret.
Script til at bestemme antallet af store sider
Dette er et enkelt script, der returnerer det nødvendige antal store sider. Kør scriptet på din Linux-server, mens PostgreSQL kører. Sørg for at miljøvariablen $PGDATA angiver PostgreSQL-datakatalogen.
Hentning af det krævede antal 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: $hpScriptudgangen ser således ud:
Scriptudgangen
Pid: 12737
VmPeak: 180932 kB
Hugepagesize: 2048 kB
Set Huge Pages: 88Det anbefalede antal store sider er 88, så du skal indstille værdien til 88.
Indstilling af store sider
sysctl -w vm.nr_hugepages=88Tjek store sider nu, og du vil se, at store sider ikke bruges (HugePages_Free = HugePages_Total).
Igen information om store sider (kun 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 kBNu skal du indstille parameteren huge_pages "on" i $PGDATA/postgresql.conf og genstarte serveren.
Igen information om store sider (kun 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 kBNu kan du se, at der bruges meget få store sider. Lad os nu prøve at tilføje nogle data til databasen.
Nogle databaseoperationer til håndtering af store sider
postgres=# Opret TABELO foo(a INTEGER);
Opret TABEL
postgres=# Indsæt i foo VALUES(generate_Series(1,10000000));
INDsæt 0 10000000Lad os se, om vi i øjeblikket bruger flere store sider end før.
Her er igen oplysninger 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 kBNu kan du se, at de fleste store sider er i brug.
Bemærk: Den omtrentlige værdi for HugePages, der bruges her, er meget lav, hvilket ikke er et normalt niveau for en produktionsmaskine. Vurder venligst det nødvendige antal sider til dit system, og indstil dem i overensstemmelse hermed, afhængigt af belastning og ressourcer.
vm.swappiness
vm.swappiness — er en anden kerneparameter, der kan påvirke databaseydelsen. Denne parameter bruges til at styre udvekslingsadfærden (swappiness) (udveksling af sider til og fra hukommelsen) i Linux. Værdien varierer fra 0 til 100. Den definerer, hvor meget hukommelse der vil blive udpumpet eller udfaset. Nul betyder deaktivering af udveksling, mens 100 betyder aggressiv udveksling.
Du kan opnå god ydeevne ved at indstille lavere værdier.
Indstilling af værdien 0 i nyere kerner kan medføre, at OOM Killer (hukommelsesrensningsprocessen i Linux) dræber processen. Derfor kan du sikkert indstille værdien til 1, hvis du vil minimere udvekslingen. Standardværdien i Linux er 60. En højere værdi får MMU (hukommelseskontrolblok) til at bruge mere udvekslingsplads end RAM, mens en lavere værdi bevarer flere data/kode i hukommelsen.
En lavere værdi er et godt valg for at forbedre ydeevnen i PostgreSQL.
vm.overcommit_memory / vm.overcommit_ratio
Applikationer får 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 udløse OOM killer. Her er mulige værdier for parameteren vm.overcommit_memory med beskrivelse for hver:
- Heuristisk overcommit (standard); kernebaseret heuristik
- Tillad overcommit under alle omstændigheder
- Overcommit ikke for meget, overskrid ikke overcommit-forholdet.
Link:
vm.overcommit_ratio — procent af RAM, der er tilgængelig til overdreven belastning. En værdi på 50% i et system med 2 GB RAM kan allokere op til 3 GB RAM.
Værdi 2 for vm.overcommit_memory sikrer bedre ydeevne for PostgreSQL. Denne værdi maksimerer brugen af RAM af serverprocessen uden betydelig risiko for at blive dræbt af OOM-killer-processen. Applikationen kan genstartes, men kun inden for rammerne af overforbruget, hvilket mindsker risikoen for, at OOM-killer dræber processen. Derfor giver værdi 2 bedre ydeevne end standardværdien 0. Dog kan pålideligheden forbedres ved at undgå, at hukommelse uden for det acceptable område bliver overbelastet. Dette udelukker risikoen for, at processen bliver dræbt af OOM-killer.
I systemer uden swap kan der opstå problemer med vm.overcommit_memory, der er sat til 2.
vm.dirty_background_ratio / vm.dirty_background_bytes
vm.dirty_background_ratio — er procentdelen af hukommelse, der er fyldt med beskidte sider, som skal skrives til disk. Skylning til disk sker i baggrunden. Værdien af denne parameter varierer fra 0 til 100; dog kan værdier under 5 være ineffektive, og nogle kerner understøtter dem ikke. 10 er standardværdien i de fleste Linux-systemer. Du kan forbedre ydeevnen for I/O-intensive operationer med en lavere koefficient, hvilket betyder, at Linux vil skylle beskidte sider i baggrunden.
Du skal indstille værdien vm.dirty_background_bytes afhængigt af hastigheden på din disk.
Der er ingen 'gode' værdier for disse to parametre, da begge afhænger af hardwaren. Dog øger indstillingen af vm.dirty_background_ratio til 5 og vm.dirty_background_bytes til 25% af diskens hastighed ydeevnen med omkring 25% i de fleste tilfælde.
vm.dirty_ratio / dirty_bytes
Dette er det samme som vm.dirty_background_ratio / dirty_background_bytes, bortset fra at skylningen udføres i den aktive session, hvilket blokerer applikationen. Derfor skal vm.dirty_ratio være højere end vm.dirty_background_ratio. Dette sikrer, at baggrundsprocesser starter tidligere for at undgå maksimal blokering af applikationen. Du kan justere forskellen mellem disse to forhold afhængigt af belastningen på disk I/O.
Resultat
Du kan justere andre indstillinger for at øge ydeevnen, men forbedringerne vil være minimale, og du vil ikke få nogen væsentlige fordele. Vi skal huske, at ikke alle indstillinger gælder for alle applikationstyper. Nogle applikationer fungerer bedre, når vi justerer visse indstillinger, mens andre ikke gør. Du skal finde den rette balance mellem konfigurationerne af disse indstillinger for den forventede arbejdsbelastning og applikationstypen, og samtidig skal du tage hensyn til operativsystemets adfærd. At justere kerneindstillingerne er ikke så enkelt som at justere databaseindstillingerne: det er vanskeligere at give anbefalinger her.
Kilde: habr.com
