PostgreSQL pe un VPS: cum dimensionați memoria și discul

Porniți de la volumul util

Memoria unui server de baze de date servește în primul rând drept cache: o pagină citită din memorie este servită mult mai repede decât una citită de pe disc, chiar și NVMe. Întrebarea nu este deci doar „cât cântărește baza?”, ci „ce parte din ea este citită des?”. O bază de 50 GB din care sunt consultate doar ultimele douăsprezece luni lucrează poate pe 8 GB.

Pe o bază existentă, două interogări dau volumul total și cele mai mari tabele, inclusiv indecșii:

SELECT pg_size_pretty(pg_database_size(current_database()));

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

Pentru o bază care urmează să fie creată, estimați tabel cu tabel: numărul de rânduri așteptate la un an × dimensiunea medie a unui rând, apoi adăugați indecșii, care cântăresc frecvent între 30 și 100% din date. Exemplu: 2 milioane de rânduri pe lună, de 500 de octeți fiecare, fac 12 GB de date la un an și între 18 și 24 GB cu indecșii.

Memoria: setările de pornire

PostgreSQL păstrează paginile citite pe două niveluri: propriul cache (shared_buffers) și cache-ul de fișiere al sistemului. Documentația sa recomandă să porniți de la 25% din memorie pentru shared_buffers pe un server dedicat și observă că peste 40% câștigul devine rar: restul rămâne în folosul cache-ului sistemului și al sortărilor.

Aceste valori presupun o bază singură pe server. Dacă aplicația rulează alături, scădeți mai întâi memoria ei (procese, cache, compilare) și aplicați procentele la rest: un server de 8 GB care rulează o aplicație de 3 GB se reglează ca o bază de 5 GB.

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

shared_buffers intră în vigoare doar la repornirea PostgreSQL; ceilalți parametri se reîncarcă fără întrerupere, cu SELECT pg_reload_conf();.

Pentru a ști dacă memoria ajunge, citiți rata de citire din cache. Pe o aplicație de gestiune sau pe un site, ea depășește 99%:

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

Conexiunile: câte un proces fiecare

PostgreSQL deschide un proces pentru fiecare conexiune și acceptă implicit 100 (max_connections). Fiecare proces ocupă câțiva megaocteți în repaus, mai mult când sortează sau aplică hash pe date (work_mem, uneori de mai multe ori în aceeași interogare). A ridica max_connections la 500 pentru a ține pasul cu o aplicație care deschide multe conexiuni înseamnă a expune serverul lipsei de memorie la primul vârf.

Răspunsul potrivit este un pooler de conexiuni: PgBouncer, în modul transaction, face ca sute de conexiuni ale aplicației să împartă câteva zeci de conexiuni reale. Framework-urile au și ele propriul pool (SQLAlchemy, Prisma, HikariCP): reglați-i dimensiunea după numărul de vCPU al serverului de baze de date, nu după numărul de utilizatori.

Discul: volum, marjă și jurnal

Discul unui server PostgreSQL conține mai mult decât tabelele:

• Datele și indecșii, cu creșterea lor pe un an.
• Jurnalul de tranzacții (WAL): 1 GB implicit între două puncte de control (max_wal_size), mai mult în timpul unui import masiv și și mai mult dacă arhivarea jurnalului rămâne în urmă.
• Fișierele temporare ale sortărilor care depășesc work_mem.
• Spațiul pentru o reorganizare: VACUUM FULL și reconstruirea unui index scriu o copie completă înainte de a o elibera pe cea veche.
• Exporturile locale, dacă păstrați backupuri pe server înainte de a le trimite în altă parte.

Regula: volumul la un an, plus o marjă de cel puțin 30%. Nu este un lux: când discul care găzduiește jurnalul de tranzacții se umple, PostgreSQL se oprește pentru a-și proteja datele. Urmăriți gradul de ocupare și măriți discul înainte de 80%.

Din punctul de vedere al performanței, fiecare validare de tranzacție așteaptă scrierea jurnalului pe disc: latența stocării stabilește debitul de scriere. Aici face diferența un SSD NVMe, mult mai mult decât la citiri, pe care memoria le servește deja.

Procesorul: o interogare, un nucleu

O interogare PostgreSQL rulează pe un singur nucleu, cu excepția citirilor mari pe care motorul le paralelizează. Numărul de vCPU stabilește deci câte interogări grele sunt procesate în același timp: 2 vCPU ajung unei aplicații de gestiune la lansare, între 4 și 8 se potrivesc bazelor foarte solicitate și rapoartelor grele.

Înainte de a adăuga vCPU, căutați interogările care le consumă. Extensia pg_stat_statements le ordonează după timpul total:

shared_preload_libraries = 'pg_stat_statements'

CREATE EXTENSION IF NOT EXISTS pg_stat_statements;

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

Același server cu aplicația sau un server separat?

La lansare, baza de date pe același server cu aplicația este alegerea potrivită: nicio latență de rețea între cele două, o conexiune prin socket Unix, un singur server de salvat și de monitorizat. Le separați când își dispută resursele: o compilare sau un vârf de trafic care golește cache-ul bazei, o bază care are nevoie de toată memoria pentru datele ei sau cerințe de backup diferite.

Securitate și backupuri

• Ascultare locală: listen_addresses = 'localhost' cât timp doar aplicația de pe server se conectează. Dacă un alt server trebuie să o acceseze, deschideți portul 5432 doar pentru adresa lui, în firewall și în pg_hba.conf.
• Autentificare: metoda scram-sha-256 în pg_hba.conf, un rol pentru fiecare aplicație, fără drepturi de superutilizator.
• Backup logic zilnic cu pg_dump, copiat în afara serverului.
• Restaurare la un moment precis: arhivarea continuă a jurnalului (pgBackRest, WAL-G) permite revenirea la minutul dinaintea unei erori, acolo unde un export zilnic vă duce înapoi la ziua precedentă.
• Restaurare testată: un backup se dovedește restaurându-l, pe o bază de test, la intervale regulate.

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