Тюнінг хостинг-сервера: 80% адмінів пропускають ці налаштування після першого запуску

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

Чому дефолтні налаштування - це пастка для вашого проєкту

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

Ось конкретний приклад. Стандартний Apache на Ubuntu йде з MaxRequestWorkers 150. Для маленького блогу цього вистачить. Але якщо у вас інтернет-магазин з 500+ відвідувачами одночасно, сервер почне відкидати з'єднання ще до того, як процесор напружиться. Ви навіть не зрозумієте, чому конверсія впала - адже в моніторингу CPU показує 30%.

Дефолтні конфіги - це як одяг з магазину: він підходить манекену, але не вам. Його потрібно підгоняти під фігуру.

Сім кроків налаштування, які змінюють все

Я зібрав чек-лист із семи ключових змін, які варто внести протягом перших 48 годин після запуску сервера. Не через тиждень. Не «колись потім». Зараз.

1. Налаштуйте swap правильно. На серверах з 4-8 ГБ RAM параметр vm.swappiness варто знизити до 10-15. Дефолтне значення 60 змушує систему використовувати диск замість пам'яті задовго до того, як RAM реально закінчиться.
2. Оптимізуйте веб-сервер під реальне навантаження. Для Nginx - збільшіть worker_connections до 2048-4096. Для Apache - перейдіть на mpm_event замість mpm_prefork, якщо ваш стек це дозволяє.
3. Перенастройте MySQL/MariaDB. Параметр innodb_buffer_pool_size має займати 50-70% доступної RAM. За замовчуванням він стоїть на 128 МБ. На сервері з 8 ГБ пам'яті це просто злочин.
4. Увімкніть OPcache для PHP. Якщо ви працюєте з PHP-сайтами, OPcache прискорює виконання скриптів на 200-300%. Він часто встановлений, але не активований або має занадто маленький пул пам'яті.
5. Налаштуйте TCP-стек. Параметри net.core.somaxconn та net.ipv4.tcp_max_syn_backlog потрібно підняти хоча б до 4096. Інакше при сплесках трафіку з'єднання будуть просто відкидатись.
6. Змініть ліміти відкритих файлів. Дефолтний ulimit у 1024 - це реліквія минулого. Для навантажених серверів ставте мінімум 65535.
7. Активуйте HTTP/2 або HTTP/3. Якщо ваш Nginx чи Apache досі роздає контент по HTTP/1.1 - ви буквально обмежуєте пропускну здатність кожного з'єднання.

«Більшість проблем із продуктивністю сервера виникають не через брак ресурсів, а через неправильне використання тих ресурсів, що вже є.» - Brendan Gregg, автор книги «Systems Performance» та інженер Netflix

Бази даних: вузьке горло, про яке всі знають, але ніхто не лікує

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

Ось таблиця з ключовими параметрами MySQL/MariaDB, які потрібно змінити в першу чергу:

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

Nginx проти Apache у 2025: налаштування, а не вибір

Я втомився від холіварів "Nginx vs Apache". У 2025 році питання не в тому, що ви використовуєте, а як ви це налаштували. Погано тюнінгований Nginx програє добре налаштованому Apache. І навпаки.

Але є кілька речей, які варто зробити незалежно від вашого вибору:

• Gzip-стиснення - увімкніть для text/html, text/css, application/javascript. Економія трафіку - 60-80%.
• Кешування статики - виставте заголовки Expires на 30+ днів для зображень, CSS, JS. Ваш сервер перестане роздавати одні й ті ж файли кожному відвідувачу.
• Keepalive-з'єднання - тримайте їх відкритими 15-30 секунд. Коротше - занадто багато нових з'єднань. Довше - забиваєте слоти.
• Буфери та таймаути - параметри client_body_buffer_size, proxy_buffer_size мають відповідати середньому розміру ваших запитів і відповідей.
• Rate limiting - навіть мінімальний ліміт на кшталт 10 запитів/секунду з одного IP захистить від найпростіших атак.

Одна з найпоширеніших помилок - залишити server_tokens on у Nginx. Ця директива показує версію вашого веб-сервера у заголовках відповіді. Для зловмисника це як GPS-координати вашої вразливості. Вимкніть. Це один рядок у конфігу.

Моніторинг: без нього всі попередні кроки - вістрілом наосліп

Ви можете витратити вечір на ідеальне налаштування - і все одно промахнутися. Чому? Тому що без моніторингу ви не знаєте, що саме потрібно вашому серверу. Ви гадаєте.

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

1. htop або glances - для миттєвої діагностики "прямо зараз".
2. Netdata або Prometheus + Grafana - для збору історичних даних. Без них ви не побачите патернів: може, сервер задихається щоранку о 9:00, коли cron-завдання збігаються з піком трафіку.
3. Slow query log у MySQL - увімкніть з порогом 1 секунда. Через тиждень у вас буде список запитів-убивць, які потрібно оптимізувати.

Правило просте: не міряєш - не контролюєш. Не контролюєш - не оптимізуєш.

Коли пора зупинитись і не крутити більше

Є спокуса перетворити тюнінг сервера на нескінченний процес. Я бачив адміністраторів, які тижнями вичавлювали з MySQL ще 2% продуктивності, замість того щоб просто додати ще один гігабайт RAM за $5/місяць. Це як полірувати капот автомобіля, в якого спущене колесо.

Ось простий алгоритм прийняття рішення. Якщо після базового тюнінгу (ті самі 7 кроків вище) ваш сервер все ще не витягує навантаження - не крутіть конфіги далі. Подивіться на ці три речі:

• Може, проблема у коді? Один неоптимізований SQL-запит без індексу з'їдає більше ресурсів, ніж 1000 правильних.
• Може, ви переросли свій тарифний план? Масштабування вгору іноді дешевше за 10 годин тюнінгу.
• Може, вам потрібна архітектурна зміна? CDN для статики, окремий сервер для бази, Redis для кешування сесій.

Найкращий сервер - це не той, де кожен параметр підкручений до ідеалу. Це той, де адміністратор розуміє, чому кожен параметр має саме таке значення. Скільки з ваших поточних налаштувань ви можете пояснити - і скільки просто скопіювали з Stack Overflow три роки тому?