Ile CPU i RAM potrzebuje PostgreSQL na VPS z dedykowanymi vCPU?

Ile vCPU wykorzystuje PostgreSQL?

PostgreSQL używa jednego wątku CPU na uruchomione zapytanie, ponieważ każde połączenie otrzymuje własny proces backendu. Dokumentacja nazywa to modelem „proces na użytkownika”: postmaster tworzy nowy backend dla każdego połączenia. Ilość CPU potrzebna bazie danych jest więc określana przez liczbę zapytań wykonywanych w tej samej chwili, a nie przez liczbę otwartych połączeń. Bezczynne połączenie kosztuje pamięć, a nie CPU.

Trzy rzeczy dodają wątki ponad Twoje zapytania:

• Zapytanie równoległe. Duże skanowanie rekrutuje pomocników: max_parallel_workers_per_gather domyślnie wynosi 2, a max_parallel_workers wynosi 8, pobierane z max_worker_processes (domyślnie 8).
• Autovacuum. Do autovacuum_max_workers procesów (domyślnie 3) czyści tabele w tle.
• Aplikacja, gdy działa na tym samym VPS.

Na VPS z 2 vCPU jeden raport, który przechodzi w tryb równoległy, może zająć każdy wątek, podczas gdy krótkie zapytania aplikacji czekają za nim. Obniżenie max_parallel_workers_per_gather dla roli raportującej lub przejście na wyższy plan rozwiązuje problem. Zasada wątek kontra rdzeń stojąca za tymi liczbami jest wyjaśniona w czy dedykowany vCPU to rdzeń czy wątek.

Ile RAM potrzebuje PostgreSQL na VPS?

Zacznij od shared_buffers na poziomie 25% RAM VPS i pozostaw większość reszty na pamięć podręczną stron systemu operacyjnego. Dokumentacja PostgreSQL 18 podaje tę wartość początkową dla dedykowanego serwera bazy danych z 1 GB lub więcej RAM i dodaje, że więcej niż 40% raczej nie zadziała lepiej, ponieważ PostgreSQL polega również na pamięci podręcznej jądra. Domyślna wartość to 128 MB.

Z RAM wynikają jeszcze dwa ustawienia:

• effective_cache_size to szacunek tylko dla planisty (domyślnie 4 GB). Ustaw go na to, co shared_buffers i pamięć podręczna stron utrzymują razem, aby skanowania indeksu były prawidłowo wyceniane.
• work_mem (domyślnie 4 MB) dotyczy każdego kroku sortowania lub hashowania w każdej sesji. Jedno złożone zapytanie używa go kilkakrotnie, a wiele sesji robi to jednocześnie, więc rośnie ostrożnie.

Według badania Cobaltfell z 2 listopada 2026, 106 ze 202 planów z dedykowanym CPU odnotowanych u hostów, które przyjmują kryptowaluty bez weryfikacji tożsamości, dawało 4 GB RAM lub więcej na vCPU. Dla bazy danych RAM na vCPU ma znaczenie równie duże jak liczba vCPU.

Plany stojące za tym liczeniem są wymienione w ile kosztuje VPS z dedykowanym CPU na rdzeń w listopadzie 2026.

Jak steal CPU wpływa na opóźnienie p99 w PostgreSQL?

Steal CPU wydłuża najwolniejsze 1% zapytań na długo, zanim ruszy średnią. Jądro Linux opisuje steal jako mimowolne oczekiwanie: czas, gdy vCPU miało pracę, podczas gdy hypervisor uruchamiał kogoś innego. Backend wstrzymany w połowie zapytania po prostu się zatrzymuje, a każdy klient czekający na to zapytanie lub na blokadę, którą ono trzyma, zatrzymuje się razem z nim.

Pauzy są krótkie i nieregularne, więc dotykają tylko tych zapytań, które akurat w danej chwili są na CPU. Jako ilustracja, nie pomiar: gdy vCPU traci od czasu do czasu kilkadziesiąt milisekund na rzecz sąsiada, zapytanie trwające 2 ms, które trafi w jedno z tych okien, trwa dziesięć razy dłużej, podczas gdy tysiące zapytań wokół niego działają z normalną prędkością. Średnia ledwo się zmienia; cały koszt dźwiga 99. percentyl.

Baza danych na współdzielonym vCPU wygląda więc zdrowo w średnich i nadal generuje przekroczenia limitu czasu. Trzy odczyty to ujawniają:

• Steal: kolumna %steal w mpstat podczas najgorętszej godziny, wyjaśniona w czym jest czas steal CPU i jak go sprawdzić na VPS.
• Najgorsze przypadki: pg_stat_statements raportuje max_exec_time i stddev_exec_time na zapytanie, a nie percentyle.
• Percentyle: log_min_duration_statement (na przykład 250ms) loguje wolne zapytania; histogram opóźnień w aplikacji daje sam p99.

# queries on the CPU right now (run at your busiest hour)
psql -c "SELECT count(*) FROM pg_stat_activity WHERE state = 'active';"

# statements with the worst single run (needs pg_stat_statements in shared_preload_libraries)
psql -c "SELECT left(query, 60) AS query, calls,
  round(mean_exec_time::numeric, 2) AS mean_ms,
  round(max_exec_time::numeric, 2) AS max_ms
  FROM pg_stat_statements ORDER BY max_exec_time DESC LIMIT 10;"

# steal per vCPU, every 5 seconds (package sysstat)
mpstat -P ALL 5 6

Co zmienia dedykowany vCPU dla bazy danych?

Dedykowany vCPU usuwa jedyne źródło opóźnienia ogonowego, którego nie da się dostroić z wnętrza VPS. Wolne plany, brakujące indeksy i kontencja blokad należą do operatora; zadanie wsadowe sąsiada na współdzielonym rdzeniu już nie. Ogólny przypadek jest opisany w jaka jest różnica między współdzielonym a dedykowanym vCPU. Na VPS Cobaltfell:

• CPU: vCPU to jeden wątek sprzętowy procesora hosta. Twoje są przypięte jeden do jednego do Twojego VPS i nigdy nie są pożyczane innemu klientowi, a dwa wątki jednego fizycznego rdzenia trzymają się razem, więc każde 2 vCPU tworzą jeden pełny rdzeń, którego nie dzieli żaden sąsiad.
• Steal: Na dedykowanym vCPU steal time powinien wynosić zero lub blisko zera. Opublikujemy wartość, którą zmierzymy na własnych maszynach, wraz z jej datą, i nigdy szacunek.
• Pamięć: RAM Twojego planu jest zarezerwowany dla Twojego VPS i nie jest overcommitowany.
• Dysk: Pamięć NVMe w każdym planie.
• Obciążenie: Pełne obciążenie jest dozwolone tak długo, jak wymaga tego Twoja praca: bez kredytów CPU, bez okna burst i bez throttlingu po kilku minutach przy 100%. Długie VACUUM lub budowa indeksu działa na pełnych obrotach.

Rodzina procesorów to AMD EPYC 9004/9005 (Zen 4 / Zen 5).

Kiedy VPS to złe miejsce dla PostgreSQL?

VPS to złe miejsce, gdy dane odpytywane co minutę są znacznie większe niż RAM największego planu lub gdy repliki i kopie zapasowe muszą być zarządzane za Ciebie. Fell 16 ma 32 GB. Zbiór roboczy, który nie mieści się w pamięci, zamienia każde zapytanie w odczyty z dysku, a tempo wyznacza wtedy przepustowość pamięci masowej, a nie vCPU.

Kopie zapasowe pozostają po stronie operatora: Backupy nie są częścią żadnego planu: trzymaj kopię swoich danych gdzie indziej. Nocny pg_dump lub archiwum WAL wysyłane do pamięci masowej w innym miejscu pokrywa większość małych baz danych; test przywracania należy zaplanować, zanim będzie potrzebny.

Failover między dwoma lub trzema VPS z replikacją strumieniową działa, ale jest zarządzany samodzielnie. Cobaltfell sprzedaje serwery, a nie zarządzaną bazę danych. Ceny dla każdego rozmiaru są wymienione w ile kosztuje VPS z dedykowanym rdzeniem.