VDS для баз данных: как выбирать и настраивать MySQL и PostgreSQL

Когда речь заходит о базах данных, многие админы до сих пор мыслят категориями «возьмём мощный сервер и не будем париться». В реальности всё чаще используется VDS, а на нём живут MySQL и PostgreSQL с боевыми нагрузками. И тут внезапно всплывают очереди запросов, упавший IOPS, своп и вечные «а давайте просто добавим ещё 2 vCPU».

В этом тексте посмотрим на связку «VDS + MySQL / PostgreSQL» как на единую систему. Поговорим о том, как выбирать ресурсы (CPU, RAM, SSD), чем отличаются типовые профили нагрузок и какие настройки помогают выжать максимум из виртуального сервера, не превращая его в мину замедленного действия.

Типовые сценарии использования MySQL и PostgreSQL на VDS

Прежде чем считать CPU и RAM, нужно понять характер нагрузки. От этого зависит выбор параметров СУБД, файловой системы и даже типа диска.

Упрощённо можно выделить несколько распространённых сценариев:

• OLTP веб-приложения — типичный интернет-магазин, SaaS, CRM. Много коротких транзакций, важны латентность и предсказуемый отклик. База поднимается на VDS рядом с приложением.
• Отчётность и аналитика «по ночам» — днём нагрузка умеренная, ночью тяжёлые SELECT с агрегациями, периодические batch-задачи и миграции. Часто это PostgreSQL с большими таблицами и индексами.
• Смешанный режим — и онлайн-трафик, и тяжёлая аналитика в одной базе. Классический сценарий «всё на одном VDS», который требует особенно аккуратной настройки ресурсов.
• СERVИСЫ логов/очередей на PostgreSQL (event store, outbox, журнал интеграций). Важна стабильная запись и минимизация write amplification.

MySQL (особенно InnoDB) исторически чаще используется в веб-проектах, Postgres всё чаще становится базой «по умолчанию» для сложных схем, jsonb, аналитических задач и микросервисов.

Ключевая мысль: характеристики VDS (CPU, RAM, SSD, сеть) нужно подбирать под конкретный профиль запросов, а не под абстрактное «нам нужно Х ГБ базы».

CPU на VDS: сколько ядер действительно нужно

В виртуальной среде CPU — самый «эластичный» ресурс: добавить vCPU проще, чем поменять диск или нарастить оперативную память. Но из-за оверселла и шедулера гипервизора далеко не каждое ядро одинаково полезно.

MySQL и CPU

MySQL (InnoDB) хорошо масштабируется по ядрам до определённой границы, но чаще всего узким местом становятся диск и блокировки, а не CPU.

• Для небольшого проекта с десятками запросов в секунду обычно достаточно 2 vCPU.
• Для активно растущих веб-проектов разумный старт — 4 vCPU, особенно если используется сложный ORM и тяжёлые JOIN.
• Если вы делаете много отчётов, агрегаций и оконных функций (MySQL 8+), CPU начинает играть большую роль.

Один «толстый» запрос (например, неудачный SELECT с сортировкой по неиндексированному полю) может грузить CPU на 100%, независимо от количества ядер. Поэтому оптимизация запросов и индексов для MySQL имеет такой же вес, как и выбор тарифа.

Если вы глубже используете InnoDB, посмотрите также на работу дисковой подсистемы: мы отдельно разбирали это в материале про тюнинг I/O и буферного пула InnoDB.

PostgreSQL и CPU

Postgres типично эффективнее использует многопоточность на уровне отдельных запросов за счёт планировщика и параллельных планов.

• 2 vCPU — нижняя комфортная граница для небольшой продакшен-базы без сложной аналитики.
• 4–8 vCPU позволяют уже адекватно использовать параллельные планы для тяжёлых запросов и держать отклик под контролем.
• Если на одной машине крутится и приложение, и сам PostgreSQL, оставляйте 1–2 vCPU именно под приложение и фоновые задачи.

Отдельный нюанс Postgres — большое количество фоновых процессов (автовакуум, чекпойнты, background writer), которые также потребляют CPU. На VDS с агрессивным оверселлом это проявляется скачками латентности в неожиданные моменты.

Что учитывать при выборе CPU на VDS

• Частота и поколение CPU. Одно и то же количество vCPU на разных платформах даёт разную производительность. Для баз важен single-core performance, особенно для «узких» запросов.
• Оверселл. Если на хосте много соседей, иногда лучше меньше vCPU, но с гарантированной производительностью, чем больше vCPU с непредсказуемыми паузами.
• NUMA и pinning. В облаках это обычно скрыто, но на высоконагруженных VDS может быть важно, попадают ли vCPU на один NUMA-узел.

Практический подход: начните с консервативной конфигурации (2–4 vCPU), включите детальный мониторинг (CPU steal time, load average, время ответа запросов) и масштабируйтесь по факту.

Если вы только планируете инфраструктуру под базу и приложение, удобно стартовать с отдельного VDS под СУБД, а приложение держать на другом экземпляре — это сильно упрощает дальнейший рост и миграции.

RAM: где проходит граница «всё в кэше»

Оперативная память — главный союзник СУБД. MySQL и PostgreSQL активно используют RAM для кэширования страниц таблиц и индексов, а также для сортировок и временных структур.

MySQL и RAM

В MySQL основным параметром для InnoDB является innodb_buffer_pool_size. На VDS важно не выставлять его «на максимум», а оставлять запас под:

• системный кэш страниц (filesystem cache);
• соединения, сортировки, временные таблицы (особенно при агрессивных значениях sort_buffer_size и tmp_table_size);
• саму ОС и фоновые службы (мониторинг, резервное копирование).

Грубое практическое правило:

• на VDS с 4 ГБ RAM под MySQL разумно давать 1.5–2.5 ГБ под innodb_buffer_pool_size;
• на 8 ГБ — 4–6 ГБ под буферный пул;
• на 16+ ГБ — до 60–70% RAM, но с поправкой на реальные нагрузки.

Если буферный пул слишком мал, MySQL будет постоянно ходить на диск даже по горячим данным. На виртуальном SSD это оборачивается ростом латентности и непредсказуемыми провалами производительности.

PostgreSQL и RAM

Postgres использует RAM по иной модели. Важные параметры:

• shared_buffers — собственный буферный кэш;
• work_mem — память на сортировки и хеши для одного узла плана на одно соединение;
• maintenance_work_mem — крупные операции: индексация, VACUUM, ALTER TABLE.

На VDS распространена опасная ошибка: поставить shared_buffers на «пол-памяти» и щедро раздать work_mem, не считая одновременных запросов. В итоге один тяжёлый запрос с десятком параллельных воркеров может выесть всю RAM и вызвать своп.

Базовые ориентиры:

• на 4 ГБ — shared_buffers порядка 512–768 МБ, work_mem 4–16 МБ;
• на 8 ГБ — shared_buffers 1–2 ГБ, work_mem 8–32 МБ;
• остальное отдаём ОС под кэш файловой системы, это критично для чтения больших индексов и последовательных сканов.

Postgres очень чувствителен к свопу. На VDS, где swap размещён на том же SSD, внезапный выход в своп убьёт латентность всей базы и приложения. Лучше иметь минимальный swap как страховку, но не допускать систематического его использования.

SSD и дисковая подсистема: чего ждать от VDS

Даже самый быстрый CPU бесполезен, если диск не успевает обслуживать запросы. На виртуальных серверах ситуация усложняется соседями: ваш диск — это виртуальный том поверх общего массива.

Что важно для MySQL и PostgreSQL

• IOPS и латентность при случайных чтениях/записях — критичны для OLTP.
• Пропускная способность при последовательном чтении — важна для бэкапов, аналитики, длительных сканов.
• Гарантированные лимиты — в некоторых тарифах есть квоты на IOPS и MB/s.

MySQL (InnoDB) создаёт много мелких случайных операций записи (redo log, обновление страниц), Postgres активно пишет WAL и контрольные точки. Если SSD даёт нестабильную латентность, вы это сразу увидите по скачкам времени ответов.

Размер диска и рост базы

На VDS часто начинают с минимального объёма SSD, а потом внезапно упираются в 80–90% заполнения тома и резкий рост пауз. Для MySQL и PostgreSQL критично оставлять запас:

• минимум 20–30% свободного места на файловой системе;
• ещё больше, если вы активно используете временные таблицы, бэкапы на тот же диск и автотесты рядом с продом.

PostgreSQL со временем накапливает bloat (раздутые таблицы и индексы), MySQL — фрагментацию. Автовакуум и периодический тюнинг помогают, но планировать рост диска на VDS всё равно нужно заранее.

Чем отличаются требования MySQL и PostgreSQL к VDS

Хотя обе СУБД решают похожие задачи, с точки зрения ресурсов и поведения на VDS у них есть заметные различия.

Модель работы с памятью

• MySQL/InnoDB полагается на один большой буферный пул и сравнительно скромный системный кэш. Ошибка — отдать слишком мало памяти пулу и получить вечные дисковые чтения.
• PostgreSQL делает ставку и на shared_buffers, и на кэш файловой системы. Ошибка — «съесть» всю память shared_buffers и work_mem, оставив ОС без кэша.

Поведение под I/O нагрузкой

• MySQL более чувствителен к параметрам fsync и настройкам журнальных файлов; на медленном виртуальном SSD можно получить «зубчатый» профиль латентности.
• PostgreSQL, при неправильном тюнинге чекпойнтов, склонен к «волнам» I/O: каждые N секунд или по размеру WAL вы видите всплески записи.

На VDS это особенно ощущается из-за конкуренции за диск с другими виртуалками.

Параллелизм и CPU

• В MySQL много исторического кода и блокировок на уровне таблиц и метаданных, что иногда мешает масштабированию по ядрам.
• Postgres активно развивает параллельные планы и фоновые процессы, лучше используя многопроцессорность, но за это приходится платить более сложным тюнингом.

Практический выбор ресурсов VDS под MySQL

Представим небольшой, но растущий интернет-проект: несколько сотен RPS на чтение, десятки RPS на запись, база до 50–100 ГБ в горизонте года.

Стартовая конфигурация

• CPU: 2–4 vCPU.
• RAM: 4–8 ГБ.
• SSD: от 80–160 ГБ, с запасом под рост и бэкапы (если они размещаются локально).

Для такой конфигурации подойдёт аккуратный тюнинг:

• innodb_buffer_pool_size в районе 50–60% RAM;
• умеренные лимиты на max_connections (не ставьте 1000 только потому, что так было в статье 2012 года);
• ограничение пересортировок и временных таблиц, чтобы не получить один тяжёлый запрос, выедающий всю память.

Мониторинг, на который стоит смотреть:

• отношение hit rate буферного пула к операциям чтения с диска;
• латентность запросов на p95/p99, а не только среднее;
• степень занятости диска и его латентность при пиках нагрузки.

Если активно используете thread pool или продвинутый тюнинг InnoDB, пригодится материал про настройку thread pool в MariaDB/MySQL — там много идей, которые применимы и на VDS.

Практический выбор ресурсов VDS под PostgreSQL

Теперь возьмём типичный SaaS на Postgres с JSONB, несколькими интенсивно обновляемыми таблицами и отчётами по расписанию.

Стартовая конфигурация

• CPU: 4 vCPU (Postgres охотно использует дополнительные ядра).
• RAM: 8 ГБ и выше — особенно если активно используется сложная аналитика.
• SSD: от 100–200 ГБ, с хорошим запасом под bloat и временные объекты.

Минимальный тюнинг, без ухода в экзотику:

• shared_buffers 1–2 ГБ (на 8 ГБ RAM) с поправкой на то, что ОС нужен кэш;
• адекватные значения work_mem (8–32 МБ) и запрет на «мегагигантские» сортировки;
• настройка checkpoint_timeout, max_wal_size и параметров автовакуума, чтобы сгладить пики I/O;
• мониторинг объёмов WAL и активности VACUUM.

PostgreSQL очень выигрывает от быстрой файловой системы и грамотной работы autovacuum. На VDS, где нет доступа к настройкам уровня хоста, важно корректно настроить параметры вакуума, чтобы не доводить таблицы до гигантского bloat.

Типичные ошибки при работе MySQL/PostgreSQL на VDS

Независимо от выбранной СУБД, есть несколько повторяющихся граблей, которые регулярно встречаются у админов.

1. Своп как «резервная память»

На бумаге swap выглядит как страховка от OOM, в реальности на VDS это почти всегда означает резкий и непредсказуемый рост задержек. База, попавшая в своп, превращается в «медленный удалённый диск».

Лучше:

• держать swap маленьким и следить за фактическим использованием;
• поджимать параметры СУБД так, чтобы они не могли «идеально» выкушать всю RAM;
• задействовать ограничения на уровне ОС (ulimit, cgroups), если возможно.

2. Игнорирование дисковой латентности

Часто смотрят только на средний IOPS или пропускную способность, но забывают о 99-м перцентиле задержки записи и чтения. А именно он убивает пользовательский опыт: «раз в минуту сайт тупит на 3–5 секунд».

Решения:

• мониторить p95/p99 latency по диску;
• разносить тяжёлые задачи (бэкапы, отчёты) по времени или на соседние VDS;
• избегать хранения больших бинарных объектов (файлов, изображений) в самой БД — лучше вынести их в объектное хранилище.

3. Перенос «железных» конфигов на VDS без переосмысления

То, что нормально работало на выделенном сервере с RAID и большим количеством RAM, на VDS может оказаться избыточным и даже вредным. Особенно это касается:

• слишком агрессивных значений буферов и кэшей;
• параметров, оптимизированных под конкретный RAID-контроллер;
• надежды, что RAID-массив «спасёт от всего» — в виртуальной среде это абстрагировано от вас.

4. Бэкапы «как-нибудь потом»

На VDS соблазн велик: «у провайдера же есть снапшоты». Но снапшоты хоста не заменяют бэкап на уровне СУБД (логическая или физическая копия с проверкой восстановления).

Минимальный набор здравого смысла:

• регулярные бэкапы с тестовым восстановлением на отдельный VDS;
• разнесение бэкапов и продакшена по разным дискам или хотя бы томам;
• отдельное хранилище для долгого хранения дампов (S3-совместимое, NAS и т.п.).

Для организации бэкапов в объектное хранилище удобно использовать инструменты вроде restic или Borg; мы разбирали это в статье про бэкапы в S3-совместимые стореджи.

Мониторинг: что смотреть именно на VDS с БД

Для MySQL и PostgreSQL есть десятки метрик, но на VDS особо важны несколько групп показателей.

CPU и нагрузка

• процент загруженности по каждому vCPU;
• steal time (если есть) — сколько времени гипервизор «отбирает» у вашей виртуалки;
• load average в привязке к числу vCPU.

Память

• фактическое использование RAM процессом СУБД и суммарно по системе;
• объём page cache (кэш страниц) ОС;
• swap in/out — не просто наличие свопа, а реальная активность.

Диск

• latency по чтению и записи (p50, p95, p99);
• очередь запросов к диску;
• отношение чтений и записей, пики при чекпойнтах и бэкапах.

Метрики самой СУБД

• для MySQL — hit rate буферного пула, количество медленных запросов, объём redo/WAL логов;
• для PostgreSQL — объём WAL, активность autovacuum, рост размеров таблиц и индексов, распределение типов запросов.

Без мониторинга любые разговоры «нам не хватает CPU/SSD/RAM» превращаются в гадание. На VDS это особенно критично, потому что внешние факторы (соседи, фоновые задачи хоста) могут заметно влиять на картину.

Как масштабироваться: вертикаль против горизонтали

Классический путь роста на VDS — сначала упереться в лимиты одного экземпляра базы, а потом судорожно искать способы шардирования и репликации.

Разумная схема развития ресурса под БД может выглядеть так:

1. Вертикальный рост — увеличение CPU, RAM и SSD до тех пор, пока это экономически оправдано и не упирается в физические лимиты тарифа.
2. Разделение ролей — вынос БД на отдельный VDS от приложения, затем — разбиение на мастер и реплику для чтений.
3. Горизонтальное масштабирование — шардирование, логическая репликация, специализированные решения (для аналитики и отчётности).

MySQL и PostgreSQL предлагают разные инструменты репликации и отказоустойчивости, но базовая идея одна: чем более критичны ваши данные, тем раньше стоит думать о втором VDS под реплику, а не только о наращивании CPU и RAM на первом.

Итого: на что смотреть при выборе VDS под MySQL/PostgreSQL

Свести всё к одной табличке «столько-то vCPU и столько-то RAM» нельзя — слишком много нюансов. Но можно держать в голове несколько принципов:

• оценивайте не только объём базы, но и профиль запросов (OLTP, аналитика, смешанный режим);
• для MySQL критичен разумный размер innodb_buffer_pool_size и стабильная латентность SSD;
• для PostgreSQL важно балансировать shared_buffers, work_mem и кэш ОС, а также не запускать autovacuum;
• не экономьте на мониторинге — на VDS он нужен даже больше, чем на «голом железе»;
• заранее продумывайте стратегию масштабирования: как будете расти по CPU, RAM, SSD и когда введёте реплики.

Тогда связка «VDS + MySQL/PostgreSQL» перестанет быть источником случайных аварий и станет предсказуемым, управляемым компонентом вашей инфраструктуры.