PostgreSQL na VPS-u: kako dimenzionirati memoriju i disk

Polazite od korisnog volumena

Memorija poslužitelja baze podataka prije svega služi kao predmemorija: stranica pročitana iz memorije poslužuje se mnogo brže od stranice pročitane s diska, čak i NVMe. Pitanje zato nije samo „koliko je baza velika?”, nego „koji se njezin dio često čita?”. Baza od 50 GB u kojoj se pretražuje samo posljednjih dvanaest mjeseci možda radi na 8 GB.

Na postojećoj bazi dva upita daju ukupnu veličinu i najveće tablice, uključujući indekse:

SELECT pg_size_pretty(pg_database_size(current_database()));

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

Za bazu koja tek dolazi procijenite tablicu po tablicu: broj redaka očekivan za godinu dana × prosječna veličina retka, a zatim dodajte indekse, koji obično teže 30 do 100 % podataka. Primjer: 2 milijuna redaka mjesečno, svaki od 500 bajtova, čini 12 GB podataka za godinu dana, a 18 do 24 GB s indeksima.

Memorija: početne postavke

PostgreSQL pročitane stranice drži na dvije razine: u vlastitoj predmemoriji (shared_buffers) i u predmemoriji datoteka operativnog sustava. Njegova dokumentacija preporučuje da se na poslužitelju namijenjenom bazi za shared_buffers krene od 25 % memorije i napominje da je iznad 40 % dobitak rijedak: ostatak koristi predmemoriji sustava i sortiranjima.

Ove vrijednosti pretpostavljaju da je baza sama na poslužitelju. Ako uz nju radi i aplikacija, najprije oduzmite njezinu memoriju (procesi, predmemorija, kompilacija) i postotke primijenite na ostatak: poslužitelj od 8 GB na kojem radi aplikacija od 3 GB podešava se kao baza od 5 GB.

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

shared_buffers počinje djelovati tek nakon ponovnog pokretanja PostgreSQL-a; ostali se parametri učitavaju bez prekida, naredbom SELECT pg_reload_conf();.

Da biste znali je li memorija dovoljna, pogledajte udio čitanja iz predmemorije. Kod poslovne aplikacije ili web stranice on prelazi 99 %:

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

Veze: svaka je jedan proces

PostgreSQL otvara jedan proces po vezi i prema zadanim postavkama prihvaća njih 100 (max_connections). Svaki proces u mirovanju zauzima nekoliko megabajta, a više kada sortira ili hashira podatke (work_mem, ponekad više puta unutar istog upita). Povećati max_connections na 500 kako bi se pratila „brbljava” aplikacija znači izložiti poslužitelj nedostatku memorije već pri prvom vrhu opterećenja.

Pravi je odgovor alat za grupiranje veza (connection pooler): PgBouncer, u načinu rada transaction, omogućuje da stotine veza aplikacije dijele nekoliko desetaka stvarnih veza. Razvojni okviri imaju i vlastiti pool (SQLAlchemy, Prisma, HikariCP): njegovu veličinu podesite prema broju vCPU-a poslužitelja baze, a ne prema broju korisnika.

Disk: volumen, rezerva i dnevnik transakcija

Disk PostgreSQL poslužitelja nosi više od samih tablica:

• Podaci i indeksi, i njihov rast tijekom godine dana.
• Dnevnik transakcija (WAL): 1 GB prema zadanim postavkama između dviju kontrolnih točaka (max_wal_size), više tijekom masovnog uvoza, a još više ako arhiviranje dnevnika kasni.
• Privremene datoteke sortiranja koja premašuju work_mem.
• Prostor za reorganizaciju: VACUUM FULL i ponovna izrada indeksa zapisuju potpunu kopiju prije nego što oslobode staru.
• Lokalni izvozi, ako sigurnosne kopije čuvate na poslužitelju prije nego što ih pošaljete drugamo.

Pravilo: volumen za godinu dana, plus najmanje 30 % rezerve. To nije stvar udobnosti: kada se disk na kojem je dnevnik transakcija napuni, PostgreSQL se zaustavlja kako bi zaštitio svoje podatke. Pratite zauzeće i proširite disk prije 80 %.

Što se performansi tiče, svaka potvrda transakcije čeka zapis dnevnika na disk: latencija pohrane određuje propusnost pisanja. Tu NVMe SSD čini razliku, mnogo više nego kod čitanja, koja već poslužuje memorija.

Procesor: jedan upit, jedna jezgra

PostgreSQL upit izvršava se na jednoj jezgri, osim velikih čitanja koja pogon paralelizira. Broj vCPU-a stoga određuje koliko se zahtjevnih upita obrađuje u isto vrijeme: 2 vCPU-a dovoljna su poslovnoj aplikaciji pri pokretanju, a 4 do 8 odgovaraju vrlo opterećenim bazama i zahtjevnim izvješćima.

Prije dodavanja vCPU-a pronađite upite koji ih troše. Proširenje pg_stat_statements razvrstava ih prema ukupnom vremenu:

shared_preload_libraries = 'pg_stat_statements'

CREATE EXTENSION IF NOT EXISTS pg_stat_statements;

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

Isti poslužitelj kao aplikacija ili zaseban poslužitelj?

Pri pokretanju baza na istom poslužitelju kao aplikacija pravi je izbor: između njih nema mrežne latencije, veza ide preko Unix socketa, a sigurnosno kopiranje i nadzor odnose se na jedan poslužitelj. Razdvajaju se kada se natječu za resurse: kompilacija ili vrh prometa koji isprazni predmemoriju baze, baza kojoj je za podatke potrebna sva memorija ili različiti zahtjevi za sigurnosne kopije.

Sigurnost i sigurnosne kopije

• Lokalno slušanje: listen_addresses = 'localhost' sve dok se spaja samo aplikacija s poslužitelja. Ako joj mora pristupati drugi poslužitelj, otvorite port 5432 samo za njegovu adresu, u vatrozidu i u pg_hba.conf.
• Autentifikacija: metoda scram-sha-256 u pg_hba.conf, jedna uloga po aplikaciji, bez prava superkorisnika.
• Logička sigurnosna kopija svaki dan naredbom pg_dump, kopirana izvan poslužitelja.
• Vraćanje na točan trenutak: kontinuirano arhiviranje dnevnika (pgBackRest, WAL-G) omogućuje povratak na minutu prije pogreške, dok dnevni izvoz vraća na prethodni dan.
• Testirano vraćanje: sigurnosna kopija dokazuje se vraćanjem, u testnu bazu, u redovitim razmacima.

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