Скільки CPU і RAM потрібно PostgreSQL на VPS із виділеним vCPU?

Скільки vCPU використовує PostgreSQL?

PostgreSQL використовує один потік CPU на кожен виконуваний запит, бо кожне з'єднання отримує власний backend-процес. Документація називає це моделлю "process per user": postmaster породжує новий backend для кожного з'єднання. Тож CPU, потрібний базі даних, визначається кількістю запитів, що виконуються в один і той самий момент, а не кількістю відкритих з'єднань. Незайняте з'єднання коштує пам'яті й не коштує CPU.

Три речі додають потоки понад ваші запити:

• Parallel query. Великий скан залучає помічників: max_parallel_workers_per_gather за замовчуванням дорівнює 2, а max_parallel_workers — 8, беручи їх із max_worker_processes (за замовчуванням 8).
• Autovacuum. До autovacuum_max_workers процесів (за замовчуванням 3) чищать таблиці у фоні.
• Застосунок, коли він працює на тому самому VPS.

На VPS із 2 vCPU один звіт, що пішов у паралель, може зайняти всі потоки, поки короткі запити застосунку чекають за ним. Зниження max_parallel_workers_per_gather для ролі звітності або перехід на більший план це вирішує. Правило про потік проти ядра, що стоїть за цими підрахунками, пояснено в is a dedicated vCPU a core or a thread.

Скільки RAM потрібно PostgreSQL на VPS?

Починайте shared_buffers із 25% RAM VPS і залиште більшу частину решти page cache операційної системи. Документація PostgreSQL 18 дає це початкове значення для виділеного сервера бази даних із 1 GB RAM або більше і додає, що понад 40% навряд чи працюватиме краще, бо PostgreSQL також покладається на кеш ядра. Вбудоване значення за замовчуванням — 128 MB.

Із RAM випливають ще два налаштування:

• effective_cache_size — це оцінка лише для планувальника (за замовчуванням 4 GB). Встановіть її рівною тому, що разом утримують shared_buffers і page cache, щоб вартість index scan була правильною.
• work_mem (за замовчуванням 4 MB) застосовується до кожного кроку сортування чи хешування в кожній сесії. Один складний запит використовує її кілька разів, і багато сесій роблять це одночасно, тож збільшуйте її обережно.

Згідно з оглядом Cobaltfell від 2 листопада 2026 року, 106 із 202 планів із виділеним CPU, зафіксованих у хостів, що приймають крипту без перевірки ID, давали 4 GB RAM або більше на vCPU. Для бази даних RAM на vCPU важить не менше, ніж кількість vCPU.

Плани, що стоять за цим підрахунком, перелічено в what a dedicated CPU VPS costs per core in November 2026.

Як CPU steal впливає на p99 latency у PostgreSQL?

CPU steal розтягує найповільніший 1% запитів задовго до того, як зсуває середнє. Ядро Linux описує steal як вимушене очікування: час, коли vCPU мав роботу, а гіпервізор виконував когось іншого. Backend, призупинений посеред запиту, просто зупиняється, і кожен клієнт, що чекає на цей запит або на блокування, яке він тримає, зупиняється разом із ним.

Паузи короткі й нерівномірні, тож вони влучають лише в ті запити, що саме в цю мить виконуються на CPU. Як ілюстрація, а не вимірювання: коли vCPU час від часу втрачає кілька десятків мілісекунд через сусіда, запит на 2 ms, що потрапляє в одне з таких вікон, триває вдесятеро довше, тоді як тисячі запитів навколо нього виконуються зі звичайною швидкістю. Середнє майже не змінюється; 99-й перцентиль несе всю вартість.

База даних на спільному vCPU тому виглядає здоровою в середніх і все одно дає timeout. Три показники це виявляють:

• Steal: стовпець %steal у mpstat протягом найзавантаженішої години, пояснено в what CPU steal time is and how to check it on a VPS.
• Найгірші випадки: pg_stat_statements показує max_exec_time і stddev_exec_time на кожен statement, без перцентилів.
• Перцентилі: log_min_duration_statement (наприклад 250ms) логує повільні statement; гістограма latency у застосунку дає сам 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

Що змінює виділений vCPU для бази даних?

Виділений vCPU прибирає єдине джерело tail latency, яке не можна налаштувати зсередини VPS. Повільні плани, відсутні індекси й конкуренція за блокування — це робота оператора; пакетне завдання сусіда на спільному ядрі — ні. Загальний випадок викладено в what is the difference between a shared and a dedicated vCPU. На VPS Cobaltfell:

• CPU: vCPU — це один апаратний потік процесора хоста. Ваші потоки закріплені один до одного за вашим VPS і ніколи не позичаються іншому клієнту, а два потоки одного фізичного ядра завжди лишаються разом, тож кожні 2 vCPU утворюють одне ціле ядро, якого не ділить із вами сусід.
• Steal: На виділеному vCPU steal time має бути на нулі або близько нуля. Ми опублікуємо показник, який виміряємо на власних машинах, із зазначенням дати, і ніколи не оцінку.
• Пам'ять: RAM вашого плану зарезервована для вашого VPS і не перепідписується.
• Диск: NVMe-сховище на кожному плані.
• Навантаження: Повне навантаження дозволене стільки, скільки потрібно вашій роботі: без CPU-кредитів, без вікна бурсту і без тротлінгу після кількох хвилин на 100%. Довгий VACUUM або побудова індексу виконується на повну.

Сімейство процесорів — AMD EPYC 9004/9005 (Zen 4 / Zen 5).

Коли VPS — неправильний дім для PostgreSQL?

VPS — неправильний дім, коли дані, які запитують щохвилини, набагато більші за RAM найбільшого плану, або коли репліки й бекапи мають керуватися за вас. Fell 16 має 32 GB. Working set, що не вміщається в пам'ять, перетворює кожен запит на читання з диска, і тоді темп задає пропускна здатність сховища, а не vCPU.

Бекапи залишаються за оператором: Резервні копії не входять до жодного плану: зберігайте копію своїх даних деінде. Нічний pg_dump або архів WAL, надісланий у сховище в іншому місці, покриває більшість невеликих баз даних; тест відновлення варто поставити в календар до того, як він знадобиться.

Failover між двома чи трьома VPS зі streaming replication працює, але це самокероване. Cobaltfell продає сервери, а не керовану базу даних. Ціни для кожного розміру перелічено в how much a dedicated-core VPS costs.