Анализ нагрузки на веб-сервер Linux
Обновлено: 29.01.2021 Опубликовано: 12.09.2018
В данной статье пойдет речь о мониторинге нагрузки, именно, в контексте веб-сервера. Мы не будем особо заострять внимание на проверке производительности системы, как, например, командами top, htop, free и так далее.
Нагрузка на сервер
Анализ нагрузки стоит начать с общих метрик — потребление процессорного времени, памяти, нагрузки на сеть и дисковую систему.
Нагрузка по процессам
Проверить, нагружен ли сервер, а также понять, какой именно процесс больше всего потребляет ресурсов можно с помощью команд:
* по сути, все 3 вышеперечисленные команды выдают одну и туже информацию в разном виде. Какой-то из них может оказаться удобнее пользоваться. Утилита top встроена в систему, для использования остальных необходимо установить одноименные пакеты.
Оперативная память
Для определения объема свободной и занимаемой памяти можно воспользоваться командой:
* предыдущие команды тоже показывали утилизацию памяти, но кому-то команда free может показаться нагляднее.
Нагрузка на диск
Для определения нагрузки на дисковую систему, используем утилиту iotop. Сначала ее нужно установить.
а) На системы Debian / Ubuntu:
б) На системы Red Hat / CentOS:
После выполняем следующую команду:
Сетевая активность
Для измерения нагрузки на сеть необходимо установить утилиту nload.
а) В CentOS / Red Hat:
б) В Ubuntu / Debian:
После установки, запускаем утилиту командой:
* в данном примере будет запущена статистика для использования сетевого интерфейса eth0.
Что грузит систему
Даже, если мы увидим, что на веб-сервере заканчивается оперативная память или загружен процессор, мы не сможем найти источник проблемы, которым, чаще всего, является некорректно работающий скрипт. Поэтому, определяем, какой файл на сервере вызывает нагрузку.
Использование lsof
lsof — утилита командной строки, которая отображает какие файлы используются процессами. Она позволит определить, к каким скриптам идет обращение со стороны веб-сервера. Для начала, необходимо установить lsof.
а) В CentOS / Red Hat:
б) В Ubuntu / Debian:
Теперь можно выполнить следующие команды:
* первая команда покажет, к каким файлам обращается apache, вторая — php-fpm (часто можно увидеть в связке с nginx).
Анализ error-логов
Анализ логов ошибок позволит не только обнаружить проблемы в работе сайта, но и найти причину его медленной работы. По умолчанию, логи находятся в каталоге /var/log. Если мы не меняли расположение логов, запускаем следующие команды:
tail -f /var/log/nginx/error.log
tail -f /var/log/php-fpm/error.log
tail -f /var/log/httpd/error_log
* лог ошибок apache в CentOS.
tail -f /var/log/apache2/error_log
* лог ошибок apache в Ubuntu.
В первую очередь, нужно обратить внимание на повторяющиеся ошибки — они могут быть причиной проблем. Лучше всего, добиться полного отсутствия ошибок, внеся исправления в работу сайта. Возможно, это устранит проблемы производительности.
Статистика веб-сервера
Для веб-серверов можно воспользоваться служебной страницей просмотра статуса. Она может показать статистику запросов к веб-серверу.
Apache
Для Apache необходим модуль mod_status, который идет в комплекте с данным веб-сервером. Проверить подключение модуля можно в конфигурационном файле httpd.conf (в разных Linux системах может находится в различных каталогах).
По умолчанию, server-status не активен. Создаем конфигурационный файл.
Для CentOS / Red Hat:
Для Ubuntu / Debian:
* где 2 — используемая версия apache.
В открытый конфигурационный файл добавим:
* где 111.111.111.111 — IP-адрес нашего веб-сервера; 80 — порт, на котором слушает apache.
* в данном примере мы прописали два варианта просмотра статистики: первый — обращение в браузере к серверу по IP-адресу + /server-status; второй — обращение к любому сайту + /server-status. Разные способы оправданы для разных настроек самих сайтов и используемых CMS.
Проверим корректность внесенных данных и перезапустим веб-сервер apache:
systemctl restart httpd || systemctl restart apache2
Теперь открываем браузер и вводим название сайта + /server-status, например, http://www.dmosk.ru/server-status. Или обращаемся к серверу по IP-адресу, например, http://111.111.111.111/server-status.
NGINX + PHP-FPM
Открываем конфигурационный файл nginx:
.
server listen 80;
server_name 111.111.111.111;
location /server-status stub_status on;
>
>
.
* где 111.111.111.111 — IP-адрес нашего веб-сервера.
Проверяем корректность настройки и перезапускаем nginx:
Открываем браузер и заходим на страницу 111.111.111.111/server-status. Мы должны увидеть статистику использования сервера:
Теперь настроим статистику для php-fpm. В конфигурационном файле nginx в нашу директиву server добавим:
.
server listen 80;
server_name 78.110.63.31;
location /server-status stub_status on;
>
location /status access_log off;
include fastcgi_params;
#fastcgi_pass unix:/var/run/php-fpm/php5-fpm.sock;
fastcgi_pass 127.0.0.1:9000;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
>
>
.
* обратите внимание на закомментированную строку и строку под ней. В зависимости от того, как настроен php-fpm (слушает на порту или через сокетный файл) необходимо настроить nginx. В данном примере подразумевается, что php-fpm слушает на 9000 порту.
Открываем конфигурационный файл php-fpm:
Снимаем комментарий со следующей строки:
Проверяем настройку nginx, перезапускаем его и php-fpm:
Открываем браузер и заходим на страницу 111.111.111.111/server-status. Мы должны увидеть статистику использования сервера:
Долгие запросы
С помощью длительных запросов к веб-серверу или СУБД можно сделать выводы о том, что является узким местом в работе сервиса.
MySQL / MariDB
Для начала, воспользуемся инструкцией, чтобы настроить ведение лога медленных запросов (для MySQL или MariaDB).
После, воспользовавшись статистикой, находим неоптимальные запросы. В одних случаях необходимо будет переписать сам запрос, в других — создать индексы базы данных.
PHP-FPM
Открываем конфигурационный файл:
Редактируем следующие параметры:
request_slowlog_timeout = 10s
slowlog = /var/log/php-fpm/www-slow.log
* request_slowlog_timeout определяет время, в течение которого должен выполняться запрос, чтобы он считался медленным; slowlog — путь до лога, куда будет сохранена информация о медленных запросах.
Непрерывный просмотр лога можно запустить командой:
tail -f /var/log/php-fpm/www-slow.log