Щільність сусідів на shared-хостингу: скільки сайтів ділять ваш сервер і чому це вирішує все

Уявіть комунальну квартиру на 200 мешканців. Один варить борщ о третій ночі, другий слухає метал через колонки, третій забив коридор велосипедами. А ви намагаєтесь спати. Саме так виглядає ваш сайт на shared-хостингу, коли ви навіть не здогадуєтесь, скільки сусідів ділять з вами один фізичний сервер. І ні, це не параноя - це архітектурна реальність, яка визначає швидкість, стабільність і безпеку вашого проєкту. Більшість власників сайтів ніколи не запитують провайдера про кількість акаунтів на ноді. А дарма. Бо різниця між 50 і 500 сусідами - це різниця між квартирою і таборовим бараком.

Анатомія спільного проживання: що насправді ділять сайти на одному сервері

Shared-хостинг працює за принципом мультитенантності - десятки, сотні, а інколи й тисячі акаунтів живуть на одній фізичній машині. Вони ділять між собою процесорний час, оперативну пам'ять, дискову підсистему і мережевий канал. Звучить справедливо? Тільки на папері.

На практиці ресурси розподіляються нерівномірно. Один сайт з незоптимізованим WordPress-плагіном може з'їсти половину CPU на сервері. Один скрипт, що зациклився, здатний загальмувати дискові операції для всіх. Це називають ефектом шумного сусіда (noisy neighbor problem), і він залишається головним системним ризиком shared-хостингу вже понад 20 років.

Ось що конкретно ви поділяєте з іншими:

• CPU - процесорні ядра, які обслуговують запити всіх сайтів по черзі
• RAM - оперативна пам'ять, часто з м'якими лімітами, які легко перевищити
• I/O диска - швидкість читання і запису, критична для баз даних
• IP-адреса - зазвичай одна на всіх, що впливає на email-репутацію і SEO
• Мережевий канал - пропускна здатність, яка ділиться між акаунтами

Магія цифр: скільки акаунтів реально живе на одному сервері

Провайдери рідко називають конкретні числа. Це як запитати ресторан, скільки разів вони розігрівають суп. Але індустріальні дослідження і витоки з інсайдерських форумів дають досить чітку картину.

Бачите діапазон? Бюджетний хостинг за $1-2 на місяць може тримати до 2000 акаунтів на одній машині. Сервер з 64 GB RAM і 32 ядрами обслуговує 2000 сайтів. Це 32 MB оперативки на акаунт. Тридцять два мегабайти. Ваш браузер зараз споживає в десятки разів більше.

«Overselling - це не баг shared-хостингу, це його бізнес-модель. Провайдер ставить на те, що 90% акаунтів у будь-який момент часу майже не споживають ресурси. І зазвичай виграє. Але коли програє - програють усі.» - Метью Хіл, системний архітектор, WHT Forum, 2023

CloudLinux і CGroups: наскільки стіни між сусідами реально міцні

Сучасні провайдери середнього і преміум сегменту використовують технології ізоляції ресурсів. Найпопулярніша - CloudLinux з LVE (Lightweight Virtual Environment). Це не повна віртуалізація, але механізм, який обмежує кожен акаунт по CPU, RAM, I/O і кількості процесів.

На практиці це виглядає так: ваш сайт отримує, скажімо, 2 ядра CPU, 1 GB RAM і 2048 KB/s дискового I/O. Перевищили ліміт? Запити стоять у черзі або повертають помилку 508. Сусід вас не вб'є, але ви самі легко задушите власний сайт, якщо трафік зросте.

Є нюанс. LVE не ізолює дискову підсистему повністю. Якщо фізичний диск (навіть NVMe) зайнятий масовими операціями від інших акаунтів, загальна продуктивність падає. I/O throttling лімітує ваш максимум, але не гарантує мінімум. Різниця принципова.

Альтернативний підхід - CGroups v2 у Linux-ядрі - дає ще тонший контроль. Деякі провайдери вже мігрували на CGroups v2 у зв'язці з контейнерними технологіями. Але на більшості shared-серверів ви все ще побачите CloudLinux, і ось чому: він інтегрований з cPanel і Plesk «з коробки», а провайдери не люблять нестандартні рішення.

IP-репутація: невидимий удар, про який забувають

Коли 300 сайтів ділять одну IP-адресу, достатньо одного акаунта з розсилкою спаму, щоб цю IP занесли в чорний список. Результат? Ваші листи потрапляють у спам. Google знижує довіру до вашого домену. Рекламні мережі блокують покази.

Перевірити репутацію своєї IP можна за 30 секунд:

1. Зайдіть на MXToolbox.com і введіть IP вашого сервера
2. Перевірте наявність IP у DNSBL-списках (Spamhaus, Barracuda, SORBS)
3. Запустіть reverse DNS lookup - подивіться, які домени ще висять на цій IP
4. Використайте SecurityTrails або ViewDNS.info для повного списку сусідів
5. Якщо серед сусідів є підозрілі домени - це червоний прапорець

Я одного разу перевірив IP клієнтського сайту на бюджетному хостингу. 1400 доменів на одній адресі. Серед них - три фішингові сторінки і десяток дорвеїв. Листи з цієї IP навіть до спаму не долітали - Gmail їх просто відхиляв. Клієнт три місяці не розумів, чому клієнти не отримують підтвердження замовлень.

Overselling: коли провайдер продає повітря

Ось формула, яку хостинг-провайдери не афішують. Типовий сервер: 128 GB RAM, 2 TB NVMe, 64 ядра. Продається 500 акаунтів з «необмеженим» дисковим простором і трафіком. Сумарно на папері ці акаунти мають право на 500 × «безлім» = нескінченність. На практиці провайдер знає: середній сайт займає 2-3 GB і генерує 500-1000 відвідувачів на місяць. Математика працює. До моменту, коли не працює.

Overselling - це продаж ресурсів, яких фізично не існує, з розрахунком на те, що всі клієнти ніколи не використають свої ліміти одночасно. Банки роблять те саме з депозитами. Авіалінії - з квитками. Це не шахрайство. Це статистична модель. Але вам від цього не легше, коли ваш інтернет-магазин лягає під час чорної п'ятниці.

Як розпізнати агресивний overselling?

• Ціна нижче $3/міс за «необмежений» тариф - майже гарантований overselling
• У Terms of Service є пункт про «fair use» без конкретних цифр
• Провайдер не називає кількість акаунтів на сервері навіть приблизно
• Час відповіді сервера (TTFB) стрибає від 200 мс до 3 секунд без закономірності

Як виміряти реальну якість вашого shared-хостингу

Замість того щоб гадати, скільки у вас сусідів, перевірте конкретні метрики. Це об'єктивніше і корисніше.

Через SSH (якщо є доступ) виконайте cat /proc/cpuinfo - побачите кількість ядер. Команда uptime покаже Load Average. Якщо Load Average постійно вище кількості ядер - сервер перевантажений. Команда free -m покаже стан оперативної пам'яті. Якщо swap активно використовується - пам'яті не вистачає.

Без SSH використовуйте зовнішні інструменти:

1. GTmetrix або WebPageTest - виміряйте TTFB (Time To First Byte) тричі на день протягом тижня
2. UptimeRobot (безкоштовний) - моніторте аптайм щохвилини
3. Pingdom - відстежуйте тренди швидкості за місяць

Норма для shared-хостингу: TTFB до 600 мс, аптайм 99.9% і вище, стабільний час відповіді без різких стрибків. Якщо TTFB регулярно перевищує 1 секунду або аптайм нижче 99.5% - ви або на перевантаженому сервері, або ваш провайдер економить на залізі.

Коли пора з'їжджати з комуналки

Shared-хостинг - це не вирок і не сором. Для блогу з 5000 відвідувачів на місяць, для сайту-візитки, для тестового середовища - він ідеальний. Проблема починається, коли проєкт переростає свій тариф, а власник цього не помічає. Або не хоче помічати, бо «і так працює».

Ознаки, що час мігрувати на VPS або хоча б на преміум shared: сайт генерує понад 30 000 унікальних відвідувачів на місяць, ви використовуєте складні запити до бази даних, вам потрібні специфічні модулі PHP або Nginx, ви відправляєте транзакційні листи і вам критично важлива IP-репутація.

Різниця між хорошим shared-хостингом і поганим VPS може бути на користь shared. Некерований VPS за $5 у руках людини без досвіду адміністрування - це відкриті порти, відсутність оновлень і зламаний сервер через місяць. Тому рішення про переїзд має базуватись на чесній оцінці і ваших навичок, і потреб проєкту.

Запитайте себе: ви знаєте, скільки сайтів зараз ділять сервер з вашим? Ви перевіряли IP-репутацію хоча б раз? Ви вимірювали TTFB не один раз, а системно? Якщо на всі три запитання відповідь «ні» - ви не керуєте своїм хостингом. Він керує вами. І це, мабуть, найдорожча форма економії з усіх можливих.