PostgreSQL na VPS: ako dimenzovať pamäť a disk

Vychádzať z užitočného objemu

Pamäť databázového servera slúži predovšetkým ako cache: stránka prečítaná z pamäte sa obslúži oveľa rýchlejšie než stránka prečítaná z disku, aj z NVMe. Otázka teda neznie len „koľko váži databáza?“, ale aj „aká jej časť sa číta často?“. Databáza s veľkosťou 50 GB, v ktorej sa čítajú len údaje za posledných dvanásť mesiacov, môže pracovať s 8 GB.

Na existujúcej databáze dajú dva dopyty celkový objem a najväčšie tabuľky vrátane indexov:

SELECT pg_size_pretty(pg_database_size(current_database()));

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

Pri budúcej databáze odhadujte tabuľku po tabuľke: počet riadkov očakávaný o rok × priemerná veľkosť riadku, a potom pridajte indexy, ktoré bežne vážia 30 až 100 % údajov. Príklad: 2 milióny riadkov mesačne, každý s veľkosťou 500 bajtov, dajú o rok 12 GB údajov a s indexmi 18 až 24 GB.

Pamäť: východiskové nastavenia

PostgreSQL drží prečítané stránky na dvoch úrovniach: vo vlastnej cache (shared_buffers) a v cache súborov systému. Jeho dokumentácia odporúča začať s 25 % pamäte pre shared_buffers na vyhradenom serveri a konštatuje, že nad 40 % je prínos zriedkavý: zvyšok prospieva cache systému a triedeniu.

Tieto hodnoty predpokladajú, že databáza je na serveri sama. Ak vedľa nej beží aplikácia, najprv odpočítajte jej pamäť (procesy, cache, kompilácia) a percentá použite na zvyšok: server s 8 GB, na ktorom beží aplikácia s 3 GB, sa nastavuje ako databáza s 5 GB.

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

shared_buffers sa prejaví až po reštarte PostgreSQL; ostatné parametre sa načítajú bez prerušenia, príkazom SELECT pg_reload_conf();.

Či pamäť stačí, zistíte z podielu čítaní z cache. Pri podnikovej aplikácii alebo webe presahuje 99 %:

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

Pripojenia: každé je proces

PostgreSQL otvára jeden proces na pripojenie a predvolene ich prijme 100 (max_connections). Každý proces zaberá v nečinnosti niekoľko megabajtov, viac, keď triedi alebo hašuje údaje (work_mem, niekedy viackrát v jednom dopyte). Zvýšiť max_connections na 500, aby ste stačili aplikácii, ktorá otvára veľa pripojení, znamená vystaviť server riziku, že mu pri prvej špičke dôjde pamäť.

Správnou odpoveďou je pooler pripojení: PgBouncer v režime transaction nechá stovky pripojení aplikácie zdieľať niekoľko desiatok skutočných pripojení. Frameworky majú aj vlastný pool (SQLAlchemy, Prisma, HikariCP): jeho veľkosť nastavte podľa počtu vCPU databázového servera, nie podľa počtu používateľov.

Disk: objem, rezerva a transakčný log

Disk servera PostgreSQL nesie viac než len tabuľky:

• Údaje a indexy a ich rast počas jedného roka.
• Transakčný log (WAL): predvolene 1 GB medzi dvoma kontrolnými bodmi (max_wal_size), viac počas hromadného importu a ešte viac, ak archivácia logu mešká.
• Dočasné súbory triedení, ktoré prekročia work_mem.
• Miesto na reorganizáciu: VACUUM FULL a prestavba indexu zapíšu úplnú kópiu skôr, než uvoľnia pôvodnú.
• Lokálne exporty, ak si zálohy ponechávate na serveri pred ich odoslaním inam.

Pravidlo: objem o rok, plus aspoň 30 % rezerva. Nejde o pohodlie: keď sa disk s transakčným logom zaplní, PostgreSQL sa zastaví, aby ochránil svoje údaje. Sledujte obsadenosť a disk zväčšite skôr, než dosiahne 80 %.

Z hľadiska výkonu čaká každé potvrdenie transakcie na zápis logu na disk: latencia úložiska určuje priepustnosť zápisu. Práve tu robí SSD NVMe rozdiel, oveľa viac než pri čítaní, ktoré už obsluhuje pamäť.

Procesor: jeden dopyt, jedno jadro

Dopyt v PostgreSQL beží na jedinom jadre, okrem veľkých čítaní, ktoré databázový stroj paralelizuje. Počet vCPU preto určuje, koľko náročných dopytov sa spracúva súčasne: pri spustení podnikovej aplikácie stačia 2 vCPU, 4 až 8 vyhovuje veľmi vyťaženým databázam a náročným reportom.

Skôr než pridáte vCPU, nájdite dopyty, ktoré ich spotrebúvajú. Rozšírenie pg_stat_statements ich zoradí podľa celkového času:

shared_preload_libraries = 'pg_stat_statements'

CREATE EXTENSION IF NOT EXISTS pg_stat_statements;

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

Na rovnakom serveri ako aplikácia, alebo na samostatnom?

Pri spustení je databáza na tom istom serveri ako aplikácia správnou voľbou: žiadna sieťová latencia medzi nimi, pripojenie cez unixový socket, jediný server na zálohovanie a sledovanie. Oddeľujú sa, keď si konkurujú o prostriedky: kompilácia alebo návštevnostná špička, ktorá vyprázdni cache databázy, databáza, ktorá potrebuje celú pamäť pre svoje údaje, alebo rozdielne požiadavky na zálohovanie.

Bezpečnosť a zálohy

• Lokálne počúvanie: listen_addresses = 'localhost', kým sa pripája len aplikácia na tom istom serveri. Ak k databáze musí pristupovať iný server, otvorte port 5432 len pre jeho adresu, vo firewalle aj v pg_hba.conf.
• Autentifikácia: metóda scram-sha-256 v pg_hba.conf, jedna rola na aplikáciu, bez práv superpoužívateľa.
• Logická záloha každý deň pomocou pg_dump, skopírovaná mimo servera.
• Obnova k presnému okamihu: priebežná archivácia logu (pgBackRest, WAL-G) umožňuje vrátiť sa na minútu presne pred chybu, zatiaľ čo denný export vás vráti k predchádzajúcemu dňu.
• Otestovaná obnova: záloha sa dokazuje obnovou do testovacej databázy, v pravidelných intervaloch.

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