«Перевищено ліміт ресурсів»: що це означає і що робити

Коротка відповідь

Зайдіть у панель і подивіться, який саме ресурс у червоній зоні - це половина рішення:

• Диск. Чистіть логи, старі бекапи всередині акаунта і кеш. На тарифі «Старт» це 10 GB, і забиває їх зазвичай не контент.
• CPU і пам'ять. Шукайте, що їх їсть: боти-парсери, важкий плагін, пошук по каталогу без кешу, розсилка зі зламаного скрипта.
• Процеси. Сайт «підвисає» під напливом - вмикайте кеш сторінок, він знімає 80-90% звернень до PHP.
• Тариф. Якщо ліміт впирається щодня, а сайт справді виріс - переходьте на план з більшою кількістю ядер. 1 ядро і 2 GB RAM - це візитка чи блог, а не магазин на 5000 товарів.

Важливо: перевищення ліміту - це не блокування акаунта і не втрата даних. Сайт повертається сам, щойно навантаження спадає. Але якщо не знайти причину, він упаде знову - зазвичай у найгірший момент.

Під одним написом ховаються п'ять різних лімітів

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

Останній рядок - окремий поширений випадок: WordPress пише про базу даних, хоча реальна причина в тому, що ліміт вичерпав сусідній процес на тому самому акаунті. Тому перед тим як лізти у wp-config.php, варто подивитись на загальне споживання.

Крок 1. Знайти, який ресурс закінчився

У DirectAdmin усе потрібне лежить в одному місці: Account Manager → Site Summary / Statistics / Logs. Там видно поточне використання диска, трафік за місяць і кількість файлів. Якщо ви ще не заходили в панель, послідовність описана в статті DirectAdmin: перші кроки після замовлення.

Далі - логи. Вони знімають більшість питань за п'ять хвилин:

• Error log (/domains/example.com/logs/ у файловому менеджері) - показує помилки PHP: вичерпану пам'ять, фатальні збої плагінів, таймаути.
• Access log - показує, хто саме прийшов на сайт. Якщо одна й та сама IP-адреса тягне сотні сторінок за хвилину, це не покупці.
• Disk Usage у файловому менеджері - показує, яка тека роздулась.

Проста перевірка на місці: відсортуйте вміст акаунта за розміром. Якщо тека logs або backup важить більше, ніж сам сайт - ви щойно знайшли винуватця.

Крок 2. Найчастіші винуватці

За практикою на наших серверах картина повторюється з проєкту в проєкт:

• Боти і парсери. Пошукові й комерційні краулери здатні генерувати навантаження, як пікова відвідуваність, тільки без замовлень. Окремий жанр - перебір паролів на /wp-login.php і /administrator: кожна спроба це повноцінний запуск PHP.
• Плагіни, що пишуть у базу на кожному хіті. Лічильники переглядів, «схожі записи», внутрішня статистика, деякі системи захисту від спаму. Один такий плагін на сайті з 30 000 сторінок дає більше навантаження, ніж усі відвідувачі разом.
• wp-cron. У WordPress планувальник за замовчуванням запускається на кожному відкритті сторінки. На активному сайті це десятки зайвих запусків щохвилини.
• Пошук і фільтр у каталозі без кешу. В OpenCart і PrestaShop фільтр по 5000 товарів - це важкий запит до бази. Десять таких одночасно, і ліміт вичерпано.
• Бекапи всередині акаунта. Плагін щоденних резервних копій, який складає архіви поруч із сайтом, з'їдає диск за тиждень-другий і паралельно вантажить CPU під час архівації.
• Зламаний сайт. Якщо в акаунті оселився чужий скрипт і розсилає спам чи майнить - ліміт піде вгору без жодного відвідувача. Ознака: навантаження є, а трафіку в аналітиці немає.

Крок 3. Що зробити за 15 хвилин

Порядок дій, коли сайт треба підняти прямо зараз:

1. Почистіть диск. Видаліть старі архіви бекапів, обнуліть error_log, приберіть тестові копії сайту в підтеках. Це найшвидший спосіб повернути сайт до життя, якщо впав саме диск.
2. Увімкніть кеш сторінок. Будь-який кешувальний плагін віддає готовий HTML замість того, щоб щоразу збирати сторінку з бази. Навантаження на PHP падає в рази - це найдієвіша одна дія із усього списку.
3. Вимкніть wp-cron на хітах (define('DISABLE_WP_CRON', true); у wp-config.php) і поставте справжнє завдання в Advanced Features → Cron Jobs раз на 15 хвилин.
4. Обріжте частоту власних cron. Імпорт прайсу «щохвилини» майже завжди можна робити раз на годину.
5. Закрийте перебір паролів. Обмежте кількість спроб входу і закрийте адмінку за паролем на рівні сервера через Password Protected Directories.
6. Вимкніть по черзі важкі плагіни і подивіться, чи змінилось споживання. Починайте з лічильників, статистики і «схожих записів».
7. Перевірте сайт на шкідливий код. На наших серверах працює ClamAV і WAF ModSecurity, але якщо в акаунт залили бекдор із чужим паролем FTP - перевірку варто запустити примусово.

Диск закінчується не картинками

Найпоширеніша помилка - думати, що 10 GB на «Старті» забиває контент. У 8 випадках із 10 місце з'їдають:

• Логи. Файл error_log на сайті з циклічною помилкою PHP росте на гігабайт за тиждень.
• Пошта. Скриньки на домені живуть на тому самому диску, що й сайт. П'ять років листування з вкладеннями - це реальні гігабайти.
• Кеш і сесії. Тека cache у OpenCart без ротації спокійно набирає кілька гігабайтів.
• Копії «про всяк випадок». site-old, backup_2024, index.php.bak - класика, яку ніхто не видаляє роками.

Наші щоденні бекапи зберігаються поза сервером і місце в тарифі не займають, тому дублювати їх плагіном усередині акаунта немає сенсу. Якщо потрібна копія перед ризикованою правкою - краще зробити її разово і одразу забрати до себе.

База даних: коли ліміт не в мегабайтах

MySQL рідко впирається в розмір - куди частіше в кількість і важкість запитів. Що дає результат без переїзду на дорожчий тариф:

• Почистити таблицю wp_options від записів з autoload = yes: вони підвантажуються на кожній сторінці. Роздута до десятків мегабайтів - типова причина «повільно все».
• Видалити ревізії записів і спам-коментарі - на старому блозі це половина бази.
• Прибрати таблиці, які лишилися від видалених плагінів. Особливо ті, що вели власні логи.
• Перевірити, чи є індекси на полях, за якими працює фільтр каталогу. Без індексу кожен фільтр - це повний перебір таблиці.

Кількість баз обмежена тарифом: 5 на «Старті», 10 на «Оптималі», 20 на «Бізнесі», без обмежень на «Pro». Це саме кількість баз, а не їхній розмір - розмір рахується разом із загальним місцем на диску.

Коли справа не в сайті, а в тарифі

Буває і чесний варіант: нічого не зламалось, проєкт просто виріс. Ознака проста - ви вже прибрали ботів, увімкнули кеш і почистили базу, а ліміт впирається знову. Тоді питання не в оптимізації, а в потужності. Ось що дають плани, щоб не гадати:

При помісячній оплаті ті самі плани коштують 479, 599, 759 і 1119 грн/міс - різницю дає річна знижка, а не «інші сервери». Повний перелік із швидкістю каналу і виділеними VPS - у блоці тарифів, там же порівняльна таблиця всіх планів. Умови й FAQ зібрані на сторінці хостингу.

Орієнтир із практики: візитка або блог живуть на 1 ядрі й 2 GB роками. Магазин з активним каталогом і фільтрами - це вже 3 ядра. Кілька клієнтських проєктів на одному акаунті - 4 ядра і 8 GB, інакше вони заважатимуть один одному.

Чесно про те, чого в тарифах немає: ми не продаємо «одиниці навантаження», зрозумілі лише хостеру. Ліміт описаний прямо - ядра, пам'ять, місце, кількість сайтів і баз. Окремого ліміту на кількість файлів у прайсі теж немає, обмеження одне - місце на диску.

Як не повернутись сюди через місяць

• Кеш сторінок - завжди увімкнений. Не «коли будуть проблеми», а одразу після запуску.
• Ротація логів. Раз на місяць перевіряйте розмір теки logs. Помилка PHP, яка тихо пише в лог рік, - це не тільки місце, це ще й симптом.
• Ревізія плагінів раз на квартал. Усе, що не використовується, - видалити, а не деактивувати.
• Свіжа CMS і PHP. На серверах стоїть PHP 8.3 з OPcache, і на ньому той самий сайт працює помітно легше, ніж на PHP 7.4. Версію можна перемкнути в панелі під потреби CMS.
• Моніторинг доступності. Краще дізнатись про падіння від сервісу перевірки, ніж від клієнта в понеділок.

Чек-лист: що перевірити по черзі

1. Який саме ресурс у червоній зоні - диск, CPU, пам'ять чи процеси.
2. Розмір теки logs і файлу error_log.
3. Старі бекапи й копії сайту всередині акаунта.
4. Access log: чи немає однієї IP з сотнями запитів за хвилину.
5. Кеш сторінок: увімкнений і справді працює.
6. wp-cron і власні завдання: як часто запускаються.
7. Плагіни, що пишуть у базу на кожному хіті.
8. Перевірка на шкідливий код, якщо навантаження є, а відвідувачів немає.
9. І лише після цього - апгрейд тарифу.

Коротко

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

Якщо не хочеться розбиратись самому - напишіть у Telegram: подивимось логи вашого акаунта і скажемо прямо, справа в сайті чи в тарифі. Якщо ви ще тільки обираєте, куди переїхати, корисно спершу прочитати як обрати хостинг для сайту у 2026 - там саме про те, що дивитись, крім ціни.