PostgreSQL på en VPS: dimensionera minne och disk

Utgå från den aktiva datamängden

Minnet i en databasserver fungerar först och främst som cache: en sida som läses från minnet levereras mycket snabbare än en sida som läses från disk, även NVMe. Frågan är alltså inte bara ”hur stor är databasen?”, utan ”hur stor del läses ofta?”. En databas på 50 GB där bara de senaste tolv månaderna efterfrågas arbetar kanske med 8 GB.

På en befintlig databas ger två frågor den totala storleken och de största tabellerna, index inräknade:

SELECT pg_size_pretty(pg_database_size(current_database()));

SELECT relname AS namn,
       pg_size_pretty(pg_total_relation_size(relid)) AS storlek_med_index
FROM pg_catalog.pg_statio_user_tables
ORDER BY pg_total_relation_size(relid) DESC
LIMIT 10;

För en databas som ännu inte finns uppskattar du tabell för tabell: antalet rader som väntas om ett år × en rads genomsnittliga storlek, och lägger sedan till indexen, som ofta väger 30 till 100 % av datan. Exempel: 2 miljoner rader per månad, på 500 byte vardera, blir 12 GB data om ett år, och 18 till 24 GB med indexen.

Minnet: startinställningarna

PostgreSQL håller lästa sidor på två nivåer: sin egen cache (shared_buffers) och systemets filcache. Dokumentationen rekommenderar att utgå från 25 % av minnet för shared_buffers på en dedikerad server, och konstaterar att vinsten sällan blir större över 40 %: resten kommer systemets cache och sorteringarna till godo.

Värdena förutsätter att databasen är ensam på servern. Om applikationen körs bredvid drar du först av dess minne (processer, cache, kompilering) och tillämpar procentsatserna på resten: en server på 8 GB som kör en applikation på 3 GB ställs in som en databas på 5 GB.

shared_buffers = 2GB
effective_cache_size = 6GB
work_mem = 16MB
maintenance_work_mem = 512MB
random_page_cost = 1.1

shared_buffers träder i kraft först när PostgreSQL startas om; de andra parametrarna laddas om utan avbrott, med SELECT pg_reload_conf();.

För att veta om minnet räcker läser du andelen läsningar från cachen. För en affärsapplikation eller en webbplats ligger den över 99 %:

SELECT round(100.0 * blks_hit / nullif(blks_hit + blks_read, 0), 2) AS cacheandel
FROM pg_stat_database
WHERE datname = current_database();

Anslutningarna: en process var

PostgreSQL öppnar en process per anslutning och accepterar 100 som standard (max_connections). Varje process tar några megabyte i vila, mer när den sorterar eller hashar data (work_mem, ibland flera gånger i samma fråga). Att höja max_connections till 500 för att hänga med en pratsam applikation utsätter servern för minnesbrist vid första topp.

Det rätta svaret är en anslutningspoolare: PgBouncer, i läget transaction, låter hundratals anslutningar från applikationen dela på några tiotal verkliga anslutningar. Ramverken har också sin egen pool (SQLAlchemy, Prisma, HikariCP): ställ in dess storlek efter antalet vCPU på databasservern snarare än efter antalet användare.

Disken: volym, marginal och transaktionslogg

Disken i en PostgreSQL-server rymmer mer än tabellerna:

• Data och index, och deras tillväxt under ett år.
• Transaktionsloggen (WAL): 1 GB som standard mellan två kontrollpunkter (max_wal_size), mer under en massimport, och ännu mer om arkiveringen av loggen släpar efter.
• De temporära filerna från sorteringar som överskrider work_mem.
• Utrymmet för en omorganisation: VACUUM FULL och ombyggnaden av ett index skriver en fullständig kopia innan den gamla frigörs.
• Lokala exporter, om du behåller säkerhetskopior på servern innan de skickas vidare.

Regeln: volymen om ett år, plus minst 30 % marginal. Det är ingen lyx: när disken som rymmer transaktionsloggen blir full stänger PostgreSQL av sig själv för att skydda sina data. Följ beläggningen och utöka före 80 %.

När det gäller prestanda väntar varje bekräftad transaktion på att loggen skrivs till disk: lagringens latens bestämmer skrivhastigheten. Det är där en NVMe-SSD gör skillnad, mycket mer än vid läsningar, som minnet redan hanterar.

Processorn: en fråga, en kärna

En PostgreSQL-fråga körs på en enda kärna, utom de stora läsningar som motorn parallelliserar. Antalet vCPU bestämmer alltså hur många tunga frågor som hanteras samtidigt: 2 vCPU räcker för en affärsapplikation vid lanseringen, 4 till 8 passar databaser med hög belastning och tunga rapporter.

Innan du lägger till vCPU letar du upp de frågor som förbrukar dem. Tillägget pg_stat_statements sorterar dem efter total tid:

shared_preload_libraries = 'pg_stat_statements'

CREATE EXTENSION IF NOT EXISTS pg_stat_statements;

SELECT calls, round(total_exec_time) AS ms_totalt,
       round(mean_exec_time::numeric, 1) AS ms_snitt, query
FROM pg_stat_statements
ORDER BY total_exec_time DESC
LIMIT 10;

Samma server som applikationen, eller en separat server?

Vid lanseringen är databasen på samma server som applikationen rätt val: ingen nätverkslatens mellan dem, anslutning via Unix-socket, en enda server att säkerhetskopiera och övervaka. Man delar upp dem när de konkurrerar om resurserna: en kompilering eller en trafiktopp som tömmer databasens cache, en databas som behöver hela minnet för sina data, eller olika krav på säkerhetskopiering.

Säkerhet och säkerhetskopior

• Lokal lyssning: listen_addresses = 'localhost' så länge bara applikationen på servern ansluter. Om en annan server behöver åtkomst öppnar du port 5432 enbart för dess adress, i brandväggen och i pg_hba.conf.
• Autentisering: metoden scram-sha-256 i pg_hba.conf, en roll per applikation, utan superanvändarrättigheter.
• Logisk säkerhetskopia varje dag med pg_dump, kopierad utanför servern.
• Återställning till en exakt tidpunkt: kontinuerlig arkivering av loggen (pgBackRest, WAL-G) gör det möjligt att gå tillbaka till minuten före ett misstag, medan en daglig export tar dig tillbaka till dagen innan.
• Testad återställning: en säkerhetskopia bevisas genom att återställa den, i en testdatabas, med jämna mellanrum.

pg_dump -Fc -d min_databas -f min_databas-$(date +%F).dump
createdb min_databas_test
pg_restore -d min_databas_test min_databas-2026-10-29.dump