🥇Justering av Linux-kärnparametrar för att optimera PostgreSQL

Optimal prestanda för PostgreSQL beror på korrekt definierade parametrar i operativsystemet. Dåligt konfigurerade kärnparametrar kan leda till minskad prestanda för databasservern. Det är därför viktigt att dessa parametrar är inställda i enlighet med databasservern och dess arbetsbelastning. I detta inlägg kommer vi att diskutera några viktiga Linux-kärnparametrar som kan påverka databasserverns prestanda och hur man konfigurerar dem.

SHMMAX / SHMALL

SHMMAX är en kärnparameter som används för att definiera den maximala storleken på en enskild segment av delad minne (shared memory) som en Linux-process kan allokera. Fram till version 9.2 använde PostgreSQL System V (SysV), vilket kräver konfiguration av SHMMAX. Efter version 9.2 har PostgreSQL övergått till POSIX delat minne. Så nu krävs det mindre byte av System V delat minne.

Fram till version 9.3 var SHMMAX den viktigaste kärnparametern. Värdet på SHMMAX anges i byte.

På samma sätt, SHMALL är en annan kärnparameter som används för att definiera
det totala antalet sidor av delad minne (shared memory). För att se de aktuella värdena av SHMMAX, SHMALL eller SHMMIN, använd kommandot ipcs.

SHM* Detaljer — Linux

$ ipcs -lm

------ Gränser för delat minne --------
max antal segment = 4096
max segmentstorlek (kbytes) = 1073741824
max totalt delat minne (kbytes) = 17179869184
min segmentstorlek (bytes) = 1

SHM* Detaljer — MacOS X

$ ipcs -M
IPC-status från  den 16 aug 2018 22:20:35 PKT
shminfo:
	shmmax: 16777216	(max storlek på delad minnessegment)
	shmmin:       1	(min storlek på delad minnessegment)
	shmmni:      32	(max antal identifierare för delat minne)
	shmseg:       8	(max antal delade minnessegment per process)
	shmall:    1024	(max mängd delat minne i sidor)

PostgreSQL använder System V IPC för att allokera 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 du har ett mycket lågt värde på SHMMAX. Det förväntas att användare justerar och ökar värdet i enlighet med den delade minneskapacitet de planerar att använda.

Möjliga fel vid felaktig konfiguration

Om SHMMAX är felkonfigurerad kan du få ett fel när du försöker initiera en PostgreSQL-kluster med kommandot initdb.

initdb Failure
DETAIL: Misslyckad systemanrop var shmget(key=1, size=2072576, 03600).

HINT: Detta fel betyder vanligtvis att PostgreSQL:s begäran om ett segment av delat minne överskred din kärnas SHMMAX-parameter.
Du kan antingen minska begärningsstorleken eller konfigurera kärnan med en större SHMMAX. För att minska begärningsstorleken (för närvarande 2072576 byte),
minska PostgreSQLs delade minnesanvändning, kanske genom att minska shared_buffers eller max_connections.

Om begärningsstorleken redan är liten kan det hända att den är mindre än din kärnas SHMMIN-parameter,
i vilket fall det är nödvändigt att höja begärningsstorleken eller omkonfigurera SHMMIN.

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

På samma sätt kan du få ett fel vid start av PostgreSQL-servern med kommandot pg_ctl.

pg_ctl-fel
DETAIL: Det misslyckade systemanropet var shmget(key=5432001, size=14385152, 03600).

HINT: Detta fel betyder vanligtvis att PostgreSQL:s begäran om ett segment av delat minne överskred din kärnas SHMMAX-parameter.

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

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

Förstå skillnaderna i definitionerna

Definitionerna av SHMMAX/SHMALL skiljer sig något mellan Linux och MacOS X:

Linux: kernel.shmmax, kernel.shmall
MacOS X: kern.sysv.shmmax, kern.sysv.shmall

Team sysctl kan användas för att temporärt ändra värdet. För att ställa in permanenta värden, lägg till en post i /etc/sysctl.conf. Detaljer anges nedan.

Ändring av 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

Ändring av kärninställningar 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 ändringarna permanenta, lägg till dessa värden i /etc/sysctl.conf

Stora sidor (Huge Pages)

I Linux används som standard 4 KB minnessidor, i BSD — Super Pages, och i Windows — Large Pages. En sida är en del av RAM-minnet som tilldelas en process. En process kan ha flera sidor beroende på minnesbehovet. Ju mer minne en process behöver, desto fler sidor tilldelas den. OS upprätthåller en sidhanteringstabell för processerna. Ju mindre storlek på sidan, desto större tabell, desto mer tid krävs för att söka efter en sida i denna tabell. Därför tillåter stora sidor att använda stora mängder minne med minskade overheadkostnader; färre sidvisningar, färre sidfel, snabbare läs-/skrivoperationer genom stora buffertar. Resultatet blir en förbättrad prestanda.

PostgreSQL stöder stora sidor endast på Linux. Som standard använder Linux 4 kB minnessidor, så i fall där det finns för många minnesoperationer är det nödvändigt att ställa in sidor av större storlek. En prestandaförbättring kan observeras vid användning av stora sidor på 2 MB och upp till 1 GB. Storleken på 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 genom att använda kommandot cat /proc/meminfo | grep -i huge.

Hämta information om stora sidor (endast på Linux)

Obs: Detta gäller endast för Linux, för andra operativsystem ignoreras denna operation
$ 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 storleken på den stora sidan är inställd på 2048 (2 MB), har det totala antalet stora sidor värdet 0. Detta betyder att stora sidor är avstängda.

Script för att bestämma antalet stora sidor

Detta är ett enkelt skript som returnerar det nödvändiga antalet stora sidor. Kör skriptet på din Linux-server medan PostgreSQL körs. Se till att miljövariabeln $PGDATA är inställd på PostgreSQL:s datakatalog.

Hämta siffran för de nödvändiga stora sidorna

#!/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

Skripts output ser ut som följer:

Skripts output

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 värdet 88.

Ställa in 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).

Än en gång 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

Nu ställer du in parameter huge_pages "on" i $PGDATA/postgresql.conf och startar 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 mycket få stora sidor används. Låt oss nu försöka lägga till lite data i databasen.

Vissa databasoperationer för att hantera 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 för närvarande använder fler stora sidor ä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 stora sidor används.

Observera: 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 produktionsmaskin. Vänligen bedöm det nödvändiga antalet sidor för ditt system och ställ in dem i enlighet med belastning och resurser.

vm.swappiness

vm.swappiness — detta är en annan kärnparameter som kan påverka databasens prestanda. Den här parametern används för att styra swapbeteendet (swappiness) (att swapa sidor in och ut ur minnet) i Linux. Värdet varierar från 0 till 100. Det bestämmer hur mycket minne som kommer att avlastas eller avlastas. Noll betyder att swap inte används, och 100 innebär aggressiv svappning.

Du kan få bra prestanda genom att ställa in lägre värden.

Att sätta värdet 0 i nyare kärnor kan leda till att OOM Killer (minnesrensningsprocessen i Linux) dödar processen. Således kan värdet 1 säkerställas om du vill minimera svappning. Standardvärdet i Linux är 60. Ett högre värde får MMU (minneshanteringsenheten) att använda mer swaputrymme än RAM, medan ett lägre värde behåller mer data/kod i minnet.

Ett lägre värde är en bra insats för att förbättra prestandan i PostgreSQL.

vm.overcommit_memory / vm.overcommit_ratio

Applikationer får minne och frigör det när det inte längre behövs. Men i vissa fall får applikationen för mycket minne och frigör det inte. Detta kan orsaka OOM killer. Här är möjliga värden för parametern vm.overcommit_memory med en beskrivning för varje:

Heuristisk överkommitté (standard); kärn-baserad heuristik
Tillåt överkommitté i alla fall
Överkommitté för mycket, överskrid inte överkommitté koefficienten.

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

vm.overcommit_ratio — procent av RAM-minnet som är tillgängligt för överbelastning. Värdet 50 % i ett system med 2 GB RAM kan tilldela upp till 3 GB RAM.

Värdet 2 för vm.overcommit_memory ger bättre prestanda för PostgreSQL. Det här värdet maximerar användningen av RAM-minne av serverprocessen utan någon betydande risk för att bli dödad av OOM-killern. Applikationen kan startas om, men endast inom överutnyttjandet, vilket minskar risken för att OOM-killern dödar processen. Därför ger värdet 2 bättre prestanda än standardvärdet 0. Å andra sidan kan tillförlitligheten förbättras genom att minnet utanför det tillåtna intervallet inte överbelastas. Detta utesluter risken för att processen dödas av OOM-killern.

I system utan byte kan det uppstå problem med vm.overcommit_memory lika med 2.

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 — är procentandelen av minnet som är fyllt med smutsiga sidor som måste skrivas till disk. Skrivning till disk sker i bakgrunden. Värdet på denna parameter varierar från 0 till 100; dock kan ett värde under 5 vara ineffektivt, och vissa kärnor stöder det inte. 10 är standardvärdet i de flesta Linux-system. Du kan öka prestanda för skrivintensiva operationer med en lägre kvot som betyder att Linux kommer att skriva smutsiga sidor i bakgrunden.

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

För dessa två parametrar finns det inga 'bra' värden, eftersom båda beror på hårdvaran. Men att ställa in vm.dirty_background_ratio på 5 och vm.dirty_background_bytes på 25 % av diskens hastighet ökar prestandan med ~ 25 % i de flesta fall.

vm.dirty_ratio / dirty_bytes

Detta är detsamma som vm.dirty_background_ratio / dirty_background_bytes, med den skillnaden att skrivningen görs i en aktiv session, och blockerar applikationen. Därför bör vm.dirty_ratio vara högre än vm.dirty_background_ratio. Detta säkerställer att bakgrundsprocesserna startas tidigare för att undvika maximal blockering av applikationen. Du kan justera skillnaden mellan dessa två kvoter beroende på belastningen på disk I/O.

Resultat

Du kan justera andra parametrar för att öka prestandan, men förbättringarna kommer att vara minimala och du kommer inte att få några särskilda fördelar. Vi måste komma ihåg att inte alla parametrar gäller för alla typer av applikationer. Vissa applikationer fungerar bättre när vi justerar vissa parametrar, medan andra inte gör det. Du måste hitta rätt balans mellan konfigurationerna av dessa parametrar för den förväntade arbetsbelastningen och typ av applikation, samt ta hänsyn till operativsystemets beteende vid justering. Att justera kärnparametrar är inte så enkelt som att justera databasparametrar: här är det svårare att ge rekommendationer.

Källa: habr.com