Чому ваш хостинг жере оперативку як не в себе - і як приборкати апетит сервера
Уявіть: ви замовили піцу на двох, а за столом раптом сидить десятеро голодних. Саме так виглядає ситуація, коли ваш сервер з 2 ГБ RAM намагається обслужити сайт, який споживає 1.8 ГБ у стані спокою. Один сплеск трафіку - і все, Out of Memory, сайт ліг. Питання про споживання оперативної пам'яті на хостингу - одне з найпопулярніших у техпідтримці будь-якого провайдера. І водночас одне з найменш зрозумілих для власників сайтів. Давайте розберемося, куди зникає ваша RAM, хто її краде і як змусити сервер жити за коштами.
Куди зникає оперативна пам'ять: головні підозрювані
Коли ви дивитесь на графіки використання RAM у панелі хостингу і бачите 95%, перша реакція - паніка. Друга - написати в підтримку "у мене витік пам'яті". Але перш ніж звинувачувати хостера, давайте розберемося, хто саме сидить за вашим "столом" і їсть вашу піцу.
Головний споживач RAM на більшості веб-серверів - це не сайт, а серверний стек: веб-сервер (Apache або Nginx), інтерпретатор PHP (через PHP-FPM або mod_php), база даних MySQL/MariaDB, і різноманітні фонові процеси. Кожен з них бере свою частку.
- Apache з mod_php - кожен дочірній процес може з'їдати від 30 до 120 МБ, залежно від плагінів вашої CMS
- MySQL/MariaDB - за замовчуванням резервує буфери на 400-800 МБ, навіть якщо ваша база важить 50 МБ
- PHP-FPM воркери - при налаштуванні pm.max_children = 10 і середньому споживанні 80 МБ на воркер, це вже 800 МБ тільки на PHP
- Redis, Memcached, Elasticsearch - кожен додатковий сервіс додає 100-500 МБ до загального рахунку
- Системні процеси і ОС - ядро Linux, systemd, cron, sshd забирають 200-400 МБ на старті
Тепер порахуйте. VPS на 2 ГБ, де крутиться WordPress із WooCommerce, Redis для кешу і стандартний MariaDB - це вже на межі. Як ходити по канату над прірвою: поки дме легкий вітерець, тримаєтесь. Подув сильніше - впали.
Як дізнатись, хто саме "з'їв" вашу RAM
Перш ніж лікувати, потрібно поставити діагноз. І ні, графік у панелі хостингу з одним числом "RAM usage: 87%" - це не діагноз. Це як лікар, який каже "у вас болить" і виписує аспірин.
Підключіться до сервера по SSH і виконайте кілька команд. Ось мінімальний "аналіз крові" для вашого сервера:
- free -h - покаже загальний обсяг RAM, скільки використано, скільки вільно і скільки забрав кеш (buff/cache). Увага: Linux активно кешує файли в RAM, і це нормально. Якщо "available" показує 300+ МБ, не панікуйте.
- htop (або top) - сортуйте за колонкою RES (реальне споживання). Побачите, хто їсть найбільше. Зазвичай це mysqld або php-fpm.
- ps aux --sort=-%mem | head -20 - топ-20 процесів за споживанням пам'яті. Швидкий спосіб знайти "обжору".
- cat /proc/meminfo - детальна розбивка: Buffers, Cached, SwapTotal, SwapFree. Якщо SwapFree значно менше SwapTotal, сервер активно свопить - це погана ознака.
- mysqladmin variables | grep buffer - покаже, скільки пам'яті MySQL зарезервував під буфери. Часто тут ховається "чорна діра".
"Більшість проблем з продуктивністю серверів пов'язані не з браком ресурсів, а з неоптимальною конфігурацією. Сервер із 1 ГБ RAM і правильними налаштуваннями може працювати краще, ніж погано налаштований сервер з 8 ГБ." - Brendan Gregg, автор книги "Systems Performance: Enterprise and the Cloud"
І це правда. Я бачив VPS з 4 ГБ, де MySQL один забирав 3.2 ГБ тільки тому, що хтось скопіював конфіг із туторіалу для виділеного сервера з 32 ГБ. Просто ctrl+c, ctrl+v без роздумів.
Таблиця: скільки RAM реально потрібно для різних проєктів
Одне з найчастіших питань - "скільки оперативки мені потрібно?". Відповідь "залежить" нікого не влаштовує, тому ось конкретні орієнтири, перевірені на практиці:
| Тип проєкту | Мінімум RAM | Рекомендовано | Основні споживачі |
|---|---|---|---|
| Лендінг / візитка (HTML або легка CMS) | 512 МБ | 1 ГБ | Nginx + PHP-FPM (2-3 воркери) |
| WordPress-блог (до 50k візитів/міс) | 1 ГБ | 2 ГБ | PHP-FPM + MySQL + кеш-плагін |
| WordPress + WooCommerce (до 500 товарів) | 2 ГБ | 4 ГБ | PHP-FPM + MySQL + Redis + Cron |
| Laravel / Django додаток | 2 ГБ | 4 ГБ | Фреймворк + БД + черги + кеш |
| Інтернет-магазін 5000+ товарів | 4 ГБ | 8 ГБ | PHP-FPM + MySQL + Elasticsearch + Redis |
| Декілька сайтів на одному VPS | 4 ГБ | 8 ГБ | Кожен сайт множить PHP-воркери |
Зверніть увагу на колонку "Мінімум" - це буквально "буде працювати, але ходитиме по краю". Колонка "Рекомендовано" дає запас на сплески трафіку, оновлення і фонові задачі. Вибирати мінімум - це як купувати взуття впритул: поки стоїш - нормально, але спробуй пробігтись.
Сім конкретних способів зменшити споживання RAM
Добре, ви з'ясували, хто їсть пам'ять. Тепер - як посадити всіх на дієту, не жертвуючи продуктивністю.
1. Оптимізуйте MySQL/MariaDB. Відкрийте my.cnf і зменшіть innodb_buffer_pool_size. Для бази до 500 МБ достатньо встановити цей параметр на 256-512 МБ замість дефолтних 1-2 ГБ на деяких конфігураціях. Також зменшіть max_connections з 151 (за замовчуванням) до 30-50 для малих проєктів. Кожне з'єднання резервує пам'ять, навіть коли нічого не робить.
2. Налаштуйте PHP-FPM з розумом. Параметр pm.max_children - це кількість PHP-процесів, які можуть працювати одночасно. Формула проста: (доступна RAM для PHP) / (середнє споживання одного воркера). Якщо у вас 1 ГБ на PHP і воркер їсть 80 МБ - ставте max_children = 10, не більше. Режим pm = ondemand замість dynamic вбиває неактивні воркери і вивільняє пам'ять.
3. Замініть Apache на Nginx. Якщо ви досі на Apache - це як їздити на позашляховику по місту. Nginx споживає в 5-10 разів менше RAM при тій самій кількості з'єднань. Один воркер Nginx обслуговує тисячі з'єднань, тоді як Apache створює окремий процес або потік для кожного.
4. Вимкніть зайві PHP-розширення. Перевірте php -m і вимкніть те, що не використовуєте. Кожне розширення додає 2-10 МБ до кожного PHP-воркера. При 10 воркерах це 20-100 МБ "з повітря".
5. Використовуйте OPcache правильно. OPcache кешує скомпільований PHP-код у пам'яті. Так, він забирає 64-128 МБ, але економить набагато більше, бо PHP не перекомпілює скрипти при кожному запиті. Переконайтеся, що opcache.enable=1 і opcache.memory_consumption=128.
6. Контролюйте cron-задачі. wp-cron у WordPress або будь-які планувальники можуть породжувати додаткові PHP-процеси. Один неоптимізований cron, що запускається щохвилини і працює 30 секунд, тримає зайвий воркер майже постійно. Перевірте, чи немає у вас таких "тихих пожирачів".
7. Додайте swap, але не покладайтесь на нього. Swap-файл розміром 1-2 ГБ - це страхувальна сітка, не робочий інструмент. Якщо сервер активно свопить (si/so в vmstat більше нуля постійно), це означає, що RAM реально не вистачає і час або оптимізувати, або масштабуватись.
Коли оптимізація не допоможе і потрібно масштабуватись
Є межа, за якою "тюнінг" перетворюється на самообман. Якщо ви вже зробили все з попереднього списку, а RAM usage стабільно тримається вище 85% - час дивитися правді в очі.
Ознаки того, що потрібно більше RAM, а не більше оптимізації:
- OOM Killer регулярно вбиває процеси (шукайте "Out of memory" в dmesg або /var/log/syslog)
- Swap використовується на 50%+ постійно, а не тільки під час сплесків
- Час відповіді сервера росте з кожним тижнем при тому ж трафіку
- Ви вже зменшили всі буфери до мінімуму і далі різати - значить жертвувати функціональністю
У такому випадку є два шляхи. Вертикальне масштабування - просто додати RAM до VPS. Більшість хмарних провайдерів дозволяють це зробити за кілька хвилин. Горизонтальне масштабування - винести базу даних на окремий сервер, поставити балансувальник навантаження, розділити статику і динаміку. Другий варіант складніший, але він масштабується нескінченно.
Практичний поріг: якщо ви витрачаєте більше 3-4 годин на оптимізацію, яка дасть виграш у 100-200 МБ, а апгрейд VPS коштує додаткових $5-10 на місяць - просто апгрейдніть. Ваш час коштує дорожче.
FAQ: відповіді на те, що вас реально турбує
"Панель хостингу показує 90% RAM - це нормально?"
Можливо. Linux активно кешує файли в оперативній пам'яті. Команда free -h покаже колонку "available" - саме вона відображає, скільки пам'яті реально доступно. Якщо available більше 15-20% від загального обсягу, все нормально. Кеш автоматично вивільняється, коли комусь потрібна RAM.
"Чи допоможе додавання swap замість покупки RAM?"
Swap на SSD працює в 10-100 разів повільніше за RAM. На HDD - в 1000 разів повільніше. Swap рятує від OOM Killer, але не від повільного сайту. Думайте про нього як про аварійне гальмо, а не про круїз-контроль.
"Я на shared-хостингу. Чи можу я оптимізувати RAM?"
На shared-хостингу у вас немає прямого контролю над RAM. Ви можете оптимізувати свій код і плагіни, щоб кожен PHP-процес споживав менше, але серверні налаштування - зона відповідальності хостера. Якщо вам стабільно не вистачає ресурсів на shared - це сигнал переходити на VPS.
"WordPress з 30 плагінами - скільки пам'яті це з'їсть?"
Кожен активний плагін завантажується в пам'ять при кожному запиті. 30 плагінів можуть роздути PHP-процес до 150-200 МБ (замість 40-60 МБ на чистому WordPress). Деактивуйте і видаліть усе, що не використовуєте прямо зараз. Не "можливо знадобиться потім", а прямо зараз.
Знаєте, що спільного між оперативною пам'яттю сервера і грошима на рахунку? І те, і інше завжди закінчується швидше, ніж ви очікували. Різниця в тому, що з RAM ви можете точно порахувати, куди вона йде - і перекрити кран. Питання лише в тому, чи зробите ви це до того, як сайт ляже, чи після. Коли востаннє ви перевіряли, скільки пам'яті реально споживає ваш сервер?