PostgreSQL na VPS: jak dimenzovat paměť a disk

Vycházet z objemu, se kterým se pracuje

Paměť databázového serveru slouží především jako cache: stránka přečtená z paměti se obslouží mnohem rychleji než stránka přečtená z disku, i z NVMe. Otázka tedy nezní jen „kolik databáze váží?“, ale „jaká její část se čte často?“. Databáze o 50 GB, ve které se používá jen posledních dvanáct měsíců, možná pracuje s 8 GB.

Na stávající databázi ukážou dva dotazy celkový objem a největší tabulky, včetně indexů:

SELECT pg_size_pretty(pg_database_size(current_database()));

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

U budoucí databáze odhadněte objem tabulku po tabulce: očekávaný počet řádků za rok × průměrná velikost řádku, a pak přidejte indexy, které běžně váží 30 až 100 % dat. Příklad: 2 miliony řádků měsíčně po 500 bajtech dávají za rok 12 GB dat a s indexy 18 až 24 GB.

Paměť: výchozí nastavení

PostgreSQL uchovává přečtené stránky na dvou úrovních: ve vlastní cache (shared_buffers) a v souborové cache systému. Jeho dokumentace doporučuje na vyhrazeném serveru začít s 25 % paměti pro shared_buffers a uvádí, že nad 40 % bývá přínos vzácný: zbytek prospívá cache systému a řazení.

Tyto hodnoty předpokládají databázi, která na serveru běží sama. Pokud vedle ní běží aplikace, nejdřív odečtěte její paměť (procesy, cache, sestavení) a procenta použijte na zbytek: server s 8 GB, na kterém běží aplikace o 3 GB, se nastavuje jako databáze s 5 GB.

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

shared_buffers se projeví až po restartu PostgreSQL; ostatní parametry se načtou bez přerušení pomocí SELECT pg_reload_conf();.

Zda paměť stačí, zjistíte z podílu čtení z cache. U firemní aplikace nebo webu přesahuje 99 %:

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

Připojení: každé je proces

PostgreSQL otevírá jeden proces na každé připojení a ve výchozím nastavení jich přijímá 100 (max_connections). Každý proces zabírá v klidu několik megabajtů, více, když řadí nebo hashuje data (work_mem, někdy i několikrát v jediném dotazu). Zvýšit max_connections na 500 kvůli upovídané aplikaci znamená vystavit server riziku, že mu při první špičce dojde paměť.

Správnou odpovědí je pooler připojení: PgBouncer v režimu transaction nechá stovky připojení aplikace sdílet několik desítek skutečných připojení. Frameworky mají i vlastní pool (SQLAlchemy, Prisma, HikariCP): jeho velikost nastavte podle počtu vCPU databázového serveru, ne podle počtu uživatelů.

Disk: objem, rezerva a transakční log

Disk serveru PostgreSQL nese víc než jen tabulky:

• Data a indexy a jejich růst za rok.
• Transakční log (WAL): ve výchozím nastavení 1 GB mezi dvěma kontrolními body (max_wal_size), více během hromadného importu a ještě více, pokud archivace logu nestíhá.
• Dočasné soubory řazení, která přesáhnou work_mem.
• Místo pro reorganizaci: VACUUM FULL a přestavba indexu zapíší úplnou kopii, než uvolní tu starou.
• Lokální exporty, pokud si zálohy necháváte na serveru, než je odešlete jinam.

Pravidlo: objem za rok plus nejméně 30 % rezervy. Nejde o pohodlí: když se zaplní disk, na kterém leží transakční log, PostgreSQL se zastaví, aby ochránil svá data. Sledujte zaplnění a disk zvětšete dřív, než dosáhne 80 %.

Z hlediska výkonu čeká každé potvrzení transakce na zápis logu na disk: latence úložiště určuje propustnost zápisu. Právě zde SSD NVMe dělá rozdíl, mnohem větší než u čtení, která už obsluhuje paměť.

Procesor: jeden dotaz, jedno jádro

Dotaz PostgreSQL běží na jediném jádře, s výjimkou velkých čtení, která databáze paralelizuje. Počet vCPU proto určuje, kolik náročných dotazů se zpracuje současně: 2 vCPU stačí firemní aplikaci při spuštění, 4 až 8 vyhovují velmi vytíženým databázím a náročným reportům.

Než přidáte vCPU, najděte dotazy, které je spotřebovávají. Rozšíření pg_stat_statements je seřadí podle 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_celkem,
       round(mean_exec_time::numeric, 1) AS ms_prumer, query
FROM pg_stat_statements
ORDER BY total_exec_time DESC
LIMIT 10;

Stejný server jako aplikace, nebo samostatný server?

Při spuštění je databáze na stejném serveru jako aplikace správnou volbou: mezi nimi není žádná síťová latence, připojení vede přes unixový socket a zálohovat a sledovat stačí jediný server. Oddělují se, když si konkurují o prostředky: sestavení nebo špička provozu, která vyprázdní cache databáze, databáze, která potřebuje veškerou paměť pro svá data, nebo odlišné požadavky na zálohování.

Zabezpečení a zálohy

• Lokální naslouchání: listen_addresses = 'localhost', dokud se připojuje jen aplikace na serveru. Pokud k databázi potřebuje přístup jiný server, otevřete port 5432 jen jeho adrese, ve firewallu i v pg_hba.conf.
• Ověřování: metoda scram-sha-256 v pg_hba.conf, jedna role na aplikaci, bez práv superuživatele.
• Logická záloha každý den pomocí pg_dump, zkopírovaná mimo server.
• Obnova k určitému okamžiku: průběžná archivace logu (pgBackRest, WAL-G) umožňuje vrátit se s přesností na minutu do doby před chybou, zatímco denní export vrací ke včerejšku.
• Otestovaná obnova: záloha se prokazuje obnovou, do testovací databáze, v pravidelných intervalech.

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