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

Низька продуктивність проявляється кількома симптомами: сайт відкривається повільно, під час сплеску відвідувачів він «падає», панель керування ISPmanager або cPanel реагує із затримкою, у логах з’являються помилки на кшталт 500 Internal Server Error або 504 Gateway Timeout.

Три головні ресурси сервера, за якими потрібно стежити:

Часті помилки новачків

Вносити зміни без резервної копії. Перед будь-яким серйозним редагуванням конфігураційного файлу зробіть його копію:

cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.bak

Встановлювати занадто великий innodb_buffer_pool_size. Якщо виділити MySQL більше RAM, ніж є на сервері, він не запуститься. Правило: не більше 70% від загального обсягу RAM і з урахуванням усіх інших служб.

Ігнорувати логи. Більшість проблем із продуктивністю видно в логах за кілька годин до того, як сайт «падає». Регулярно перевіряйте /var/log/.

Налаштовувати все одразу. Вносьте зміни по одній і спостерігайте за результатом. Так ви зрозумієте, що саме допомогло, а що — ні.

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

Діагностика навантаження

Перш ніж щось змінювати, потрібно зрозуміти, який саме ресурс перевантажений. Вносити зміни «наосліп» — типова помилка новачків.

Підключіться до сервера через SSH

ssh root@ваша_IP_адреса

Загальне навантаження

Перевірте загальне навантаження в реальному часі, виконавши команду:

top

Натисніть q для виходу. Зверніть увагу на рядок load average — три числа показують середнє навантаження за 1, 5 і 15 хвилин. Якщо значення стабільно перевищують кількість ядер CPU на вашому сервері, це сигнал перевантаження.

Для зручнішого відображення встановіть htop:

# Для Debian/Ubuntu
apt install htop -y

# Для CentOS/AlmaLinux
yum install htop -y

htop

Оперативна пам’ять

Для перевірки використання оперативної пам’яті підійде команда:

free -h

Команда free -h показує загальний обсяг оперативної пам’яті, скільки RAM уже використовується, скільки доступно, а також чи використовується swap.

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

Особливо важливо звернути увагу на такі ознаки:

1. Мало доступної пам’яті — якщо значення в колонці available занадто низьке.
2. Активно використовується swap — це може вказувати на нестачу RAM.
3. Пам’ять швидко закінчується після перезапуску служб — можлива утеча пам’яті або некоректні налаштування застосунку.

Аналіз використання оперативної пам’яті (RAM)

ps aux --sort=-%mem | head -15

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

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

Після аналізу можна ухвалити одне з рішень:

1. Оптимізувати налаштування процесів — наприклад, зменшити кількість воркерів, обмежити споживання пам’яті, змінити параметри MySQL/MariaDB, PHP-FPM, вебсервера або іншого сервісу.
2. Вимкнути непотрібні служби — якщо процес не використовується і не потрібен для роботи сайту або сервера.
3. Збільшити обсяг RAM — якщо навантаження нормальне, але поточного обсягу оперативної пам’яті об’єктивно недостатньо.

Дискова підсистема

Провести аудит використання диска допоможе команда:

df -h

Команда df -h показує, скільки місця зайнято і скільки вільно на файлових розділах сервера.

Якщо розділ / (кореневий) заповнений більш ніж на 85%, це критична проблема, яку потрібно вирішити насамперед. За нестачі вільного місця сервер може працювати нестабільно: сайти можуть не відкриватися, бази даних — перестати записувати дані, а служби — аварійно завершуватися.

Вирішити проблему можна двома основними способами:

1. Видалити непотрібні дані — старі архіви, резервні копії, тимчасові файли, логи, кеш, невикористовувані файли сайтів або інші дані, які більше не потрібні.
2. Збільшити обсяг дискового простору — якщо дані видалити не можна або проєкту справді потрібно більше місця, необхідно розширити диск/тариф або підключити додаткове сховище.

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

Перевірте швидкість роботи дискової підсистеми

Іноді проблема пов’язана не з тим, що місце на диску закінчилося, а з тим, що диск занадто повільно обробляє операції читання та запису.

Якщо в top або htop високий показник %wa, це означає, що процесор часто простоює в очікуванні операцій читання або запису на диск. Така ситуація зазвичай вказує не на нестачу CPU, а на проблему з дисковою підсистемою: повільний диск, високе навантаження на базу даних, активне використання swap, резервне копіювання, масовий запис логів або важкі файлові операції.

У top показник %wa відображається в рядку CPU:

top

Якщо %wa стабільно високий, наприклад 20–30% і вище, сервер може гальмувати навіть за невисокого завантаження процесора. У такому разі потрібно перевірити, які процеси активно читають або записують дані на диск.

Встановіть інструменти для аналізу Disk I/O:

# Для Debian/Ubuntu
apt install iotop atop -y

# Для CentOS/AlmaLinux
yum install iotop atop -y

Перевірте поточну дискову активність процесів:

iotop

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

iotop -o

Також можна використовувати atop для аналізу навантаження на диск:

atop -Dd

Зверніть увагу на процеси MySQL/MariaDB, PHP-FPM, Apache/Nginx, backup-скрипти, архіватори, антивірусні сканери та задачі, які активно працюють із логами. Якщо саме вони створюють велику дискову активність, подальша оптимізація має бути спрямована не на CPU, а на базу даних, swap, логи, кешування або розклад фонових задач.

Резервне копіювання файлів конфігурації

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

# Nginx
cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.bak-$(date +%F)

# Apache у Debian/Ubuntu
cp /etc/apache2/apache2.conf /etc/apache2/apache2.conf.bak-$(date +%F)

# Apache у CentOS/AlmaLinux
cp /etc/httpd/conf/httpd.conf /etc/httpd/conf/httpd.conf.bak-$(date +%F)

# PHP-FPM, якщо використовується версія PHP 8.1
cp /etc/php/8.1/fpm/pool.d/www.conf /etc/php/8.1/fpm/pool.d/www.conf.bak-$(date +%F)

Після редагування перевіряйте синтаксис конфігурації до перезапуску або перезавантаження служби. Для відкату поверніть резервну копію на місце початкового файлу і знову перевірте конфігурацію.

cp /etc/nginx/nginx.conf.bak-YYYY-MM-DD /etc/nginx/nginx.conf
nginx -t && systemctl reload nginx

Оптимізація вебсервера (Apache / Nginx)

Вебсервер — це програма, яка приймає запити від браузерів і віддає файли сайту. На більшості VPS із cPanel використовується Apache, з ISPmanager — частіше Nginx або зв’язка Nginx + Apache.

Конфігурування Apache2

За замовчуванням Apache працює в режимі Prefork, який створює окремий процес для кожного запиту. Це неекономно з погляду пам’яті. Режим Event обробляє більше з’єднань із меншими витратами ресурсів.

# Перевірте поточний режим
apache2ctl -V | grep MPM

Якщо ви бачите Server MPM: prefork, перемкніться:

a2dismod mpm_prefork
a2enmod mpm_event
systemctl restart apache2

Ліміти Apache

Для налаштування лімітів Apache відкрийте головний конфігураційний файл:

# Debian/Ubuntu:
nano /etc/apache2/apache2.conf
# або для CentOS/AlmaLinux:
nano /etc/httpd/conf/httpd.conf

Знайдіть або додайте секцію <IfModule mpm_event_module> і задайте параметри під ваш тариф:

<IfModule mpm_event_module>
    StartServers             2
    MinSpareThreads         25
    MaxSpareThreads         75
    ThreadLimit             64
    ThreadsPerChild         25
    MaxRequestWorkers      150
    MaxConnectionsPerChild   0
</IfModule>

Для VPS із 2 ГБ RAM зменште MaxRequestWorkers до 100.

Nginx: базова оптимізація

Відкрийте основний конфігураційний файл Nginx:

nano /etc/nginx/nginx.conf

Перед змінами зробіть резервну копію файлу:

cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.bak

Перевірте або додайте базові параметри:

# Кількість worker-процесів = кількості ядер CPU
worker_processes auto;

events {
    # Максимальна кількість з’єднань на один worker-процес
    worker_connections 2048;

    # Ефективний метод обробки з’єднань для Linux
    use epoll;
}

http {
    # Стиснення відповідей
    gzip on;
    gzip_disable "msie6";
    gzip_types text/plain text/css application/json application/javascript;
    gzip_min_length 1024;

    # Оптимізація передавання статичних файлів
    tcp_nopush on;
    tcp_nodelay on;

    # Кеш відкритих файлів
    open_file_cache max=10000 inactive=30s;
    open_file_cache_valid 60s;
    open_file_cache_min_uses 2;

    # Таймаути та розмір завантажуваних файлів
    keepalive_timeout 30;
    client_max_body_size 64m;
}

Після змін завжди перевіряйте конфігурацію перед перезапуском:

nginx -t && systemctl reload nginx

Оптимізація PHP

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

Перейдіть на PHP-FPM

PHP-FPM (FastCGI Process Manager) працює як окремий сервіс і обробляє PHP-запити ефективніше, ніж вбудований mod_php в Apache.

В ISPmanager 6 це робиться через інтерфейс: Сайти → виберіть сайт → Налаштування → PHP-FPM. У cPanel аналогічне налаштування розташоване в MultiPHP Manager.

Налаштуйте пул PHP-FPM під ваш сервер

nano /etc/php/8.1/fpm/pool.d/www.conf

Для VPS із 2–4 ГБ RAM рекомендується така конфігурація:

; Динамічний режим — створює процеси за потреби
pm = dynamic

; Максимальна кількість дочірніх процесів
pm.max_children = 20

; Стартова кількість процесів під час запуску
pm.start_servers = 5

; Мінімум простоюючих процесів
pm.min_spare_servers = 3

; Максимум простоюючих процесів
pm.max_spare_servers = 7

; Перезапуск процесу після N запитів (боротьба з утечками пам’яті)
pm.max_requests = 500

Після змін перезапустіть PHP-FPM:

systemctl restart php8.1-fpm

Вимкніть невикористовувані розширення PHP

php -m

Ця команда виведе список завантажених модулів. Якщо ви бачите модулі, які точно не потрібні вашому сайту (наприклад, ldap, snmp, xmlrpc), вимкніть їх — кожен модуль займає пам’ять.

ls /etc/php/8.1/fpm/conf.d/

Перейменуйте файл конфігурації непотрібного модуля, додавши суфікс .disabled:

mv /etc/php/8.1/fpm/conf.d/20-ldap.ini /etc/php/8.1/fpm/conf.d/20-ldap.ini.disabled

Керування процесами та автозапуском

Часто на щойно встановленому сервері працюють служби, які ніхто не вмикав навмисно. Кожна служба споживає RAM.

Перевірте список служб, що запускаються автоматично

systemctl list-units --type=service --state=running

Вимкніть те, що не потрібно

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

# Postfix (поштовий сервер) — якщо ви не надсилаєте пошту із сервера напряму
systemctl disable postfix
systemctl stop postfix

# Bluetooth — точно не потрібен на сервері
systemctl disable bluetooth
systemctl stop bluetooth

Висновок

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

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