PostgreSQL VPS serverī: kā dimensionēt atmiņu un disku

Sākt no izmantotā datu apjoma

Datubāzes servera atmiņa vispirms kalpo kā kešatmiņa: no atmiņas nolasītu lapu apkalpo daudz ātrāk nekā no diska, pat NVMe. Tāpēc jautājums nav tikai «cik liela ir datubāze?», bet «kāda daļa tiek lasīta bieži?». 50 GB datubāze, kurā skatās tikai pēdējos divpadsmit mēnešus, varbūt strādā ar 8 GB.

Esošā datubāzē divi vaicājumi parāda kopējo apjomu un lielākās tabulas, ieskaitot indeksus:

SELECT pg_size_pretty(pg_database_size(current_database()));

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

Topošai datubāzei aplēsiet pa tabulām: pēc gada gaidāmais rindu skaits × rindas vidējais izmērs, tad pieskaitiet indeksus, kas parasti sver 30 līdz 100 % no datiem. Piemērs: 2 miljoni rindu mēnesī, katra 500 baitu, pēc gada ir 12 GB datu un ar indeksiem 18 līdz 24 GB.

Atmiņa: sākuma iestatījumi

PostgreSQL nolasītās lapas glabā divos līmeņos: savā kešatmiņā (shared_buffers) un sistēmas failu kešatmiņā. Tā dokumentācija iesaka serverim, kas veltīts datubāzei, sākt ar shared_buffers 25 % apmērā no atmiņas un norāda, ka virs 40 % ieguvums kļūst rets: pārējais nāk par labu sistēmas kešatmiņai un kārtošanai.

Šīs vērtības pieņem, ka datubāze serverī ir viena pati. Ja blakus darbojas lietojumprogramma, vispirms atskaitiet tās atmiņu (procesi, kešatmiņa, kompilēšana) un procentus piemērojiet atlikumam: 8 GB serveri, kurā darbojas 3 GB lietojumprogramma, iestata kā 5 GB datubāzes serveri.

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

shared_buffers stājas spēkā tikai pēc PostgreSQL restartēšanas; pārējos parametrus var pārlādēt bez pārtraukuma ar SELECT pg_reload_conf();.

Lai uzzinātu, vai atmiņas pietiek, skatieties kešatmiņas trāpījumu īpatsvaru. Biznesa lietojumprogrammā vai vietnē tas pārsniedz 99 %:

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

Savienojumi: katram savs process

PostgreSQL atver vienu procesu uz katru savienojumu un pēc noklusējuma pieņem 100 (max_connections). Katrs process dīkstāvē aizņem dažus megabaitus, vairāk, kad kārto vai jauc datus (work_mem, dažkārt vairākas reizes vienā vaicājumā). Palielināt max_connections līdz 500, lai sekotu runīgai lietojumprogrammai, nozīmē pakļaut serveri atmiņas trūkumam jau pirmajā slodzes maksimumā.

Pareizā atbilde ir savienojumu apvienotājs (connection pooler): PgBouncer transaction režīmā ļauj simtiem lietojumprogrammas savienojumu dalīt dažus desmitus reālu savienojumu. Ietvariem ir arī savs pūls (SQLAlchemy, Prisma, HikariCP): iestatiet tā izmēru pēc datubāzes servera vCPU skaita, nevis pēc lietotāju skaita.

Disks: apjoms, rezerve un žurnāls

PostgreSQL servera diskā glabājas vairāk nekā tabulas:

• Dati un indeksi un to pieaugums gada laikā.
• Transakciju žurnāls (WAL): pēc noklusējuma 1 GB starp diviem kontrolpunktiem (max_wal_size), vairāk masveida importa laikā un vēl vairāk, ja žurnāla arhivēšana atpaliek.
• Pagaidu faili kārtošanām, kas pārsniedz work_mem.
• Vieta reorganizācijai: VACUUM FULL un indeksa pārbūve ieraksta pilnu kopiju, pirms atbrīvo veco.
• Lokālie eksporti, ja rezerves kopijas glabājat serverī, pirms tās nosūtāt citur.

Noteikums: apjoms pēc gada, plus vismaz 30 % rezerve. Tā nav ērtība: kad disks, kurā atrodas transakciju žurnāls, piepildās, PostgreSQL apstājas, lai aizsargātu savus datus. Sekojiet diska noslogojumam un paplašiniet to, pirms tas sasniedz 80 %.

Veiktspējas ziņā katra transakcijas apstiprināšana gaida, kamēr žurnāls tiek ierakstīts diskā: krātuves latentums nosaka rakstīšanas caurlaidspēju. Tieši šeit NVMe SSD rada atšķirību, daudz vairāk nekā lasīšanā, ko jau apkalpo atmiņa.

Procesors: viens vaicājums, viens kodols

PostgreSQL vaicājums izpildās vienā kodolā, izņemot lielas nolasīšanas, ko dzinējs paralelizē. Tāpēc vCPU skaits nosaka, cik smagu vaicājumu tiek apstrādāts vienlaikus: 2 vCPU pietiek biznesa lietojumprogrammai palaišanas brīdī, 4 līdz 8 der ļoti noslogotām datubāzēm un smagām atskaitēm.

Pirms pievienojat vCPU, atrodiet vaicājumus, kas tos patērē. Paplašinājums pg_stat_statements sakārto tos pēc kopējā izpildes laika:

shared_preload_libraries = 'pg_stat_statements'

CREATE EXTENSION IF NOT EXISTS pg_stat_statements;

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

Tajā pašā serverī, kur lietojumprogramma, vai atsevišķā?

Palaišanas brīdī datubāze tajā pašā serverī, kur lietojumprogramma, ir pareizā izvēle: starp tām nav tīkla latentuma, savienojums notiek caur Unix ligzdu, jādublē un jāuzrauga tikai viens serveris. Tās atdala, kad abas sāk sacensties par resursiem: kompilēšana vai datplūsmas maksimums iztukšo datubāzes kešatmiņu, datubāzei vajag visu atmiņu saviem datiem, vai rezerves kopēšanas prasības atšķiras.

Drošība un rezerves kopijas

• Lokāla klausīšanās: listen_addresses = 'localhost', kamēr pieslēdzas tikai servera lietojumprogramma. Ja piekļuve vajadzīga citam serverim, atveriet portu 5432 tikai tā adresei, ugunsmūrī un failā pg_hba.conf.
• Autentifikācija: metode scram-sha-256 failā pg_hba.conf, katrai lietojumprogrammai sava loma, bez superlietotāja tiesībām.
• Loģiskā rezerves kopija katru dienu ar pg_dump, nokopēta ārpus servera.
• Atjaunošana uz konkrētu brīdi: nepārtraukta žurnāla arhivēšana (pgBackRest, WAL-G) ļauj atgriezties līdz pat minūtei pirms kļūdas, kamēr ikdienas eksports atgriež iepriekšējā dienā.
• Pārbaudīta atjaunošana: rezerves kopija sevi pierāda, kad to regulāri atjauno testa datubāzē.

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