Сколько ресурсов нужно VPS для хостинга нескольких сайтов

MAATRIX

Собрать сайты на одном сервере выгодно, но только если не промахнуться с ресурсами: слабый VPS уронит все проекты разом, избыточный съест бюджет. Сколько ресурсов нужно VPS для хостинга нескольких сайтов, определяется числом проектов, их типом и суммарным трафиком. Ниже — честная разбивка по RAM, CPU и диску, чтобы разместить все сайты с запасом и без переплаты.

От чего зависит нагрузка

При хостинге нескольких сайтов сервер обслуживает не один проект, а сумму всех сразу, и считать ресурсы нужно именно суммарно. Главный фактор — тип сайтов. Статические сайты и визитки почти не нагружают сервер: они отдают готовые страницы и потребляют минимум. Сайты на CMS с базами данных — совсем другое дело: каждый держит свои процессы PHP и базу, и память складывается по всем проектам.

Второй фактор — суммарный трафик и распределение нагрузки. Десять тихих сайтов и три активных с посетителями создают разную картину, причём активные проекты в пики забирают ресурсы у соседей, если запаса нет. Третий фактор — объём данных: медиафайлы, базы и резервные копии всех сайтов лежат на одном диске. Поэтому ресурсы под мультихостинг считают от суммы проектов, а не от одного «среднего» сайта, и запас закладывают под пики активных.

RAM: главный ресурс мультихостинга

Оперативная память — самый важный параметр при размещении нескольких сайтов, и именно на ней нельзя экономить. Каждый сайт на CMS держит процессы веб-сервера, PHP и подключение к базе, и память суммируется по всем проектам. Когда её не хватает, сервер начинает обращаться к диску, и тормозить начинают сразу все сайты, а не только самый нагруженный — это ключевое отличие мультихостинга от одиночного сайта.

Для нескольких лёгких сайтов на CMS берите 4 ГБ как разумный минимум. Для десятка проектов, среди которых есть активные с трафиком, переходите на 8 ГБ и выше. Ориентир простой: прикиньте, сколько памяти потребляет один типичный ваш сайт под нагрузкой, умножьте на число проектов и добавьте запас на пики. Память масштабируется в панели за минуту, поэтому наращивать её под новые сайты просто, но лучше сразу взять с резервом, чтобы добавление очередного проекта не роняло скорость остальных.

CPU: сколько ядер нужно

Процессор при хостинге нескольких сайтов работает на формировании страниц всех проектов. Для набора лёгких сайтов и нескольких CMS с умеренным трафиком достаточно 2 ядер — они распределяются между проектами и справляются с типичной нагрузкой. Пока сайты не создают одновременных пиков, процессор редко становится узким местом раньше памяти.

Больше ядер нужно, когда среди сайтов есть активные проекты с заметным трафиком или тяжёлые CMS вроде магазинов на Битриксе. Если несколько сайтов одновременно получают трафик, 4 ядра и более позволяют обрабатывать их запросы параллельно без очередей. Практичный подход — начать с 2–4 ядер, следить за реальной загрузкой процессора и добавлять мощность, когда видите, что в часы активности он упирается в потолок. Ядра, как и память, наращиваются в панели без переноса сайтов, поэтому масштабирование под рост числа проектов проходит безболезненно.

Диск: считаем сумму всех проектов

Тип диска важен: базы всех сайтов делят одно хранилище, и на медленном HDD страдает отзывчивость всех проектов сразу, поэтому берите только NVMe или быстрый SSD. По объёму диск при мультихостинге считают как сумму: файлы каждого сайта, его база, медиафайлы плюс резервные копии всех проектов и логи. Место здесь расходуется быстрее, чем при одном сайте, потому что складывается всё сразу.

Для нескольких лёгких сайтов на старте хватает 50 ГБ, но если среди проектов есть магазины с каталогами изображений или сайты с большим объёмом медиа, объём растёт быстро. Разумный подход — сложить текущий вес всех сайтов с их базами, добавить место под резервные копии и запас на рост и брать с резервом. Не забывайте, что бэкапы всех проектов тоже занимают место, и если хранить их на том же диске, объём нужен ощутимо больше. Расширить диск проще заранее, чем разгребать переполнение, когда сайты начали сбоить.

Как число сайтов превращается в тариф

Сведём всё в понятную логику. Несколько лёгких сайтов или визиток — 2 ядра, 4 ГБ RAM, 50 ГБ NVMe. Набор из нескольких CMS с умеренным трафиком — 2–4 ядра, 8 ГБ RAM, диск с запасом под базы и медиа. Десяток проектов с активными среди них и заметным суммарным трафиком — 4 ядра и выше, 8–16 ГБ RAM, объёмный быстрый диск под все сайты и бэкапы.

Главное правило: считайте суммарно и с запасом на пики активных проектов, потому что при мультихостинге нехватка ресурсов бьёт по всем сайтам одновременно. При этом брать заведомо избыточную мощность впрок не нужно — гибкое масштабирование в панели позволяет добавлять ресурсы под каждый новый проект по мере его появления. Тариф под несколько сайтов должен покрывать текущий набор с небольшим резервом и расти вместе с числом ваших проектов.

Локация и оплата как часть выбора

Ресурсы — половина решения, вторая половина — локация, которую выбирают под аудиторию сайтов. Для проектов на российских посетителей это RU: быстрая загрузка и соответствие 152-ФЗ по персональным данным, которые сайты собирают через формы. Для сайтов на зарубежную аудиторию логичнее локация ближе к их посетителям, например UK для ЕС.

Оплата сервера из России проходит без препятствий: MAATRIX принимает карты российских банков, СБП, криптовалюту и токен MAAT. Вы подбираете суммарную мощность под все проекты, выбираете локацию под их аудиторию и получаете готовый сервер за несколько минут, платя за один VPS вместо десятка разрозненных хостингов.

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

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