6.4.11 Оптимизация производительности на VPS/VDS и выделенных серверах

Banner The Host server-performance-optimization

Когда посетитель открывает ваш сайт, браузер отправляет запрос на сервер. Сервер обрабатывает его и отдаёт страницу. Чем быстрее сервер справляется с этим процессом — тем выше производительность.

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

Три главных ресурса сервера, за которыми нужно следить:

Ресурс Что делает Признак нехватки
CPU (процессор) Выполняет вычисления Высокий load average, тормоза PHP
RAM (память) Хранит данные «на лету» Своп активен, OOM killer убивает процессы
Disk I/O (диск) Читает/пишет файлы и БД Долгие запросы к MySQL, медленная загрузка файлов

Важно: Статья рассчитана прежде всего на серверы без панели управления. Если на сервере используется ISPmanager, cPanel или другая панель, не меняйте конфигурации Apache, Nginx, PHP-FPM и системных служб напрямую без проверки документации панели. Панель может хранить собственные шаблоны конфигурации, перезаписывать файлы при обновлениях и зависеть от служб, которые кажутся лишними. Как безопаснее: сначала проверьте, есть ли нужная настройка в интерфейсе панели или в её штатных шаблонах. Перед ручной правкой сделайте резервную копию файла конфигурации и сохраните команду для отката.

Частые ошибки новичков

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

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. Увеличить объём дискового пространства — если данные удалить нельзя или проекту действительно требуется больше места, необходимо расширить диск/тариф или подключить дополнительное хранилище.

Перед удалением файлов важно сначала определить, что именно занимает место на диске.

Обратите внимание: подробная инструкция по поиску крупных файлов и директорий по SSH описана в отдельной статье:
Как узнать, что занимает место на диске через SSH

Проверьте скорость работы дисковой подсистемы

Иногда проблема связана не с тем, что место на диске закончилось, а с тем, что диск слишком медленно обрабатывает операции чтения и записи.

Если в 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, логи, кэширование или расписание фоновых задач.

Примечание: если вы хотите подробнее разобраться, как анализировать нагрузку сервера через SSH, используйте отдельную инструкцию.

Резервное копирование файлов конфигурации

Перед изменением конфигурации сохраните копию исходного файла. Это позволит быстро откатить правку, если сервис не запустится после перезапуска или панель управления начнёт работать некорректно.

# 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

Важно: если вы используете mod_php (а не PHP-FPM), переключение на Event может вызвать ошибки. Сначала уточните в документации вашей панели управления.

Лимиты 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

Важно: не переносите параметры в конфигурацию без проверки контекста.

Директивы worker_processes, events, gzip, tcp_nopush и open_file_cache относятся к разным уровням конфигурации Nginx. Если разместить их не в том блоке, Nginx не применит настройки или не запустится после перезагрузки. Перед изменениями сделайте резервную копию конфигурации и обязательно выполните nginx -t.

Обратите внимание: Оптимизацию баз данных лучше выполнять после диагностики веб-сервера и PHP. Иначе можно изменить параметры MySQL без понимания, создаёт ли нагрузку именно база данных. Ознакомиться с рекомендациями и практическими подходами по оптимизации Баз данных, можете ознакомиться в нашей статье.

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

Производительность PHP напрямую влияет на скорость загрузки сайта и нагрузку на сервер. Если PHP работает в неэффективном режиме, потребляет слишком много памяти или использует лишние расширения, даже простой сайт может создавать повышенную нагрузку на CPU и RAM. Ниже приведены базовые шаги, которые помогут снизить потребление ресурсов, ускорить обработку запросов и сделать работу сайта стабильнее.

Переключитесь на PHP-FPM

PHP-FPM (FastCGI Process Manager) работает как отдельный сервис и обрабатывает PHP-запросы эффективнее, чем встроенный mod_php в Apache.

В ISPmanager 6 это делается через интерфейс: Сайты → выберите сайт → Настройки → PHP-FPM. В cPanel аналогичная настройка находится в MultiPHP Manager.

Важно: в ISPmanager 4 может не быть штатной настройки PHP-FPM в интерфейсе панели.

Не пытайтесь переносить инструкцию для ISPmanager 6 напрямую: ручное изменение конфигурации PHP, Apache или Nginx может нарушить работу сайтов и самой панели. Перед правками проверьте текущий режим обработки PHP, сделайте резервные копии конфигурационных файлов и используйте документацию именно для вашей версии ISPmanager.

Настройте пул 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

Дополнительно: для корректной и полной оптимизации работы PHP на сервере важно не только настроить режим обработки PHP и пул PHP-FPM, но и правильно задать параметры в конфигурационном файле php.ini.

Через php.ini настраиваются лимиты памяти, максимальное время выполнения скриптов, размер загружаемых файлов, параметры загрузки модулей, обработка ошибок и другие важные настройки, которые напрямую влияют на стабильность и производительность сайта.

Подробная инструкция по настройке PHP через php.ini описана в статье:
Настройка PHP.INI

Управление процессами и автозапуском

Часто на свежеустановленном сервере работают службы, которые никто не включал намеренно. Каждая служба потребляет RAM.

Проверьте список автозапускаемых служб

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

Отключите то, что не нужно

Примеры служб, которые новички часто не замечают, но которые занимают ресурсы:

# Postfix (почтовый сервер) — если вы не отправляете почту с сервера напрямую
systemctl disable postfix
systemctl stop postfix

# Bluetooth — точно не нужен на сервере
systemctl disable bluetooth
systemctl stop bluetooth

Будьте осторожны: не отключайте службы, назначение которых вам неизвестно. Если сомневаетесь — лучше не трогать.

Заключение

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

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