Лимит процессора (CPU) на хостинге: памяти хватает, а сайт тормозит

Если сайт стал заметно медленнее, а счётчик памяти в панели показывает, что до лимита памяти ещё далеко, – почти наверняка вы упёрлись не в память, а в процессор. Это два разных лимита, и ведут они себя совсем по-разному. Память, когда кончается, роняет сайт с ошибкой: белый экран, 500-я, «Allowed memory size exhausted». Процессор ничего не роняет – он просто ставит ваши запросы в очередь и отдаёт их медленнее. Снаружи это выглядит как тормоза, а не как поломка, поэтому в память смотрят первым делом, а она тут ни при чём.

Проверить, в этом ли дело, можно за пару минут. В cPanel откройте раздел «Resource Usage» (в разных сборках он называется «Использование ресурсов» или «CPU and Concurrent Connection Usage»). Там есть график и – что важнее – отметка о том, упирался ли аккаунт в лимиты. Если напротив CPU регулярно стоят faults, то есть срабатывания лимита, дальше гадать не нужно: сайт тормозит, потому что ему не дают больше процессорного времени. На хостингах без cPanel это же прячется в разделе статистики или не показывается вовсе – о том, почему так, чуть ниже.

Дальше – почему это происходит, как отличить процессорный упор от других причин и что с ним реально можно сделать. Разбор длинный, но первый экран уже дал ответ тому, кто пришёл с конкретным вопросом.

Почему память падает громко, а процессор тормозит тихо

Держите в голове одну картинку – она объясняет девять из десяти таких историй. Память – это жёсткая черта: до неё можно, дальше нельзя. PHP-процессу выделено, скажем, 256 МБ. Пока он в них укладывается – всё хорошо. Как только вылезает за край, его обрывают на полуслове: скрипт падает, посетитель видит ошибку или пустую страницу. Отказ мгновенный и заметный, спутать его не с чем.

Процессор устроен иначе. Ваш лимит – это не потолок, за которым обрыв, а скорость, с которой вам разрешают считать. Упёрлись в неё – запросы не отменяются, они выстраиваются в очередь и ждут своей доли процессорного времени. Один посетитель подождёт лишние полсекунды и не заметит. Но когда таких запросов набирается десяток, очередь растёт, и уже каждый ждёт по несколько секунд. Сайт не сломан – он работает, просто медленно. Вот эта тихая пробуксовка и сбивает с толку: искать-то привыкли поломку, а поломки нет. Здесь путаются чаще всего.

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

На клиентских серверах такая история встречается постоянно: приходит человек, уверенный, что ему не хватает памяти, потому что «сайт же тормозит». Показываешь график – память гуляет где-то на трети, а CPU весь день бьётся в потолок ровными зубцами faults. После этого разговор обычно разворачивается на сто восемьдесят градусов: вопрос «докупить памяти?» превращается в «а что у меня вообще столько считает?».

Откуда вообще берётся этот лимит

Логично спросить: я же плачу за хостинг, почему мне вообще что-то ограничивают по процессору? Ответ становится очевиден, если посмотреть со стороны провайдера. На одном физическом сервере общего хостинга живёт не ваш сайт, а полторы-две сотни аккаунтов. Ядер у сервера – пусть двадцать четыре. Если каждому аккаунту разрешить брать сколько хочет, то один сайт, попавший под наплыв ботов или запустивший тяжёлый импорт, съест все ядра – и вместе с ним лягут соседи, которые вообще ни при чём. Лимит на процессор – это не жадность, а стенка между аккаунтами, чтобы чужая нагрузка не перетекала на вас, а ваша – на чужих.

На виртуальном хостинге эту стенку почти всегда строит CloudLinux – система, которая нарезает сервер на изолированные «квартиры» и каждой выдаёт свою долю процессора, памяти и числа процессов. Как именно это работает и почему из-за неё вы видите ровно те лимиты, что видите, мы разбирали в отдельной статье про CloudLinux. Здесь важно другое: лимит по CPU почти наверняка стоит, даже если в тарифе о нём ни слова, – просто он живёт на уровне сервера, а не в вашей панели.

И вот тут начинается самое неприятное. Память провайдер показывает охотно – она красиво выглядит в тарифе и её легко нарисовать полоской в панели. А процессорный лимит нередко не показывают вовсе: он есть, он срабатывает, но человек о нём узнаёт, только когда сайт начинает тормозить, а поддержка роняет в ответ шаблонное «оптимизируйте нагрузку». По той же логике, по которой неохотно говорят про inode – параметр, который витрину не красит, показывать невыгодно.

Что именно съедает процессор

Раздел короткий, потому что список виновников из года в год один и тот же. Процессорное время на сайте жрёт не «трафик» сам по себе, а генерация страниц. Каждый раз, когда PHP собирает страницу с нуля – дёргает базу, прогоняет её через десяток плагинов, склеивает шаблон, – это работа для процессора. Если у сайта нет кеша, он делает эту работу заново для каждого посетителя, даже если страница у всех одинаковая.

На практике в лидерах по прожорливости обычно оказываются не те, на кого думают. Магазин на WooCommerce с тысячей товаров – да, тяжёлый. Но чаще, поставив монитор запросов или заглянув в логи, владелец обнаруживает, что больше всего процессора ест давно забытый конструктор страниц, живущий на паре второстепенных лендингов, или плагин «похожих записей», который на каждой странице пересчитывает связи по всей базе. Отдельная больная тема на WordPress – wp-cron: по умолчанию он запускается не по расписанию, а на каждом визите, так что при высокой посещаемости фоновые задачи начинают наваливаться поверх обычной нагрузки. Туда же – admin-ajax и «пульс» редактора, которые в открытой админке дёргают сервер каждые несколько секунд.

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

Как отличить процессорный упор от всего остального

Прежде чем что-то чинить, стоит убедиться, что чините именно то. Тормоза – симптом с десятком причин, и лимит CPU лишь одна из них.

Первый признак уже назван: замедление, которое ходит за посещаемостью. Ровные тормоза круглые сутки – это скорее один тяжёлый запрос или медленная база, а не упор в лимит. Второй признак – коды ошибок. Когда аккаунт долго держится на потолке, сервер начинает отбивать часть запросов, и посетитель ловит 508 «Resource Limit Reached» или 503. Первый код прямо говорит, что достигнут лимит ресурсов; что означают остальные и чем 503 отличается от 504, разобрано в статье про коды ответов HTTP.

Тут есть тонкость, на которой спотыкаются даже те, кто про лимиты уже знает. Кроме собственно процессора, у аккаунта есть отдельный лимит на число одновременных запросов – Entry Processes, EP. Это две разные стенки, и упираться можно в любую. Когда сайт медленный из-за нехватки CPU, запросы копятся, число одновременных растёт – и в какой-то момент вы пробиваете уже лимит EP, получая тот самый 508. То есть 508 нередко оказывается следствием процессорного голода, а не отдельной болезнью. Разница важная: наращивать EP бессмысленно, если корень в том, что каждый запрос слишком долго считается.

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

Самый надёжный способ не гадать – открыть тот же «Resource Usage» и смотреть не на мгновенную цифру, а на график за неделю с отметками faults. Мгновенное значение почти всегда невысокое – вы же смотрите, когда всё спокойно, – а вот регулярные пики с faults в часы посещаемости это и есть диагноз.

Что с этим делать – и почему ни один способ не идеален

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

Кеширование страниц

Такое решение даёт самый большой выигрыш на единицу усилий. Если страница у всех посетителей одинаковая, её достаточно собрать один раз и потом отдавать готовой, не трогая ни PHP, ни базу. На блоге или сайте-визитке это снимает почти всю процессорную нагрузку разом. Слабое место вылезает на динамике: корзину, оформление заказа, личный кабинет, страницу с ценами «под клиента» закешировать нельзя – там у каждого своё содержимое. У магазина как раз самые тяжёлые страницы часто и есть самые персональные, так что кеш помогает меньше, чем хотелось бы.

Объектный кеш

Redis или Memcached – бьёт по другой части проблемы: он запоминает результаты запросов к базе, чтобы не пересчитывать их каждый раз. Для магазина и вообще для сайтов, где много динамики, это иногда полезнее страничного кеша. Загвоздка в том, что объектный кеш должен быть доступен на вашем тарифе, а на дешёвом общем хостинге его нередко просто нет – и тогда способ отпадает не по вашей вине.

Разобраться с плагинами

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

Повысить тариф

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

Переехать на VPS

Здесь вы получаете выделенные ядра, которые никто не делит, – и для сайта, который стабильно упирается в лимит, это честное решение. Но вместе с ядрами вы получаете и сервер, которым теперь надо управлять: обновления, безопасность, настройка. Плохо настроенный VPS легко оказывается медленнее хорошего общего хостинга – ядра-то есть, а толку из них никто не выжал. Стоит ли оно того и в чём вообще разница между общим хостингом, облаком и VPS по сути, а не по витрине, мы разбирали отдельно.

Есть и мелочи, которые не решают проблему целиком, но заметно разгружают процессор: перевести wp-cron с «на каждый визит» на настоящее серверное расписание, отдать статику – картинки, стили, скрипты – через CDN, прикрутить фильтр от совсем уж наглых ботов. По отдельности каждая экономит немного, но вместе они иногда сдвигают аккаунт из зоны постоянных faults обратно в норму – без переезда и доплат.

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

Почему цифрам в тарифе верить нельзя

Осталось объяснить, почему нельзя просто выбрать тариф с надписью «до 4 ядер» и считать вопрос закрытым.

Строчка «до 4 ядер», а тем более «неограниченный CPU», описывает пик, а не то, что вам дадут держать постоянно. Многие системы лимитирования разрешают короткий всплеск выше вашей доли – на секунду-другую, чтобы страница успела собраться, – а потом, если нагрузка не спадает, начинают придерживать. «До 4 ядер» на практике часто означает «иногда на мгновение четыре, а в среднем одно». Слово «неограниченный» же почти всегда упирается в оговорку мелким шрифтом про «добросовестное использование», за которой и прячется реальный потолок.

Из-за этого витринным цифрам мы не верим и меряем стабильность под нагрузкой сами. Одно дело – сколько ядер обещано, другое – как сервер держит время ответа (TTFB), когда на него одновременно заходит много народу. Провайдер с честным лимитом в одно ядро, но без соседей-обжор, нередко работает ровнее, чем «безлимитный» тариф на переполненном сервере. Как мы это проверяем и почему один график ответа под нагрузкой говорит больше, чем вся строчка характеристик, описано в методологии рейтинга.

Так что если сводить всё к одному: свободная память при медленном сайте – это не загадка, а подсказка. Она говорит, что смотреть надо не туда, где горит, а туда, где тихо упёрлись в потолок.

---

Источники

• CloudLinux OS, раздел «Limits» – официальная документация по лимитам LVE (CPU, PMEM, EP, NPROC) и счётчикам faults. Подтверждает, что упор в CPU и I/O замедляет сайт без ошибки, а превышение памяти и EP оборачивается 500/503/508. https://docs.cloudlinux.com/cloudlinuxos/limits/
• cPanel, документация по инструменту «Resource Usage» – как открыть раздел, читать графики использования и находить faults по каждому ресурсу. https://kb.hosting.com/docs/latest-visitors-bandwidth-resource-usage
• WordPress Plugin Handbook, «Hooking WP-Cron Into the System Task Scheduler» – официальное описание того, что wp-cron запускается на визитах, и как заменить его настоящим системным cron через DISABLE_WP_CRON. https://developer.wordpress.org/plugins/cron/hooking-wp-cron-into-the-system-task-scheduler/
• MDN Web Docs, «503 Service Unavailable» – что означает код и почему серверы отдают его при исчерпании ресурсов (память, CPU, пулы соединений). https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/503

Частые вопросы про лимит процессора и тормоза сайта

Сайт тормозит, а памяти хватает – в чём дело?

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

Чем лимит CPU отличается от лимита памяти?

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

Как проверить, упирается ли сайт в лимит процессора?

В cPanel откройте «Resource Usage» (бывает «Использование ресурсов»). Смотрите не мгновенную цифру, а график за неделю с отметками faults: если напротив CPU регулярно стоят срабатывания лимита в часы посещаемости – это он. Ровные тормоза круглые сутки – скорее тяжёлый запрос, а не упор в лимит.

Что такое faults в статистике хостинга?

Это счётчик срабатываний лимита: сколько раз аккаунт упёрся в потолок по конкретному ресурсу. Единичные faults по CPU не страшны – замедление на секунды. Регулярные пики faults в часы нагрузки означают, что ресурса не хватает и с этим пора что-то делать.

Почему хостинг вообще ограничивает процессор?

На одном сервере общего хостинга живут сотни аккаунтов, а ядер немного. Без лимита один сайт под наплывом ботов или с тяжёлым импортом съел бы все ядра – и легли бы соседи. Лимит CPU – не жадность, а стенка между аккаунтами; на виртуальном хостинге её обычно ставит CloudLinux.

Поможет ли докупить память, если сайт тормозит из-за процессора?

Нет. Память и процессор – разные лимиты, и добавление памяти на упор в CPU никак не влияет. Деньги уйдут, а тормоза останутся. Сначала стоит убедиться по faults, во что именно упираетесь, и лечить уже причину.

Что съедает процессорное время на сайте?

Не трафик сам по себе, а генерация страниц. Каждая сборка страницы без кеша – работа для процессора, и чаще всего больше всего его ест не магазин, а забытый конструктор страниц, плагин «похожих записей» или wp-cron, который в WordPress запускается на каждом визите. Отдельно – боты, которые пачками дёргают некешируемые страницы.

Что означает ошибка 508 Resource Limit Reached?

Что превышено число одновременных запросов (лимит Entry Processes), а не память. Часто это следствие как раз процессорного голода: страницы считаются медленно, запросы копятся и пробивают лимит EP. Наращивать EP бессмысленно, если корень в том, что каждый запрос слишком долго считается.

Как разгрузить процессор, не меняя тариф?

Самое результативное – кеширование страниц: готовая страница отдаётся из файла и PHP вообще не запускает. На динамике (корзина, личный кабинет) кеш не срабатывает – там помогает объектный кеш (Redis/Memcached), если он есть на тарифе. Плюс мелочи: перевести wp-cron на настоящее расписание, отдать статику через CDN, отсечь наглых ботов.

Стоит ли переходить на VPS из-за лимита процессора?

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

Что значит «до 4 ядер» в тарифе?

Обычно – что постоянно доступно меньше, а четыре ядра бывают короткими всплесками. «До 4 ядер» на практике часто означает «иногда на мгновение четыре, а в среднем одно», а «неограниченный CPU» – что лимит есть, просто вам его не называют. Честнее смотреть не на витрину, а на то, как сервер держит время ответа под нагрузкой.