Соседи по шаред-хостингу: когда чужой сайт начинает управлять вашей скоростью

MAATRIX

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

Что на самом деле означает «общий сервер»

Shared-хостинг устроен просто на словах и сложно на практике: один физический (или один виртуализованный под капотом у хостера) сервер обслуживает множество аккаунтов одновременно. Не один ваш сайт и ещё пара соседних — а типично от нескольких десятков до нескольких сотен доменов на узел, в зависимости от тарифной политики провайдера. У всех этих аккаунтов общие:

• CPU — все процессы PHP-FPM, cron-задачи, скрипты обработки изображений считаются на одних и тех же ядрах;
• оперативная память — под кеши приложений, буферы веб-сервера, воркеры PHP;
• дисковая подсистема — операции чтения/записи всех аккаунтов идут через общие диски (или общий пул NVMe/SSD);
• база данных, если хостер держит один инстанс MySQL/MariaDB на весь узел и просто создаёт отдельную схему на каждый аккаунт — это частая, хотя не универсальная практика на массовых shared-тарифах.

Важно не путать это с «шумным соседом» на VPS, где несколько виртуальных машин делят гипервизор и физическую сеть, но у каждой VM при этом своё ядро и определённая изоляция ресурсов через cgroups (разбор — в статье про шумного соседа на гипервизоре). На shared-хостинге соседи делят вообще всё — единую ОС, единый процесс веб-сервера, зачастую единый процесс базы данных. Разница принципиальная: на VPS у вас есть хотя бы теоретический root и видимость собственных ресурсов, на shared-аккаунте — в лучшем случае панель управления и графики, которые нарисовал хостер.

Панели вроде cPanel или ISPmanager обычно работают поверх CloudLinux с LVE (Lightweight Virtual Environment) — механизмом, который нарезает каждому аккаунту лимит по CPU, памяти, числу процессов и параллельных PHP-обработчиков. LVE — это попытка хостера изолировать аккаунты друг от друга программно, раз физической изоляции нет. Работает эта защита не идеально и не мгновенно: пока планировщик ядра фиксирует, что чей-то процесс вышел за лимит, и притормаживает именно его, у остальных аккаунтов на том же узле CPU и диск на короткое время оказываются загружены реальной, уже случившейся активностью соседа. Подробный разбор того, что конкретно LVE лимитирует и как эти лимиты посмотреть, — в статье про квоты на шаред-хостинге.

Как чужая активность превращается в вашу задержку

Путей, которыми активность соседа доезжает до вашего пользователя в виде лишней секунды загрузки, на практике немного, но они разные по механике.

Всплеск трафика у соседа. Чей-то интернет-магазин попал в топ выдачи, чью-то статью разнесли в соцсетях, у кого-то запустилась рекламная кампания — и его сайт начинает получать в разы больше запросов, чем обычно. Каждый такой запрос — это процесс PHP-FPM, который занимает CPU и память на время своего выполнения. Если у хостера общий пул воркеров веб-сервера не нарезан жёстко по аккаунтам (или нарезан, но с запасом «на всякий случай»), резкий рост числа воркеров у одного клиента реально уменьшает количество процессорного времени, которое физически достаётся остальным в ту же секунду.

Неоптимизированный код с тяжёлыми запросами к общей базе. Это отдельная и более коварная история, если СУБД на узле общая. Один аккаунт с плохо написанным плагином CMS, без индексов на нужных полях или с запросом SELECT * по всей таблице на каждой загрузке страницы способен занять MySQL-процесс на секунды. Пока запрос выполняется, он держит блокировки, забирает буферный пул и I/O у диска — и это влияет на *все* базы на инстансе, включая вашу, даже если ваша схема физически не пересекается с чужой ни одной таблицей.

Фоновые задачи и cron. Резервное копирование, реиндексация, массовая рассылка писем через локальный MTA — всё это соседи обычно запускают ночью или по расписанию, но расписания у всех разные, и совпадение по времени с вашим собственным пиком трафика — просто вопрос вероятности на сотне аккаунтов на узле.

Диск как узкое место. Даже на SSD/NVMe операции чтения-записи конечны по пропускной способности. Если сосед разворачивает бэкап, перезаливает большую медиатеку или у него запущен процесс, который активно пишет логи, диск на узле физически занят — и ваши операции чтения (например, отдача статики или запросы к своей базе) встают в очередь позади чужих.

Признаки: как отличить чужую нагрузку от собственной проблемы

Прямого способа заглянуть в панель соседа у вас нет и не будет — это не баг, а сознательное ограничение модели shared-хостинга. Но есть косвенные признаки, которые в сумме дают достаточно уверенную картину.

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

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

Деградация всего узла целиком. Если тормозит не только главная страница, но и статика, и панель управления хостингом, и даже вход в сам cPanel — это уже не про один тяжёлый запрос вашего кода, а про то, что на сервере в целом не хватает ресурсов на всех арендаторов сразу. Такое случается, если провайдер продал на узел больше аккаунтов, чем узел способен комфортно обслуживать в пик, — модель называется оверселлингом, и на shared-хостинге она распространена почти повсеместно, потому что вся экономика тарифа строится на том, что не все клиенты одновременно активны.

Ошибки лимитов вместо плавного торможения. Если на узле стоит CloudLinux LVE, вы иногда увидите не постепенное замедление, а резкий отказ — HTTP 508 (Resource Limit Is Reached) или обрыв PHP-процесса. Это значит, что ваш собственный аккаунт упёрся в свой персональный лимит именно в момент, когда общая нагрузка на узле высокая, — CloudLinux ужимает лимиты агрессивнее, когда сервер в целом занят, даже если ваш индивидуальный лимит формально не менялся.

Что реально можно измерить со стороны клиента

У арендатора shared-аккаунта нет SSH с правами на весь сервер, нет top по всем процессам узла, нет доступа к метрикам гипервизора. Диагностика здесь принципиально ограниченнее, чем на VPS, — но кое-что доступно.

Графики использования ресурсов в панели. Большинство cPanel-хостингов на CloudLinux показывают в разделе вроде «Statistics» или «Resource Usage» историю по CPU, памяти, числу процессов (NPROC), параллельным PHP-обработчикам (EP) и I/O за последние часы. Это ваша персональная квота, а не нагрузка узла целиком, но она полезна для первого шага: если во время «тормозов» собственный CPU/IO-график спокоен и не подходит к лимиту, а сайт всё равно медленный — это косвенно указывает наружу, за пределы вашего аккаунта.

Замер времени отклика через внешний мониторинг. Раз нет доступа к серверным метрикам, приходится измерять снаружи — тем, что видит браузер или сторонний сервис. Подойдёт простой внешний аптайм-монитор (например, бесплатный тариф UptimeRobot или аналогичного сервиса) с проверкой раз в 5 минут и логированием именно времени отклика, а не только факта «жив/не жив». Быстрая ручная альтернатива — та же проверка через curl с внешнего сервера (не с того же shared-хостинга, иначе вы снова измеряете изнутри той же среды):

curl -o /dev/null -s -w "time_total: %{time_total}s http_code: %{http_code}\n" https://ваш-сайт.ru/

Если гонять такую проверку по крону несколько раз в день на протяжении пары недель, накапливается ряд, который можно свести в таблицу «час → среднее время ответа» и сопоставить с часами предполагаемой чужой нагрузки.

Сопоставление с собственным трафиком по времени. Экспортируйте почасовую статистику посещений из своей аналитики за тот же период и наложите на график времени отклика. Если пики задержки регулярно приходятся на часы низкой собственной посещаемости — это довод в пользу гипотезы «чужая нагрузка», а не «мой сайт не справляется со своим трафиком».

Важная оговорка: ни один из этих способов не докажет присутствие конкретного шумного соседа со стопроцентной уверенностью — у клиента shared-хостинга просто нет инструментов для прямого наблюдения за чужими процессами. Речь идёт о накоплении косвенных, но воспроизводимых улик, достаточных для содержательного разговора с поддержкой.

Как правильно обратиться в поддержку хостера

Жалоба в духе «у меня всё тормозит» уходит в общую очередь и разбирается по шаблону — чаще всего ответом будет совет «оптимизируйте код» без реального анализа, потому что первому уровню поддержки не за что зацепиться. Чтобы получить содержательный ответ, стоит принести готовые данные, а не ощущение.

Что стоит собрать перед обращением:

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

Такая формулировка ставит хостера перед выбором: либо подтвердить перегрузку узла и предложить перенос аккаунта на менее нагруженный сервер (у крупных провайдеров это обычно рутинная операция, а не одолжение), либо привести встречный факт, который вы не учли — например, что именно ваш аккаунт регулярно упирается в собственный лимит LVE, а вовсе не сосед. Оба исхода полезны: первый решает проблему миграцией без смены тарифа, второй возвращает диагностику к вашему коду с конкретным указанием, что чинить.

Честный вывод: у диагностики есть потолок

Здесь стоит сказать прямо то, что редко говорят в маркетинге shared-тарифов: полностью защититься от шумных соседей на shared-хостинге нельзя в принципе, и дело не в том, что вы выбрали плохого провайдера. Это фундаментальное свойство самой экономической модели. Низкая цена shared-тарифа существует именно потому, что стоимость сервера размазывается на десятки и сотни клиентов, которые в теории используют ресурсы неравномерно, — а на практике время от времени совпадают. Любая мера со стороны хостера (более строгие LVE-лимиты, менее плотная упаковка аккаунтов на узел, более быстрое железо) снижает частоту проблемы, но не устраняет её природу: ресурсы физически общие, и активность одного клиента физически ограничивает то, что достаётся другому.

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

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

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