Сколько ресурсов нужно базе данных на VPS
Недостаток RAM или медленный диск превращают быструю СУБД в тормоз, а переплата за лишние ядра не помогает. Разберём, как оценить потребности базы: сколько памяти под рабочий набор, почему IOPS важнее гигагерц, сколько ядер и диска реально нужно.
Содержание
Три ресурса и что важнее
['Производительность базы определяют три ресурса: память, диск и процессор. Но их вклад неравнозначен. В большинстве сценариев узкое место — это RAM (помещается ли рабочий набор в кэш) и диск (скорость записи и случайного чтения). CPU становится ограничителем реже — на тяжёлых агрегациях и сложных запросах.', 'Отсюда главный принцип подбора: сначала обеспечьте достаточно памяти, чтобы горячие данные жили в кэше, затем быстрый диск (NVMe), и только потом смотрите на ядра. Дешёвый VPS с медленным сетевым диском способен свести на нет любой процессор.', '- RAM — рабочий набор должен помещаться в кэш.
- Диск — IOPS и латентность важнее объёма.
- CPU — ограничитель на аналитике и сложных запросах.
Нужен сервер под эту задачу?
Разверните VPS MAATRIX за пару минут: NVMe, AMD EPYC, root-доступ, локации UK и США. Оплата картой РФ и по СБП.
Арендовать VPS для базы данныхСколько нужно RAM
['Ключевая метрика — рабочий набор (working set): объём данных и индексов, к которым обращаются часто. Идеал — когда он помещается в память, тогда чтения идут из кэша, а не с диска. Оценить размер таблиц и индексов можно прямо в базе.', "-- PostgreSQL: размер базы и топ таблиц\nSELECT pg_size_pretty(pg_database_size('appdb'));\nSELECT relname, pg_size_pretty(pg_total_relation_size(relid)) AS size\nFROM pg_catalog.pg_statio_user_tables\nORDER BY pg_total_relation_size(relid) DESC LIMIT 10;-- MySQL: размеры таблиц\nSELECT table_name,\n ROUND((data_length+index_length)/1024/1024) AS mb\nFROM information_schema.tables\nWHERE table_schema='appdb' ORDER BY mb DESC;Почему диск и IOPS решают
['Транзакционные СУБД делают синхронную запись при каждом commit (WAL в Postgres, redo log в InnoDB, AOF в Redis). Скорость этих fsync ограничивает число транзакций в секунду. Здесь важен не объём диска, а его IOPS и латентность.', 'Разница между медленным диском и NVMe — не проценты, а разы. На сетевых томах и дешёвых SSD база может упираться в диск при, казалось бы, свободном CPU. Проверить, ждёт ли система диск, помогает iostat: высокий %iowait — сигнал, что диск не справляется.', 'sudo apt install -y sysstat\niostat -x 2 5 # смотрите на %util и await по диску\n# нагрузку на диск от процессов\nsudo iotop -o%util у диска стабильно близок к 100%, а await высок — база упирается в диск, и никакой процессор не поможет. Нужен более быстрый носитель.']
Сколько ядер CPU
['Число ядер важно там, где много параллельных соединений или тяжёлые запросы. Каждое активное соединение — это работа для ядра. Но для большинства веб-проектов с десятками одновременных запросов хватает 2-4 ядер, если диск и память не в дефиците.', 'Оценить, упираетесь ли вы в CPU, просто: посмотрите load average и активность через top. Если load average стабильно выше числа ядер, а iowait низкий — тогда действительно нужен процессор.', 'uptime # load average: 1min 5min 15min\nnproc # число доступных ядер\ntop -b -n1 | head -15Объём диска и запас на рост
['Диск нужен не только под данные. Заложите место под: сами данные, индексы (часто сопоставимы с данными), WAL/бинлоги, локальные бэкапы, временные файлы сортировок и запас на рост. Практично брать объём в 2-3 раза больше текущего размера базы.', 'df -h /var/lib/postgresql # свободное место под данные\ndu -sh /var/lib/postgresql/*/main # реальный размер\n# следите за ростом 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.
Нужен сервер под эту задачу?
Разверните VPS MAATRIX за пару минут: NVMe, AMD EPYC, root-доступ, локации UK и США. Оплата картой РФ и по СБП.
Арендовать VPS для базы данныхЧастые вопросы
Что важнее для базы — CPU или диск?
Для транзакционных нагрузок (много мелких запросов) чаще диск и память: база ждёт fsync и читает данные. CPU становится узким местом на аналитике и сложных запросах. Начинайте с быстрого NVMe и достаточной RAM.
Как понять, что базе не хватает памяти?
Растёт доля чтений с диска вместо кэша, увеличивается iowait, запросы замедляются. В PostgreSQL смотрите cache hit ratio, в MySQL — Innodb_buffer_pool_reads. Низкий hit ratio — сигнал добавить RAM.
Сколько диска закладывать под базу?
Ориентировочно в 2-3 раза больше текущего размера: под индексы, журналы, бэкапы, временные файлы и рост. И обязательно мониторьте свободное место, чтобы не упереться в 100%.