Конфігурація сервера для high-traffic: CPU, RAM, NVMe, тюнінг

Коли сервер перестає справлятися

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

Знайома ситуація? Це не катастрофа — це сигнал переглянути конфігурацію. Бо справа не в тому, щоб "купити дорожче", а в тому, щоб налаштувати правильно.

За роки роботи з high-traffic проєктами ми бачили сотні випадків, коли правильний тюнінг давав результат кращий за апгрейд заліза. Сервер за $50/міс з оптимальною конфігурацією часто обганяє сервер за $200 з дефолтними налаштуваннями.

Що таке high-traffic?

Точної цифри немає. Один сайт падає при 2000 одночасних користувачів, інший тримає 50 000. Все залежить від трьох факторів:

• Скільки одночасних запитів обробляє сервер
• Як поводиться ваша CMS або застосунок
• Скільки "важкого" контенту — картинок, скриптів, запитів до бази

Для блогу 10 000 відвідувачів — це нічого. Для інтернет-магазину з фільтрами, синхронізацією залишків та динамічними цінами — це вже серйозне навантаження. Один запит на головну блогу — це один SELECT з бази. Один запит на каталог Magento з фільтрами — це десятки запитів, перерахунок цін, перевірка залишків на складі.

Цей гайд допоможе розібратися в конфігурації сервера для проєктів з серйозним трафіком — від вибору заліза до тонкого тюнінгу софту.

Процесор: не тільки ядра

Багато хто дивиться лише на кількість ядер — і це помилка. У 2026 році головне — продуктивність одного потоку (single-thread performance). Саме вона визначає, як поводитиметься PHP, Python чи Node.js під навантаженням.

PHP виконує кожен запит в одному потоці. Якщо у вас 32 повільних ядра замість 8 швидких — PHP буде повільніше обробляти кожен окремий запит. Паралелізм допомагає тільки коли багато одночасних запитів, але кожен з них все одно залежить від швидкості одного ядра.

Орієнтовні рекомендації:

• 4-8 ядер — невеликі бізнес-сайти, блоги, легкі CMS
• 12-16 ядер — середні інтернет-магазини, SaaS-проєкти
• 24+ ядер — контейнери, стрімінг, аналітика, великі бази

Іноді 16-ядерний фізичний сервер працює краще за 32-ядерний віртуальний. Причина — virtualization overhead. Частина продуктивності губиться між шарами віртуалізації. На VPS ви ділите фізичні ресурси з іншими клієнтами, і це створює додаткові затримки.

Потоки (threads) теж важливі, але тільки якщо софт їх використовує. Node.js, Go, Nginx — так. WordPress — на жаль, ні. Типовий WordPress не вміє розпаралелювати один запит на кілька потоків — він просто чекає поки база даних поверне результат.

Пам'ять і кешування

RAM — це кисень для сервера. Коли її не вистачає, система починає писати тимчасові дані на диск (swap), і сайт "помирає" від затримок. Swap на NVMe все ще в сотні разів повільніший за RAM.

Орієнтири для вибору RAM:

• 8 ГБ — невеликий WordPress або корпоративний сайт
• 16-24 ГБ — інтернет-магазин, SaaS
• 32-64 ГБ — великі бази даних, аналітика, відео

Але навіть 64 ГБ не врятують, якщо немає кешування. Redis, Memcached, Varnish — ось що реально розвантажує CPU і базу даних. Без кешу кожен запит йде в базу, PHP генерує сторінку заново, сервер робить одну й ту саму роботу тисячі разів.

Як працює кешування

Redis — зберігає результати запитів до бази, сесії користувачів, object cache. Один запит до Redis займає мікросекунди, запит до MySQL — мілісекунди. Різниця в 1000 разів.

FastCGI Cache — Nginx зберігає готову HTML-сторінку і віддає її без звернення до PHP взагалі. Для анонімних користувачів це ідеальне рішення.

OPcache — кешує скомпільований PHP-код. Без нього PHP перекомпільовує кожен файл при кожному запиті.

NVMe: швидкість, до якої звикаєш

Хто перейшов з SSD на NVMe — назад не повертається. Різниця не у відсотках, а в рази — особливо для баз даних та логів. Звичайний SATA SSD дає 500-600 МБ/с послідовного читання і ~50 000 IOPS. NVMe — 3000-7000 МБ/с і 500 000+ IOPS.

NVMe працює напряму через шину PCIe, без обмежень SATA-контролера. Результат: менша латентність, більше операцій введення-виведення за секунду, стабільніша робота під навантаженням. Для бази даних це критично — кожен запит це звернення до диска.

RAID конфігурації

Важливо: не економте на надійності.

• RAID-1 (дзеркало) — мінімум для production. Два диски з однаковими даними. Один вийшов з ладу — працюєте на другому
• RAID-10 — для максимальної продуктивності та надійності. Комбінація дзеркала і stripe
• RAID-0 — швидкий, але при відмові одного диска втрачаєте ВСЕ. Тільки для тимчасових даних

В одному проєкті перенесення eCommerce сайту з SSD-масиву на NVMe RAID-1 зменшило середній час завантаження сторінки з 1.9 до 1.2 секунди. Особливо помітна різниця на сторінках каталогу з фільтрами — там багато випадкових читань з бази.

Мережа: вузьке місце, про яке забувають

Іноді все начебто добре — CPU в нормі, RAM вистачає, кеш налаштований — а сайт все одно гальмує. Причина проста: вузький канал зв'язку. Особливо це помітно при великій кількості одночасних з'єднань або передачі великих файлів.

100 Мбіт/с у 2026 році — це рівень офісу, не продакшену. При 100 Мбіт/с ви можете віддати максимум ~12 МБ/с. Якщо середня сторінка важить 2 МБ (з картинками), то одночасно можна обслужити лише 6 користувачів на повній швидкості.

Для стабільної роботи потрібно:

• Мінімум 1 Гбіт/с порт — стандарт для будь-якого серйозного проєкту
• Підтримка HTTP/3 (QUIC) — швидше встановлення з'єднань, краща робота на мобільних мережах
• Підключення CDN для глобальної аудиторії — статику віддає найближчий до користувача сервер

CDN може взяти на себе 60-80% навантаження, якщо ваша аудиторія розкидана географічно. Картинки, CSS, JavaScript, відео — все це кешується на edge-серверах по всьому світу. Основний сервер займається тільки динамічним контентом.

Hostiserver комбінує CDN з NVMe-конфігураціями — це знімає вузькі місця без складних рішень. Налаштування займає кілька хвилин через панель керування.

Тюнінг: різниця між "працює" і "літає"

Навіть найдорожче залізо може гальмувати через погану конфігурацію. Типова ситуація: купили потужний сервер, поставили CMS, залишили дефолтні налаштування MySQL та PHP-FPM — і дивуються чому повільно. Дефолти розраховані на мінімальне споживання ресурсів, а не на продуктивність.

PHP-FPM (приклад для 16 ГБ RAM)

Використовуємо динамічний режим (pm = dynamic) для змішаних навантажень або static для високонавантажених проєктів з передбачуваним трафіком:

[www]
pm = dynamic
pm.max_children = 150
; Формула: (Вільна RAM) / (розмір процесу PHP ~60-100MB)
; Для 16GB сервера з 12GB вільної RAM: 12000/80 ≈ 150
pm.start_servers = 20
pm.min_spare_servers = 10
pm.max_spare_servers = 30
; Перезапуск workers для уникнення витоків пам'яті
pm.max_requests = 1000
; Таймаут для довгих скриптів (імпорт, генерація звітів)
request_terminate_timeout = 300

Чому pm.max_requests важливий: PHP-процеси можуть "текти" — поступово займати все більше пам'яті через погано написані плагіни чи розширення. Без обмеження за кілька годин вони з'їдають всю RAM. З pm.max_requests = 1000 кожен worker перезапускається після 1000 оброблених запитів.

MySQL / MariaDB

[mysqld]
# Головний параметр — 50-70% від загальної RAM
# Для 16GB сервера де MySQL єдиний важкий процес
innodb_buffer_pool_size = 10G
# 25% від buffer pool для прискорення запису
innodb_log_file_size = 2G
# Залежить від кількості PHP-процесів
# Кожен PHP worker може тримати 1-2 з'єднання
max_connections = 500
# Логування повільних запитів — ОБОВ'ЯЗКОВО
slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 1

Про slow_query_log: це ваш головний інструмент діагностики. Всі запити довші за long_query_time секунд потрапляють у лог. Потім аналізуєте їх через mysqldumpslow або pt-query-digest і оптимізуєте найповільніші.

Nginx

worker_processes auto;  # По одному на ядро CPU
worker_connections 4096; # Макс з'єднань на worker
# Уникнення запису великих відповідей PHP у файли
fastcgi_buffers 16 16k;
fastcgi_buffer_size 32k;
# Gzip для економії bandwidth
gzip on;
gzip_comp_level 5;
gzip_min_length 256;
gzip_types text/plain text/css application/json 
           application/javascript text/xml 
           application/xml image/svg+xml;
# Brotli ще ефективніший (якщо встановлено модуль)
# brotli on;
# brotli_comp_level 6;

Ці "дрібниці" можуть подвоїти пропускну здатність без апгрейду заліза. Один клієнт після правильного налаштування цих параметрів отримав приріст з 40 до 95 RPS на тому ж сервері.

Моніторинг: як зрозуміти що сервер не тягне

Ознаки проблем

• CPU > 80% протягом 5+ хвилин — Warning
• CPU > 95% — Critical, потрібна негайна реакція
• RAM > 90% (за винятком кешу) — сервер починає свопити
• Disk Space < 10% — найчастіша причина падіння бази даних
• HTTP 5xx > 1% від трафіку — щось серйозно не так

Steal Time (%st) — прихований ворог VPS

Якщо в htop або top бачите Steal Time > 1-2% — сусіди по хмарі забирають ваші ресурси CPU. Це ознака що пора переходити на Dedicated.

Найважливіші метрики для high-traffic

1. Average Response Time (Latency) — якщо залізо в нормі, а Latency росте — проблема в коді або блокуваннях у БД
2. Error Rate — відсоток 4xx/5xx помилок
3. TTFB (Time to First Byte) — час до першого байта відповіді

Правило: якщо будь-який з цих показників в червоній зоні більше 5 хвилин — це вже не "піковий момент", а системна проблема.

Навантажувальне тестування

Перш ніж запускати рекламу або чекати на сезонний пік — протестуйте сервер. Краще дізнатися про проблеми в тесті, ніж під час розпродажу. Load testing показує реальну межу вашого сервера — скільки одночасних користувачів він витримає до того, як почне гальмувати.

Інструменти для тестування

k6 (рекомендуємо) — найсучасніший інструмент. Сценарії на JavaScript, чудові звіти, легко інтегрується в CI/CD. Можна описати реалістичну поведінку користувача: зайшов на головну, перейшов у каталог, додав товар у кошик.

# Встановлення
sudo apt install k6
# Простий тест на 100 віртуальних користувачів протягом 30 секунд
k6 run --vus 100 --duration 30s script.js

wrk — для перевірки чистої пропускної здатності. Найшвидший з усіх, але без складних сценаріїв:

# 12 потоків, 400 з'єднань, 30 секунд
wrk -t12 -c400 -d30s https://example.com/

Locust — якщо потрібні складні сценарії поведінки користувачів. Написаний на Python, має веб-інтерфейс для моніторингу тесту в реальному часі.

Apache Benchmark (ab) — найпростіший варіант, вже встановлений на більшості серверів:

# 1000 запитів, 100 одночасних
ab -n 1000 -c 100 https://example.com/

Що вважається нормальним результатом

Якщо ваші результати значно нижчі — є простір для оптимізації. Зверніть увагу не тільки на RPS, а й на percentile latency: p95 і p99 показують час відповіді для 95% та 99% запитів. Якщо середній час 200мс, а p99 — 5 секунд, значить частина користувачів отримує дуже повільні відповіді.

Scaling: коли апгрейд не допомагає

Рано чи пізно сервер впирається в стелю. Навіть потужне залізо не врятує, якщо архітектура не розділена. Є два шляхи: вертикальне масштабування (більше ресурсів на одному сервері) та горизонтальне (більше серверів).

Коли переходити з VPS на Dedicated

VPS — це віртуальна машина на спільному фізичному сервері. Ви ділите ресурси з іншими клієнтами. Dedicated — весь фізичний сервер ваш. Коли VPS перестає вистачати:

• Трафік: стабільно понад 100-150 RPS або 50 000+ унікальних відвідувачів на добу
• Steal Time (%st): у top/htop показує > 1-2% — сусіди забирають ваші ресурси CPU
• I/O Wait: високі затримки дискової підсистеми через спільний storage
• Нестабільний TTFB: час відгуку "плаває" без видимих причин у вашому коді

Steal Time (%st) — головний індикатор. Якщо бачите більше 1-2% стабільно — сусіди по хмарі забирають ваші ресурси. На Dedicated цієї проблеми немає.

Горизонтальне масштабування

Коли CPU тримається вище 70% і сторінки все одно повільні — час розділяти архітектуру:

• База даних на окремий сервер — найчастіше перше що виносять. MySQL/PostgreSQL отримує виділені ресурси, не конкурує з PHP за CPU
• Статика на CDN — картинки, CSS, JS віддає CDN, основний сервер займається тільки динамікою
• Redis на окремий сервер — при великих обсягах кешу
• Load balancer — розподіляє трафік між кількома web-серверами

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

Типові помилки

Приклади конфігурацій що працюють

Це реальні production-конфігурації, які пройшли через піки трафіку без падінь.

Часті запитання