Vertikalt skalande PostgreSQL

PostgreSQL kan skala ganska bra vertikalt. Ju fler resurser (CPU, minne, disk) du kan göra tillgängliga för din PostgreSQL-server, desto bättre kan den prestera. Men även om vissa delar av Postgres automatiskt kan använda de utökade resurserna, behöver andra delar konfigurationsändringar innan förbättringar kan märkas.

Läs vidare för att lära dig mer om hur du säkerställer att PostgreSQL drar full nytta av systemet du kör det på.

CPU

Vad skalas automatiskt

PostgreSQL har en traditionell processarkitektur som består av en masterprocess (kallad postmaster ) som skapar en ny process (kallad enbackend ) för varje ny klientanslutning. Detta innebär att om det finns fler CPU-kärnor tillgängliga kan fler processer köras samtidigt, och därför behöver backends inte kämpa lika mycket för CPU-tillgänglighet. CPU-bundna frågor kommer att slutföras snabbare.

Du kanske vill justera de maximalt tillåtna samtidiga anslutningarna på systemomfattande, per databas eller per användare nivå:

-- system level
ALTER SYSTEM SET max_connections = 200;

-- database level
ALTER DATABASE dbname CONNECTION LIMIT 200;

-- user level
ALTER ROLE username CONNECTION LIMIT 20;

så att oseriösa appar inte kan få för många anslutningar.

Vad behöver justeras

PostgreSQL-servern kan skapa processer för att ta hand om hushållsuppgifter, som dammsugning, replikering, prenumerationer (för logisk replikering) etc. Antalet sådana arbetare bestäms inte dynamiskt, utan ställs bara in via konfiguration och är standard till 8.

Konfigurationsinställningen på översta nivån för antalet arbetsprocesser är:

# typically specified in postgresql.conf
max_worker_processes = 16

Att öka detta värde kan resultera i snabbare underhållsjobb, parallellsökningar och skapande av index.

Parallella frågor

Från och med version 9.6 kan Postgres utföra frågor parallellt om frågeplaneraren bestämmer sig för att det kommer att hjälpa. Parallell förfrågning innebär att arbetare skapas, fördela arbete mellan dem och sedan samla in (samla) resultaten. Med förbehåll för den totala gränsen för max_worker_processes ställts in tidigare kommer Postgres att avgöra hur många arbetare som kan skapas för parallella frågor beroende på värdet av två konfigurationsinställningar:

# the maximum number of workers that the system can
# support for parallel operations
max_parallel_workers = 8

# the maximum number of workers that can be started
# by a single Gather or Gather Merge node
max_parallel_workers_per_gather = 8

Om du har inaktiva processorer och parallelliserbara frågor kan ökning av dessa värden påskynda sådana frågor.

Skapa parallellt index

I Postgres 11 lades stöd för parallellt skapande av B-Tree-index till. Om du regelbundet skapar B-Tree-index eller REINDEXERA dem, kan öka detta värde hjälpa:

# the maximum number of parallel workers that can be
# started by a single utility command
max_parallel_maintenance_workers = 8

Detta kommer att tillåta Postgres att skapa dessa många arbetare (med förbehåll för den totala gränsen för max_worker_processes ) för att påskynda skapandet av B-Tree-index.

Logisk replikering

Logisk replikering (tillgänglig i Postgres 10 och högre), förlitar sig på arbetsprocesser på prenumerationssidan för att hämta ändringar från utgivaren. Genom att be Postgres att skapa fler logiska replikeringsarbetare kan ändringarna hämtas och tillämpas parallellt, speciellt om det finns fler tabeller. Denna konfigurationsinställning ökar det totala antalet replikeringsarbetare:

# maximum number of logical replication workers
max_logical_replication_workers = 8

I strömmande replikering kan du starta en synkronisering med en basbackup. För logisk replikering måste dock ändringar dras in via själva replikeringsprotokollet, över nätverket. Detta kan vara tidskrävande. Att tillåta fler arbetare under synkroniseringsfasen kan påskynda denna process:

# basically the number of tables that are synced in
# parallel during initialization of subscription
max_sync_workers_per_subscription = 8

Autovacuum

Med jämna mellanrum, baserat på en massa konfigurationsinställningar, kommer Postgres att skapa en mängd arbetare som dammsuger databastabellerna. Detta kallas naturligtvis autovakuum, och antalet arbetare som autovakuumstartaren skapar varje gång kan ställas in via konfigurationsinställningen:

# the maximum number of autovacuum processes
autovacuum_max_workers = 8

WAL-komprimering

Om du har CPU till övers kan du byta ut CPU mot diskbandbredd genom att komprimera sidorna som skrivs in i WAL-filerna. Detta minskar mängden data som behöver skrivas till disken, på bekostnad av fler CPU-cykler för att komprimera data. Det minskar också storleken på data som måste skickas över tråden för strömmande replikering.

Praktiskt taget är fördelarna med WAL-komprimering väl värda den mycket rimliga omkostnaden. För att aktivera det, använd:

# compresses full page images written to WAL
wal_compression = on

Minne

Vad skalas automatiskt

Operativsystemet hanterar och använder automatiskt minne som inte används av något program för att cachelagra data som läses från och skrevs till disken nyligen. Detta påskyndar kraftigt diskintensiva applikationer, och definitivt PostgreSQL.

I Linux, den mest populära värden för Postgres, kan storleken på OS-diskcachen inte ställas in av användaren. Dess hantering är intern i Linux. Under minnestryck kommer det att ge diskcacheminne till applikationer.

Vad behöver justeras

Frågeplanerare

Frågeplaneraren måste inkludera mängden diskcache som tillhandahålls av operativsystemet som en faktor i dess uppskattningar. Om du har lyckats öka OS-diskcachen avsevärt (genom att öka det tillgängliga minnet), kan en ökning av den här konfigurationsinställningen hjälpa till att förbättra planerarens uppskattningar:

# the planner's assumption about the effective size
# of the disk cache that is available to a single query.
effective_cache_size = 64GB

Delat minne

PostgreSQL använder en uppsättning buffertar som delas mellan alla arbetare och backendprocesser. Dessa kallas delade buffertar , och mängden minne som allokeras för delade buffertar ställs in med hjälp av konfigurationsinställningen:

shared_buffers = 32GB

Tillfälliga buffertar

När tillfälliga tabeller nås av en fråga allokeras buffertar till cacheinnehållet som läses in. Storleken på denna buffert ställs in med hjälp av konfigurationsinställningen:

# the maximum number of temporary buffers used
# by each database session
temp_buffers = 100MB

Om du har minne över och frågor som använder temporära tabeller mycket kan en ökning av detta värde påskynda sådana frågor.

Arbetsminne

Arbetsminne allokeras lokalt och privat av backends. Den används för att utföra sorteringar och sammanfogningar utan att behöva skapa till tillfälliga tabeller. Om du ökar detta från standardvärdet på 4 MB kan frågor slutföras snabbare genom att tillfälligt skapa tabeller:

# the amount of memory to be used by internal sort
# operations and hash tables before writing to temporary disk files
work_mem = 16MB

Underhållsåtgärder

Minnet som används av VACUUM, indexskapande och andra sådana underhållskommandon kontrolleras av konfigurationsinställningen maintenance_work_mem . Att öka detta belopp kan påskynda dessa operationer, särskilt på index eller tabeller som behöver återskapas.

Minnet som används av autovacuum-arbetarna kan hämtas från underhållsarbetsminnet (genom att ställa in autovacuum_work_mem = -1 ) eller konfigureras oberoende.

# the maximum amount of memory to be used by
# maintenance operations
maintenance_work_mem = 128MB

# maximum amount of memory to be used by each
# autovacuum worker process
autovacuum_work_mem = -1

Disk

Vad skalas automatiskt

Diskar kan göras större, snabbare eller mer samtidigt. Storleken på disken är det enda som PostgreSQL inte behöver instrueras om. Som standard kommer PostgreSQL inte att begränsa sig själv från att använda tillgängligt diskutrymme. Detta är vanligtvis bra.

Du kan dock sätta en gräns för den totala storleken på temporära filer som skapas, för att ge ett visst skydd mot frågor som försöker sortera en miljardrader och liknande:

# the maximum amount of disk space that a process
# can use for temporary files
temp_file_limit = 500GB

Vad behöver justeras

Samtidighet

RAID-redigerade diskar och filsystem som ZFS kan ställas in för att stödja mer samtidighet. Det vill säga, du kan ha några diskläsningar/skrivningar som hanteras samtidigt av sådana filsystem på grund av hur data lagras eller hanteras internt.

Du kan låta Postgres utfärda flera samtidiga disk I/O genom att använda denna konfigurationsinställning:

# the number of concurrent disk I/O operations that
# PostgreSQL expects can be executed simultaneously
effective_io_concurrency = 4

Detta används för närvarande endast av bitmappshögavsökningar.

Slumpmässig sidkostnad

Postgres frågeplanerare antar att sekventiell läsning är snabbare än slumpmässig läsning. Exakt hur mycket snabbare är ett värde du kan justera. Som standard antar det att slumpmässiga läsningar är fyra gånger dyrare.

Beroende på din diskinstallation, arbetsbelastning och benchmarking, om du är säker på att slumpmässiga läsningar är dubbelt så kostsamma som sekventiella läsningar, kan du berätta det för Postgres:

# the planner's estimate of the cost of a disk page
# fetch that is part of a series of sequential fetches
seq_page_cost = 1

# the planner's estimate of the cost of a
# non-sequentially-fetched disk page
random_page_cost = 2

Tabellytor

För att dra nytta av flera diskar som inte är monterade som ett stort enda filsystem kan du använda tabellutrymmen. Med tabellutrymmen kan du placera tabeller eller indexera olika filsystem. Detta kan förbättra samtidighet och ger ett enkelt sätt att hantera tabelltillväxt.

CREATE TABLESPACE disk2 LOCATION '/mnt/disk2/postgres';

Läs mer om tabellplatser här.

Nätverk

Nätverk är vanligtvis den minst använda resursen på en PostgreSQL-server och är sällan mättad. Om du behöver skala är det enkelt att lägga till fler nätverksgränssnitt vart och ett med sin egen IP och låta PostreSQL lyssna på dem alla:

listen_addresses = '10.1.0.10,10.1.0.11'

Klienterna måste vara lastbalanserade över alla IP:er som Postgreslyssnar på.

Övrigt

Det finns några andra konfigurationsinställningar som kan justeras, varav de flesta använder mer CPU och minne.

Partitionsvisa operationer

Postgres 10 introducerade tabellpartitionering, som förbättrades i Postgres 11. Vissa frågeoptimeringar på partitioner är inte aktiverade som standard, eftersom de kan resultera i högre CPU- och minnesförbrukning. Dessa är:

# allow a join between partitioned tables to be
# performed by joining the matching partitions
enable_partitionwise_join = on

# allow grouping or aggregation on a partitioned
# tables performed separately for each partition
enable_partitionwise_aggregate = on