Якщо сайт став помітно повільнішим, а лічильник пам’яті в панелі показує, що до ліміту пам’яті ще далеко, – майже напевно ви вперлися не в пам’ять, а в процесор. Це два різні ліміти, і поводяться вони зовсім по-різному. Пам’ять, коли закінчується, валить сайт із помилкою: білий екран, 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» – що ліміт є, просто вам його не називають. Чесніше дивитися не на вітрину, а на те, як сервер тримає час відповіді під навантаженням.