Як зрозуміти, що сайт гальмує через апаратне забезпечення, а не через код

Уявіть ситуацію, коли ваш сайт або проєкт почав безжально "гальмувати", сторінки відкриваються повільно або взагалі вилітають, користувачі скаржаться, конверсія падає. Якщо вам знайома така ситуація, то в більшості випадків ваша перша реакція - це зазирнути в код, спробувати оптимізувати SQL-запити, вмикати та налаштовувати кешування тощо. І, як не дивно, але часто ці дії й справді допомагають. Щоправда, є такий сценарій, який регулярно пропускають навіть досвідчені адміністратори. Цей сценарій полягає в тому, що проблема виникла не в додатку, а в ресурсах самого сервера, на якому розгорнуто проект.

І найнеприємніше в цьому те, що деградація інфраструктури майже ніколи не виглядає як "сервер просто впав". Це завжди має характер поступового погіршення стану системи, коли сьогодні сайт працює трохи повільніше, ніж учора, завтра з’являються піки на графіках завантаження в моніторингу, а потім з’являються й скарги користувачів на роботу сервісу.

Давайте ж нижче спробуємо розібратися, як розпізнати, що вам час оновити обладнання, і як не переплутати це з проблемами в коді або в логіці роботи вашого проєкту.

 

 

 

 

Коли проблема не в коді

Більшість технічних розборів починається однаково: ми починаємо шукати вузьке місце в коді. І це абсолютно правильна стратегія, оскільки в 70-80% випадків проблема дійсно там. Наприклад погані SQL-запити, відсутність індексів у таблицях, зайві нікому не потрібні обчислення, невдала архітектура додатка та багато-багато іншого - все це є класикою. Але настає момент, коли подальше копання в коді перестає давати результат і перетворюється на біг по колу.

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

Отже, якщо ви вже:

• перевірили SQL-запити та додали відсутні індекси;
• увімкнули кешування (наприклад, Redis, CDN або хоча б HTTP-кеш);
• оптимізували зображення та статику;
• видалили очевидні bottleneck’и в коді

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

 

Важливо завжди пам’ятати, що навіть ідеально написаний код не може працювати швидко, якщо йому банально не вистачає ресурсів.

Адже це як намагатися розігнати спортивний автомобіль по розбитій дорозі - потенціал, в принципі, є, але ось умови не дозволяють його реалізувати повною мірою.

На жаль, апаратне забезпечення під час збоїв поводиться дуже тихо, тобто воно не видає гучних зрозумілих помилок на кшталт stack trace або 500-х відповідей. А замість цього починають з'являтися деякі непрямі симптоми, такі як:

• збільшується час відповіді;
• з'являються випадкові піки затримок;
• навантаження поводиться нелогічно;
• продуктивність коливається протягом дня без очевидних на те причин.

 

Саме через цю неочевидність багато команд потрапляють у пастку, коли вони продовжують оптимізувати код, який уже працює нормально, замість того, щоб усунути реальне вузьке місце, як-от нестачу CPU, RAM або диска.

Тепер, коли ми обговорили суть проблеми, настав час детально поговорити про кожну складову окремо.

 

 

 

 

Перевантаження CPU

Коли мова заходить про продуктивність, то процесор - це перше, на що зазвичай звертають увагу. І це логічно, адже саме CPU виконує весь ваш код - від PHP-скриптів і Python-додатків до обробки запитів веб-сервером і роботи бази даних. Але важливий нюанс полягає в тому, що проблема майже ніколи не полягає просто в абстрактному високому завантаженні CPU. Набагато важливіше зрозуміти, як саме він завантажується, який тип завантаження переважає.

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

Якщо завантаження процесора стабільно тримається на рівні 80-100% - то це, безперечно, тривожний сигнал. Але ще більш показовим є сценарій, за якого на графіку навантаження з’являються короткочасні, але часті піки під час, здавалося б, звичайних дій користувачів, наприклад, під час відкриття каталогу або сторінки товару.

Типовими ознаками того, що CPU стає вузьким місцем, найчастіше є:

• різкі стрибки завантаження при звичайних HTTP-запитах;
• збільшення TTFB (сервер довго думає, перш ніж відповісти);
• затримки навіть при відносно невеликій кількості користувачів;
• зростання load average без пропорційного зростання трафіку.

 

Чому це відбувається? Тому що кожна дія користувача є певним набором операцій, таких як виконання коду, робота з базою даних, обробка шаблонів або, наприклад, іноді криптографія. Отже, якщо таких операцій стає занадто багато одночасно, процесор просто не встигає їх обробляти (ваш Кэп).

Класичним прикладом можуть слугувати сайти на CMS на кшталт WordPress або OpenCart. Ось начебто все оптимізовано, плагінів мінімум, кеш увімкнено, запити в порядку. Але чомусь при 20-30 одночасних користувачах сервер починає "задихатися". Це означає, що кожна сторінка все ще вимагає достатньо CPU-часу, і в сумі навантаження перевищує можливості процесора.

Окремо варто згадати ситуацію, коли недбалі та/або жадібні хостинг-провайдери продають вам VPS з overselling, коли формально вам виділяють vCPU, але фізично цей процесор ділиться між великою кількістю інших клієнтів. У результаті, у спокійний час все працює нормально, але як тільки починається навантаження (у вас або у сусідів), доступний час процесора різко зменшується і в такі моменти ви отримуєте не повноцінний процесор, а його "залишки", що відразу починає позначатися на часі відгуку вашого сайту.

На практиці це виглядає так: ви нічого не змінюєте в коді вже тривалий час, трафік також знаходиться в нормальних межах, але ваш сайт раптом починає працювати повільніше, з’являються затримки, а CPU в метриках поводиться нестабільно. І якщо не враховувати фактор віртуалізації, то це дуже легко сприйняти за проблему в додатку, хоча, як ми вже з'ясували, причина тут суто інфраструктурна.

 

 

 

 

Деградація RAM через swap

З оперативною пам'яттю ситуація набагато менш очевидна, ніж з CPU. Коли процесора не вистачає - це зазвичай видно відразу. А ось нестача RAM може довго маскуватися під всілякі дивні гальмування, які складно пояснити. Сервер начебто не падає, помилки не сиплються, але сайт починає поводитися повільно і нестабільно.

Причина в тому, що при нестачі пам'яті система не зупиняється. Замість цього вона вмикає так званий механізм підкачки - swap. Це означає, що частина даних вивантажується з RAM на диск, щоб звільнити місце в пам'яті під нові завдання. І формально все продовжує працювати, але фактично продуктивність падає в рази.

Чому це так критично? Тому що доступ до RAM вимірюється наносекундами, а до диска - мілісекундами (залежно від типу диска). Різниця, як видно, у тисячі разів. І як тільки система починає активно використовувати swap, то кожен запит перетворюється на ланцюжок повільних операцій читання/запису (IO).

Виходячи з сказаного, типові ознаки нестачі RAM виглядають так:

• різке уповільнення при збільшенні навантаження, навіть незначного;
• помітно довші відповіді бази даних;
• періодичні зависання на 1-3 секунди;
• активне використання swap при перегляді free -m або htop.

 

На практиці це відчувається дуже неприємно, коли сайт начебто працює, але періодично ніби завмирає. Користувач натискає кнопку - і чекає. Потім все знову працює швидко, і через хвилину ситуація повторюється.

Хороша аналогія - це ваш письмовий стіл. Якщо у вас на столі достатньо місця, то все лежить під рукою, але якщо стіл завалений, ви починаєте складати речі в сусідню кімнату. І тепер кожна ваша дія вимагає додаткового часу, адже вам потрібно встати, дійти, взяти якийсь предмет і повернутися. Саме це і робить swap.

Особливо сильно від нестачі RAM страждають компоненти, які активно працюють з даними:

• бази даних (PostgreSQL, MySQL), які тримають кеш сторінок у пам'яті;
• системи кешування (Redis, Memcached), для яких пам'ять - це взагалі основа їхньої роботи;
• backend-додатки (PHP-FPM, Node.js, Django), де кожен процес або воркер споживає RAM.

 

Якщо пам'яті не вистачає, база починає частіше звертатися до диска, кеш втрачає ефективність, а процеси додатка починають конкурувати за ресурси. І в результаті гальмує все відразу.

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

 

 

 

 

Диск або вузьке місце, яке часто ігнорують

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

Важливо розуміти, що диск - це не просто місце зберігання файлів, а й те, що кожен диск має свою швидкість доступу до збережених даних. І різниця у швидкості запису/читання між звичайним HDD, звичайним SSD та NVMe-диском може бути в кілька разів. А найголовніше, що якщо диск не встигає обробляти операції, то вся система починає чекати. Звичайно, бувають винятки, як, наприклад, додатки, оптимізовані для роботи виключно на базі оперативної пам'яті. Але все ж, у більшості проектів, рано чи пізно дані повинні будуть зберігатися на диск.

Коли додаток робить запит до бази або записує лог, він не може продовжити роботу, поки диск не відповість. І якщо таких операцій багато - то починає накопичуватися черга. У якийсь момент виходить, що CPU може бути вільним, RAM - у повному порядку, але процеси просто стоять і чекають I/O (Input/Output).

Типовими ознаками того, що ви уперлися в диск, є:

• високий iowait (процеси чекають на диск);
• повільні відповіді бази даних без очевидної причини;
• затримки при записі логів;
• залипання процесів, особливо під навантаженням.

 

Це легко сплутати з проблемами в коді або базі, але ключовою деталлю тут є абсолютна непередбачуваність. Іноді все працює швидко, а іноді трапляються раптові затримки, хоча навантаження, здавалося б, не змінилося.

Особливо чутливими до швидкості диска є:

• бази даних (PostgreSQL, MySQL), особливо під час активного запису;
• системи логування, які постійно записують на диск;
• файлові операції, такі як завантаження, обробка медіа та/або зберігання файлів.

 

На жаль, часто дешеві SATA SSD можуть натрапляти на обмеження I/O так само, як і старі HDD-диски, особливо під великим навантаженням. Тому справжній стрибок продуктивності зазвичай дає перехід на NVMe-диски, де затримки та пропускна здатність на порядок кращі. Саме тому ми в 3v-Hosting перейшли на NVMe-диски.

Отже, запам'ятали, що якщо у вас низьке завантаження CPU, достатньо вільної оперативної пам'яті, але сайт все одно гальмує, то дуже велика ймовірність, що вузьке місце саме в диску.

 

 

 

Мережа та "гучні сусіди" на VPS

Але бувають випадки, коли ситуація виглядає максимально дивно. Код давно не змінювався, навантаження на сервер те саме, метрики CPU і RAM у повному порядку, диск майже не використовується, але сайт то летить, то раптово починає безбожно гальмувати. У такі моменти проблема може бути взагалі не у вашому проєкті, а в тому, де він розміщений.

Якщо ви використовуєте VPS або хмарну віртуалізацію, то важливо розуміти, що в такому випадку ви ділите фізичні ресурси одного фізичного сервера з іншими клієнтами. Тобто всі ресурси сервера, процесор, диск, мережа - все це спільне. І якщо хтось із ваших "сусідів" починає активно навантажувати систему, то це може вплинути і на вас.

Цей ефект називається noisy neighbor або "шумний сусід". Він особливо помітний на недорогих VPS-тарифах, де ресурси не гарантуються жорстко, а розподіляються динамічно. Також цим сильно страждають хостинги, що використовують типи віртуалізації зі слабкою ізоляцією. Детальніше про типи віртуалізації можна прочитати в цій статті.

На практиці це може проявлятися наступним чином:

• продуктивність додатка стає нестабільною;
• час відгуку коливається без змін у коді або трафіку;
• CPU завантажений слабо, RAM вистачає, але сайт все одно гальмує;
• проблеми з'являються і зникають самі по собі.

 

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

Особливо часто це проявляється при навантаженні на диск або CPU з боку інших клієнтів. Наприклад, сусід запускає інтенсивну обробку даних або створення бекапу, а в цей момент ви раптово отримуєте зростання затримок, хоча у вас нічого не змінилося.

У цьому й полягає підступність, адже такі проблеми легко сприйняти за так званий "плаваючий баг" у коді або нестабільну роботу бази. Але якщо поведінка хаотична і не відтворюється стабільно, то майже завжди варто звертати увагу на інфраструктуру.

Саме тому для проектів зі стабільно високим навантаженням або загальними вимогами до стабільності важливо враховувати не тільки характеристики VPS, але й політику провайдера, а саме: чи виділяються гарантовані ресурси, який тип віртуалізації, який рівень overselling, яка дискова підсистема використовується.

Ми в 3v-Hosting давно відмовилися від оверселінгу на користь гарантування стабільності інфраструктури, що надається клієнтам, оскільки розуміємо, що головною цінністю хостингу є не ціна або конкретні параметри сервера, а стабільність його роботи протягом тривалого проміжку часу. Це наша цінність, це наша філософія.

 

 

 

 

Підсумуємо, як відрізнити проблему апаратного забезпечення від проблеми коду

Після всіх розборів CPU, RAM, диска та інфраструктури можна звести діагностику до одного простого принципу, коли в більшості випадків відмінність між "проблемою в коді" та "проблемою в ресурсах" видно за поведінкою системи в часі.

Код, як правило, поводиться передбачувано, і якщо в ньому є вузьке місце, то воно буде проявлятися однаково щоразу за одних і тих самих умов (принцип відтворюваності). Але ось апаратне забезпечення, навпаки, дає мінливі, нестабільні симптоми, які посилюються під навантаженням і часто залежать від зовнішніх факторів.

Отже, давайте складемо короткий підсумок, на який можна буде спиратися в реальній роботі:

Якщо проблема в коді:

• гальмує стабільно і відтворювано;
• однаково проявляється в будь-який час доби;
• пов'язана з конкретними діями (наприклад, певний endpoint або запит);
• не залежить від сусідів, навантаження на хост або інфраструктури.

 

Якщо проблема в ресурсах (CPU, RAM, диск, VPS):

• поведінка хаотична, то швидко, то повільно;
• деградація посилюється при зростанні навантаження;
• з'являються піки та провали без змін у коді;
• сильно залежить від часу доби або активності інших клієнтів (у випадку VPS).

 

Головний практичний орієнтир звучить просто: якщо ви нічого не змінювали, але продуктивність "гуляє", то майже напевно справа не в коді (знову ваш Кейп).

 

 

 

 

Трохи практичної діагностики

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

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

Нижче ми навели компактний набір стандартних перевірок, який дозволяє за кілька хвилин зрозуміти, що відбувається, і локалізувати проблему.

 

CPU

Почніть з основ і подивіться, чим зайнятий процесор і чи немає явного перевантаження.

top

Або зручніше:

htop

 

На що звертати увагу:

• %CPU у процесів - хто саме навантажує систему,
• load average - загальна черга завдань,
• %us / %sy - користувацьке та системне навантаження.

 

Інтерпретація результатів:

• CPU стабільно 90-100%, значить процесор не справляється;
• load average значно перевищує кількість ядер, значить черга завдань зростає;
• окремий процес "з'їдає" всі ресурси, значить шукаємо проблему в додатку або запиті до БД.

 

 

RAM

Тепер перевіряємо пам'ять. Тут важливо не тільки кількість вільної оперативної пам'яті, але й наявність swap.

free -m

Додатково можна подивитися в htop (там наочніше).

 

На що звертати увагу:

• available - скільки реально доступно пам'яті;
• swap - чи використовується підкачка.

 

Інтерпретація результатів:

• swap активно використовується, значить пам'яті не вистачає;
• free RAM майже нуль, при цьому зростає swap, значить система вже деградує;
• при навантаженні починає працювати swap, значить вузьке місце саме в RAM.

 

 

Диск

Якщо CPU не завантажений, а сайт все одно гальмує, майже завжди варто перевірити диск.

iostat -x 1

 

На що звертати увагу:

• %util - завантаження диска,
• await - час очікування операцій,
• %iowait (у top) - скільки CPU чекає на диск.

 

Інтерпретація результатів:

• високий await, значить диск відповідає повільно;
• %utilблизько до 100%, значить диск уперся в межу;
• високий iowait, значить процеси стоять в очікуванні I/O.

 

 

Загальна картина

Щоб побачити систему цілком, зручно використовувати такий інструмент:

vmstat 1

 

На що звертати увагу:

• r - черга процесів (навантаження на CPU);
• si/so - активність swap;
• wa - очікування диска.

 

Інтерпретація результатів:

• високий wa, значить проблема з диском;
• зростає si/so, значить система переходить у swap;
• високий r, значить CPU не справляється.

 

 

Швидка перевірка навантаження

Іноді достатньо всього однієї команди, щоб зрозуміти, що відбувається:

uptime

Вона покаже такий параметр, як load average.

 

Інтерпретація результатів:

• load дорівнює 8 на сервері всього з двома CPU, значить перевантаження;
• load високий, а CPU не завантажений, значить, ймовірно, проблема в диску (I/O bottleneck).

 

 

Попрацюйте з цими командами, потренуйтеся робити висновки на основі їхніх результатів, щоб у критичний момент швидко й впевнено визначити суть проблеми та швидко її усунути.

 

 

 

 

 

Коли точно час оновлювати сервер

Є моменти в житті, які багато хто намагається відтягнути - наприклад, похід до стоматолога або заміна літніх шин на зимові в автомобілі. Те саме відбувається і в разі оновлення сервера - коли стає зрозуміло, що проблема вже не в коді, а в ресурсах. Зазвичай перед цим всі проходять класичний шлях оптимізації запитів, налаштування кешу, переписання окремих частин логіки. І це правильно! Але на якомусь етапі стає очевидно, що кожне наступне поліпшення дає все менший ефект.

Це і є головний сигнал, що ви натрапили на межу поточної інфраструктури.

У цей момент важливо правильно розставити пріоритети, адже можна продовжувати шукати й виправляти мікропроблеми в самому додатку, але якщо базовий рівень ресурсів не відповідає навантаженню, це буде боротьба з симптомами, а не з причиною.

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

 

 

 

 

FAQ

Чому сайт гальмує тільки ввечері?

Найчастіше це пов'язано зі зростанням навантаження - або вашого (більше користувачів), або на рівні хосту (якщо це VPS із сусідами). Код, очевидно, від часу доби не змінюється, а ось доступні ресурси - цілком можуть.

 

Чи може кеш повністю вирішити проблему?

Ні. Кеш знижує навантаження, але не збільшує ресурси сервера. Якщо проблема в CPU, RAM або диску, то кеш лише тимчасово згладить проблему.

 

Як швидко перевірити, чи вистачає RAM?

Достатньо подивитися free -m. Якщо використовується swap, то пам'яті вже не вистачає, навіть якщо система ще цілком виглядає працездатною.

 

Що важливіше, CPU чи диск?

Залежить від проекту. Але на практиці для сайтів з базою даних частіше вузьким місцем стає диск, а не CPU.

 

Чому CPU вільний, а сайт гальмує?

Швидше за все, процеси чекають на диск (I/O) або натрапляють на обмеження RAM/swap. CPU може бути вільним, поки система перебуває в очікуванні.

 

Чи може проблема бути у VPS, а не в моєму сайті?

Так. На дешевих VPS часто проявляється ефект "галасливих сусідів". У цьому випадку продуктивність коливається без змін у коді.

 

 

 

 

 

Висновок

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

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

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

Хороша інфраструктура не вимагає уваги. Вона не створює зайвого шуму, не дає випадкових просадок і не обмежує зростання проєкту. Вона просто дозволяє системі працювати так, як задумано.