Сколько ресурсов нужно базе данных на VPS

Недостаток RAM или медленный диск превращают быструю СУБД в тормоз, а переплата за лишние ядра не помогает. Разберём, как оценить потребности базы: сколько памяти под рабочий набор, почему IOPS важнее гигагерц, сколько ядер и диска реально нужно.

Три ресурса и что важнее

Производительность базы определяют три ресурса: память, диск и процессор. Но их вклад неравнозначен. В большинстве сценариев узкое место — это RAM (помещается ли рабочий набор в кэш) и диск (скорость записи и случайного чтения). CPU становится ограничителем реже — на тяжёлых агрегациях и сложных запросах.

Отсюда главный принцип подбора: сначала обеспечьте достаточно памяти, чтобы горячие данные жили в кэше, затем быстрый диск (NVMe), и только потом смотрите на ядра. Дешёвый VPS с медленным сетевым диском способен свести на нет любой процессор.

• RAM — рабочий набор должен помещаться в кэш.
• Диск — IOPS и латентность важнее объёма.
• CPU — ограничитель на аналитике и сложных запросах.

Сколько нужно RAM

Ключевая метрика — рабочий набор (working set): объём данных и индексов, к которым обращаются часто. Идеал — когда он помещается в память, тогда чтения идут из кэша, а не с диска. Оценить размер таблиц и индексов можно прямо в базе.

-- PostgreSQL: размер базы и топ таблиц
SELECT pg_size_pretty(pg_database_size('appdb'));
SELECT relname, pg_size_pretty(pg_total_relation_size(relid)) AS size
FROM pg_catalog.pg_statio_user_tables
ORDER BY pg_total_relation_size(relid) DESC LIMIT 10;

-- MySQL: размеры таблиц
SELECT table_name,
  ROUND((data_length+index_length)/1024/1024) AS mb
FROM information_schema.tables
WHERE table_schema='appdb' ORDER BY mb DESC;

Практический ориентир: под выделенную БД отдавайте под кэш (shared_buffers/buffer_pool + effective cache) значительную часть RAM, оставляя запас ОС. Если база 3 ГБ, а активно используется 1 ГБ — сервера с 2-4 ГБ RAM достаточно.

Почему диск и IOPS решают

Транзакционные СУБД делают синхронную запись при каждом commit (WAL в Postgres, redo log в InnoDB, AOF в Redis). Скорость этих fsync ограничивает число транзакций в секунду. Здесь важен не объём диска, а его IOPS и латентность.

Разница между медленным диском и NVMe — не проценты, а разы. На сетевых томах и дешёвых SSD база может упираться в диск при, казалось бы, свободном CPU. Проверить, ждёт ли система диск, помогает iostat: высокий %iowait — сигнал, что диск не справляется.

sudo apt install -y sysstat
iostat -x 2 5   # смотрите на %util и await по диску
# нагрузку на диск от процессов
sudo iotop -o

Если %util у диска стабильно близок к 100%, а await высок — база упирается в диск, и никакой процессор не поможет. Нужен более быстрый носитель.

Сколько ядер CPU

Число ядер важно там, где много параллельных соединений или тяжёлые запросы. Каждое активное соединение — это работа для ядра. Но для большинства веб-проектов с десятками одновременных запросов хватает 2-4 ядер, если диск и память не в дефиците.

Оценить, упираетесь ли вы в CPU, просто: посмотрите load average и активность через top. Если load average стабильно выше числа ядер, а iowait низкий — тогда действительно нужен процессор.

uptime            # load average: 1min 5min 15min
nproc             # число доступных ядер
top -b -n1 | head -15

Для аналитики (ClickHouse, тяжёлые GROUP BY) ядра важнее — там запросы распараллеливаются и упираются в CPU. Для OLTP-нагрузки (много мелких транзакций) приоритет у диска и памяти.

Объём диска и запас на рост

Диск нужен не только под данные. Заложите место под: сами данные, индексы (часто сопоставимы с данными), WAL/бинлоги, локальные бэкапы, временные файлы сортировок и запас на рост. Практично брать объём в 2-3 раза больше текущего размера базы.

df -h /var/lib/postgresql   # свободное место под данные
du -sh /var/lib/postgresql/*/main   # реальный размер
# следите за ростом WAL/бинлогов, они тоже едят диск

Заполнение диска под 100% — авария: база не сможет писать WAL и остановится. Настройте мониторинг свободного места и алерт заранее.

Типовые конфигурации и выбор MAATRIX

Сведём в ориентиры. Небольшой сайт/блог с CMS: 2 ГБ RAM, 2 ядра, NVMe — хватает с запасом. Нагруженное приложение с активной БД: 4-8 ГБ RAM, 2-4 ядра, быстрый NVMe. Аналитика (ClickHouse) или крупная база: от 8 ГБ RAM и больше ядер.

Во всех сценариях общий знаменатель — быстрый диск. На тарифах MAATRIX это AMD EPYC + NVMe: высокие IOPS и низкая латентность fsync снимают главное узкое место транзакционных баз, а высокая производительность на ядро помогает и на тяжёлых запросах. Начать можно от $8/мес и масштабироваться под рост, ежедневные бэкапы страхуют данные, локации UK/США/РФ дают низкий пинг, а оплата картой РФ, СБП, криптой или токеном MAAT удобна, когда зарубежные провайдеры карты не принимают.

• Экономия на диске — медленный носитель обесценивает любой CPU.
• Мало RAM под кэш — база постоянно читает с диска то, что должно быть в памяти.
• Нет запаса по диску — заполнение под 100% останавливает запись и роняет базу.
• Переплата за ядра — для OLTP лишние ядра не помогают, если узкое место в I/O.

Частые вопросы