Konfigurera kärnparametrar Linux för att optimera PostgreSQL

Optimal PostgreSQL-prestanda är beroende av korrekt konfigurerade operativsystemparametrar. Dåligt konfigurerade kärnparametrar kan leda till försämrad databasserverprestanda. Därför är det viktigt att konfigurera dessa parametrar på lämpligt sätt för databasservern och dess arbetsbelastning. I det här inlägget kommer vi att diskutera några viktiga kärnparametrar. Linux, vilket kan påverka databasserverns prestanda och hur man konfigurerar dem.

SHMMAX / SHMALL

SHMMAX — är en kärnparameter som används för att bestämma den maximala storleken på ett enskilt delat minnessegment som en process kan allokera. LinuxFöre version 9.2 använde PostgreSQL System V (SysV), vilket kräver SHMMAX-inställningen. Efter 9.2 bytte PostgreSQL till delat POSIX-minne. Detta innebär att färre byte av delat System V-minne nu krävs.

Före version 9.3 var SHMMAX den viktigaste kärnparametern. SHMMAX-värdet anges i byte.

Liknande, SHMALL är en annan kärnparameter som används för att bestämma
systemomfattande volym av delade minnessidor. För att se aktuella SHMMAX-, SHMALL- eller SHMMIN-värden, använd kommandot 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) = 1

SHM* 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 använder System V IPC för att tilldela delat minne. Denna parameter är en av de viktigaste kärnparametrarna. När du får följande felmeddelanden betyder det att du har en äldre version av PostgreSQL och att ditt SHMMAX-värde är mycket lågt. Användare förväntas justera och öka värdet enligt det delade minnet de tänker använda.

Möjliga felkonfigurationsfel

Om SHMMAX inte är korrekt konfigurerat kan du få ett felmeddelande när du försöker initiera ett PostgreSQL-kluster med kommandot initdb.

initdb misslyckande
DETAIL: Failed system call was shmget(key=1, size=2072576, 03600).

TIPS: Det här felet betyder vanligtvis att PostgreSQLs begäran om ett delat minnessegment överskred din kärnas SHMMAX-parameter. 
Du kan antingen minska förfrågningsstorleken eller omkonfigurera kärnan med större SHMMAX. För att minska begäranstorleken (för närvarande 2072576 byte),
minska PostgreSQLs delade minnesanvändning, kanske genom att minska shared_buffers eller max_connections.

Om förfrågningsstorleken redan är liten är det möjligt att den är mindre än din kärnas SHMMIN-parameter,
i vilket fall det krävs att man ökar förfrågningsstorleken eller konfigurerar om SHMMIN.

PostgreSQL-dokumentationen innehåller mer information om konfiguration av delat minne. barnprocessen avslutades med avslutningskod 1

På samma sätt kan du få ett felmeddelande när du startar PostgreSQL-servern med kommandot pg_ctl.

pg_ctl Fel
DETAIL: Failed system call was shmget(key=5432001, size=14385152, 03600).

TIPS: Det här felet betyder vanligtvis att PostgreSQLs begäran om ett delat minnessegment överskred din kärnas SHMMAX-parameter.

Du kan antingen minska förfrågningsstorleken eller omkonfigurera kärnan med större SHMMAX. För att minska förfrågningsstorleken (för närvarande 14385152 byte), minska PostgreSQLs delade minnesanvändning, kanske genom att minska shared_buffers eller max_connections.

Om förfrågningsstorleken redan är liten är det möjligt att den är mindre än din kärnas SHMMIN-parameter,
i vilket fall det krävs att man ökar förfrågningsstorleken eller konfigurerar om SHMMIN.

PostgreSQL-dokumentationen innehåller mer information om konfiguration av delat minne.

Förstå skillnaderna i definitioner

Definitionen av SHMMAX/SHMALL-parametrarna är något annorlunda i Linux och MacOS X:

• Linuxkärna.shmmax, kärna.shmall
• MacOS X: kern.sysv.shmmax, kern.sysv.shmall

Team sysctl kan användas för att tillfälligt ändra värdet. Lägg till en post för att ställa in konstanta värden /etc/sysctl.conf. Detaljer finns nedan.

Ändra kärninställningar 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

Ändra kärnparametrar 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 -> 16777216

Glöm inte: För att göra ändringar permanenta, lägg till dessa värden till /etc/sysctl.conf

Enorma sidor

В Linux Som standard används 4 KB minnessidor, i BSD - Super Pages, och i Windows - Stora sidor. En sida är en bit RAM-minne som allokeras till en process. En process kan ha flera sidor beroende på minneskrav. Ju mer minne en process kräver, desto fler sidor tilldelas den. OS upprätthåller en sidtilldelningstabell för processer. Ju mindre sidstorlek, desto större tabell, desto längre tid tar det att hitta en sida i den sidtabellen. Stora sidor tillåter därför att stora mängder minne kan användas med minskad omkostnad; färre sidvisningar, färre sidfel, snabbare läs-/skrivoperationer över större buffertar. Resultatet är förbättrad prestanda.

PostgreSQL stöder endast stora sidor i Linux. Standard Linux använder 4 KB minnessidor, så i fall där det finns många minnesoperationer är det nödvändigt att ställa in större sidor. Prestandaförbättringar observeras när man använder stora sidor på 2 MB och upp till 1 GB. Storleken för stora sidor kan ställas in vid start. Du kan enkelt kontrollera inställningarna för stora sidor och deras användning på din Linux-dator med hjälp av kommandot cat /proc/meminfo | grep -i enorm.

Hämta information om stora sidor (endast på 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 kB

I det här exemplet, även om den stora sidstorleken är inställd på 2048 (2 MB), är det totala antalet stora sidor satt till 0. Detta betyder att stora sidor är inaktiverade.

Skript för att bestämma antalet stora sidor

Det här enkla skriptet returnerar det erforderliga antalet stora sidor. Kör skriptet på din server. Linuxmedan PostgreSQL körs. Se till att miljövariabeln $PGDATA PostgreSQL-datakatalogen är specificerad.

Få det antal stora sidor som krävs

#!/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:     $hp

Skriptutgången ser ut så här:

Skriptutgång

Pid:            12737
VmPeak:         180932 kB
Hugepagesize:   2048 kB
Set Huge Pages: 88

Det rekommenderade värdet för stora sidor är 88, så du bör ställa in det på 88.

Installera stora sidor

sysctl -w vm.nr_hugepages=88

Kontrollera stora sidor nu, du kommer att se att stora sidor inte används (HugePages_Free = HugePages_Total).

Mer information om stora sidor (endast 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 kB

Ställ nu parametern huge_pages till "on" i $PGDATA/postgresql.conf och starta om servern.

Och återigen information om stora sidor (endast 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 kB

Nu kan du se att väldigt få stora sidor används. Låt oss nu försöka lägga till lite data till databasen.

Vissa databasoperationer för att återvinna stora sidor

postgres=# CREATE TABLE foo(a INTEGER);
CREATE TABLE
postgres=# INSERT INTO foo VALUES(generate_Series(1,10000000));
INSERT 0 10000000

Låt oss se om vi använder fler stora sidor nu än tidigare.

Återigen information om stora sidor (endast 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 kB

Nu kan du se att de flesta av de stora sidorna används.

Obs: Det uppskattade värdet för HugePages som används här är mycket lågt, vilket inte är ett normalt värde för en maskin som kör en produktmiljö. Uppskatta det nödvändiga antalet sidor för ditt system och ställ in dem baserat på belastning och resurser.

vm.byte

vm.byte — är en annan kärnparameter som kan påverka databasens prestanda. Denna parameter används för att styra växlingsbeteendet (växling av sidor in i och ut ur minnet) i LinuxVärdet varierar från 0 till 100. Det avgör hur mycket minne som ska bytas ut eller bytas ut. Noll betyder ingen växling och 100 betyder aggressiv växling.

Du kan få bra prestanda genom att sätta lägre värden.

Att sätta värdet till 0 i nyare kärnor kan orsaka att OOM Killer (minnesrensningsprocessen i Linux) kommer att avsluta processen. Så det är säkert att sätta värdet till 1 om du vill minimera växling. Standardvärdet är Linux - 60. Ett högre värde gör att MMU (minneshanteringsenheten) använder mer växlingsutrymme än RAM, medan ett lägre värde lagrar mer data/kod i minnet.

Ett lägre värde är en bra insats för förbättrad prestanda i PostgreSQL.

vm.overcommit_memory / vm.overcommit_ratio

Applikationer skaffar minne och släpper det när det inte längre behövs. Men i vissa fall får programmet för mycket minne och släpper det inte. Detta kan orsaka en OOM-mördare. Här är de möjliga parametervärdena vm.overcommit_memory med en beskrivning för varje:

1. Heuristisk overcommit (standard); kärnbaserad heuristik
2. Tillåt övercommit ändå
3. Överdriv inte, överskrid inte överenskommelsesförhållandet.

länk: https://www.kernel.org/doc/Documentation/vm/overcommit-accounting

vm.overcommit_ratio — procentandel RAM tillgängligt för överbelastning. Ett värde på 50 % på ett system med 2 GB RAM kan allokera upp till 3 GB RAM.

Ett värde på 2 för vm.overcommit_memory ger bättre prestanda för PostgreSQL. Detta värde maximerar serverprocessens RAM-användning utan någon betydande risk att dödas av OOM-mördarprocessen. Applikationen kommer att kunna laddas om, men bara inom gränserna för överskridande, vilket minskar risken för att en OOM-mördare dödar processen. Därför ger ett värde på 2 bättre prestanda än standardvärdet på 0. Tillförlitligheten kan dock förbättras genom att säkerställa att minnet utanför intervallet inte överbelastas. Detta eliminerar risken för att processen dödas av en OOM-mördare.

På system utan byte kan ett problem med vm.overcommit_memory lika med 2 uppstå.

https://www.postgresql.org/docs/current/static/kernel-resources.html#LINUX-MEMORY-OVERCOMMIT

vm.dirty_background_ratio / vm.dirty_background_bytes

vm.dirty_background_ratio — Detta är andelen minne som är fyllt med smutsiga sidor som behöver spolas till disk. Denna spolning sker i bakgrunden. Parameterns värde varierar från 0 till 100; ett värde under 5 kan dock vara ineffektivt, och vissa kärnor stöder det inte. 10 är standardvärdet på de flesta system. LinuxDu kan förbättra prestandan för skrivintensiva operationer med en mindre förhållande, vilket innebär att Linux kommer att spola bort smutsiga sidor i bakgrunden.

Du måste ställa in värdet vm.dirty_background_bytes beroende på hastigheten på din körning.

Det finns inga "bra" värden för dessa två parametrar eftersom båda är hårdvaruberoende. Men om du ställer in vm.dirty_background_ratio till 5 och vm.dirty_background_bytes till 25 % av diskhastigheten förbättras prestandan till ~25 % i de flesta fall.

vm.dirty_ratio/dirty_bytes

Det är samma sak som vm.dirty_background_ratio/dirty_background_bytes, förutom att återställningen utförs i en arbetssession, vilket blockerar applikationen. Därför bör vm.dirty_ratio vara högre än vm.dirty_background_ratio. Detta säkerställer att bakgrundsprocesser startar tidigare för att undvika att blockera applikationen så mycket som möjligt. Du kan justera skillnaden mellan dessa två förhållanden beroende på diskens I/O-belastning.

Totalt

Du kan justera andra inställningar för att förbättra prestandan, men förbättringarna kommer att vara minimala och du kommer inte att se mycket nytta. Vi måste komma ihåg att inte alla alternativ gäller alla typer av applikationer. Vissa appar fungerar bättre när vi justerar vissa inställningar, och andra inte. Du måste hitta den rätta balansen mellan att konfigurera dessa inställningar för din förväntade arbetsbelastning och applikationstyp, och du måste också ta hänsyn till OS-beteende vid justering. Att konfigurera kärnparametrar är inte lika lätt som att konfigurera databasparametrar, det är svårare att ge rekommendationer.

Källa: will.com