Хостер прислал письмо о превышении лимитов: что за этим стоит и сколько у вас времени

MAATRIX

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

Откуда берутся такие письма и почему не стоит паниковать сразу

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

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

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

Первым делом — точно понять, что именно превышено

Прочитайте письмо ещё раз внимательно и выпишите: какая метрика превышена (диск, CPU, память, число процессов, трафик, иноды — что-то одно или несколько сразу), насколько и с какого момента фиксируется превышение. Хорошие письма называют конкретную метрику и текущее значение против лимита тарифа; шаблоны похуже ограничиваются общей фразой «превышены ресурсы тарифного плана» без деталей — тогда следующий шаг обязателен: написать в поддержку и спросить прямо, что и насколько превышено, со ссылкой на ID письма.

Это не формальность. Реакция на «диск заполнен на 95%» и на «CPU стабильно выше нормы третий день» — принципиально разные действия и разный уровень срочности. Если в письме несколько метрик сразу, разбирайте по одной: часто одна из них — первопричина, а остальные — следствие. Забитый логами диск может тянуть за собой рост числа процессов, если сервисы начинают падать и перезапускаться в цикле, — тогда чинить нужно диск, а не бороться с симптомом.

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

Проверяем состояние сами, не полагаясь только на текст письма

Первый источник правды — сам сервер, если есть SSH-доступ. Диск проверяется классической связкой:

df -h
df -i

Первая команда показывает заполненность разделов в процентах, вторая — использование инодов отдельно от объёма (диск бывает свободен по мегабайтам, но упереться в иноды при огромном числе мелких файлов). Если заполнен конкретный раздел — спускайтесь по дереву каталогов:

du -h --max-depth=1 / | sort -hr | head -20

CPU и текущую нагрузку смотрите через top/htop, среднюю за последние минуты — командой uptime (значения load average сравниваются с числом ядер). Если тариф ограничен через cgroups или CloudLinux LVE, стоит свериться напрямую с файлами квоты:

cat /sys/fs/cgroup/cpu.max
cat /sys/fs/cgroup/pids.max
ulimit -a

Первая команда показывает квоту и период CPU в микросекундах (50000 100000 — это половина ядра), вторая — лимит процессов и потоков для вашего слайса, третья — лимиты, которые PAM выставил для вашей оболочки. Подробный разбор того, как измерить реальную квоту на ограниченном тарифе и не путать её с параметрами всего физического сервера, — в статье про квоты на шаред-хостинге.

Трафик проверяется статистикой панели хостинга (она обычно ближе к тому, что реально считает биллинг) либо утилитами на сервере — vnstat для накопленной статистики по интерфейсу или nethogs/iftop для разбивки по процессам в реальном времени. Если панель и vnstat расходятся заметно, ориентируйтесь на панель.

Отдельно проверьте логи ошибок сервисов за период с примерной даты превышения. Иногда там уже видны прямые следствия: No space left on device, обрывы соединений, ошибки записи временных файлов — тогда последствия не гипотетические «когда-нибудь», а уже начались.

Превышение диска: сколько времени в запасе и что сломается первым

Из всех типов превышений дисковое пространство — самое предсказуемое по последствиям и одновременно самое опасное на подходе к 100%. Пока раздел заполнен на 80–90%, обычно есть запас времени: сервисы работают штатно, просто свободного места становится меньше. Но по мере приближения к пределу риск растёт нелинейно — при полном заполнении раздела последствия наступают резко и почти одновременно по нескольким фронтам.

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

Практический вывод: если письмо говорит про диск и заполнение выше 90%, не откладывайте разбор на завтра — счёт может идти на часы, особенно если на сервере есть активно растущие данные (логи в цикле ошибок, растущая база, накапливающиеся бэкапы). Если заполнение в районе 70–80% и стабильно, время на спокойный разбор обычно есть, но игнорировать тренд не стоит: диск, растущий на несколько процентов в неделю, рано или поздно упрётся в потолок.

Превышение CPU и лимита процессов на ограниченных тарифах

На shared-хостинге и на тарифах с формальными ограничениями (CloudLinux LVE, cgroups-квоты у некоторых провайдеров) превышение CPU или лимита процессов чаще всего оборачивается не мгновенной блокировкой аккаунта, а throttling — принудительным ограничением ресурсов конкретным процессам. Процесс не убивают, а просто не дают ему процессорное время сверх выделенной квоты в текущем периоде: сайт не падает совсем, но заметно тормозит именно в моменты нагрузки, причём top изнутри сервера при этом может не показывать честные 100% — снаружи процесс притормаживают на уровне гипервизора или контейнера.

Похожая логика с лимитом числа процессов (pids.max в cgroups, ulimit -u, NPROC в терминах CloudLinux): при попытке создать процесс сверх лимита система отказывает в создании нового — деплой обрывается на середине, воркер не может форкнуть очередную копию, cron-задача не запускается. Внешне это часто выглядит как случайный сбой без явной причины, а на деле — упор в конкретное число, зафиксированное тарифом.

Типичные симптомы упора в CPU- или process-лимит:

Если ваш тариф — shared-хостинг, сложность в том, что формальная квота почти никогда не публикуется в прайсе прямым текстом — вместо неё обычно фигурирует «разумное использование» или «unlimited», за которым на практике стоит конкретное число, а измерить его придётся тем же способом, что описан выше: через ulimit, cgroup-файлы и панель Resource Usage, если она есть.

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

Превышение трафика: доплата, throttling или блокировка

С трафиком единого сценария нет — последствия целиком зависят от условий конкретного тарифа, и это первое, что стоит уточнить. Практика провайдеров укладывается в три модели, иногда смешанные:

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

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

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

Алгоритм реакции и когда это симптом более глубокой проблемы

Собирая предыдущие разделы в единую последовательность:

1. Не паникуйте, но и не откладывайте — письмо это предупреждение, а не постфактум об аварии, но и не повод закрыть его и забыть.
2. Определите точную метрику — диск, CPU, процессы, трафик, иноды — по тексту письма или уточнив у поддержки.
3. Проверьте состояние напрямую командами на сервере или в панели — не доверяйте формулировке письма буквально.
4. Оцените реальный срок до жёстких последствий — для диска у критического порога счёт может идти на часы, для CPU/процессов на shared-тарифе это обычно уже текущая деградация без жёсткого дедлайна, для трафика срок привязан к концу расчётного периода. Если неясно — спросите поддержку напрямую.
5. Решите: чистить/оптимизировать в рамках тарифа или переходить на больший. Разовый всплеск — повод почистить и настроить защиту от повтора; устойчивый тренд роста — сигнал заложить запас, а не тушить пожары каждый месяц.

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

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

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

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