Как узнать что нагружает сервер

Диагностика ресурсов сервера

Если виртуальный или выделенный сервер не справляется с нагрузкой, сайты открываются медленно, а вместо контента появляются неприветливые ошибки. Всё это раздражает посетителей и они уходят к конкурентам.

Чтобы этого не произошло, нужно следить за параметрами сервера. За какими и как – расскажем в этой статье.

Как посмотреть общую нагрузку на сервер

Отслеживать нагрузку на ОС WIndows позволяет «Диспетчер задач», в Linux свои инструменты.

Самая распространённая утилита мониторинга – top.

Top показывает среднюю нагрузку на сервер (Load Average) в течение 1, 5 и 15 минут. В идеале она должна быть меньше, чем количество ядер процессора. Например, LA 4 при четырёх ядрах означает: каждое ядро загружено на 100% — стоит снизить нагрузку.

Далее последовательно указаны самые «тяжёлые» процессы, сколько они потребляют оперативной памяти и CPU.

Другая утилита – atop – подсвечивает высокую нагрузку красным.

Схожий функционал предоставляет nmon – при нажатии определённых клавиш выдаёт графики нагрузки: процессор (с), чтение/запись диска (d), сеть (n) и память (m) и т. д. Список нужных клавиш будет отражен при запуске программы — в приветственном окне.

Как посмотреть нагрузку детально

Начнём с дисковой памяти — её не покажут перечисленные утилиты.

ISPmanager не открывается, а на сайтах возникает ошибка (например, Unable to connect to the database: Could not connect to MySQL), однако сам сервер доступен и пингуется. Скорее всего, закончилось место на диске, проверить это легко:

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

Также можно освободить место через очистку временных файлов – логов, кеша, php-сессий.

По первой строке можно определить объем доступной пользователю памяти. Для этого сложите параметры free и cached, так как закешированая память также может быть использована приложениями.

Определить, какие процессы занимают память, поможет такой однострочник:

Если на первый взгляд ресурсов сервера хватает, но все равно чувствуются задержки, проверьте сетевой канал.

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

Также показатели трафика на VDS покажет VMmanager.

Если вы используете VMmanager 5, перейдите в раздел «Использование канала». На графиках видно, сколько трафика прошло через сервер за определённый период времени.

Если вы используете VMmanager 6, в разделе «Виртуальные машины» нажмите на ваш сервер и выберите пункт «Статистика».

В этом разделе вы увидите графики нагрузки на разные ресурсы сервера. Трафик будет внизу.

Как увидеть нагрузку через браузер

Есть мониторинги нагрузки, например, Munin:

Если на сервере установлена панель ISPmanager, в ней также можно анализировать нагрузку по процессору, памяти, занимаемому дисковому пространству:

В списке самых прожорливых процессов Apache и Mysql

Если нагрузку создаёт Apache, то на сервер приходит множество запросов по 80, 443 портам. Для снижения нагрузки рекомендуется использовать на сервере Nginx, включить сжатие и кэширование статичных ресурсов.

Возможно, это легитимная посещаемость, поисковые боты или DDOS-атака. В случае поисковых ботов можно сократить время между запросами к серверу в учетной записи Яндекс.Вебмастер и Google Webmasters Tool. В случае атаки настройками не обойтись — необходимо подключить дополнительную защиту.

Ресурсы потребляет Mysql – проведите оптимизацию настроек службы с помощью Mysqltuner.

Также стоит по возможности оптимизировать SQL-запросы к базам данных. Проверьте их через отображения списка текущих операций Mysql — команда show full processlist.

И обратите внимание на показатель WA в top: значение больше 20 говорит о том, что информация не успевает записываться на диск – необходимы диски SSD или NVMe.

Источник

Анализ нагрузки на веб-сервер Linux

В данной статье пойдет речь о мониторинге нагрузки, именно, в контексте веб-сервера. Мы не будем особо заострять внимание на проверке производительности системы, как, например, командами top, htop, free и так далее.

Нагрузка на сервер

Анализ нагрузки стоит начать с общих метрик — потребление процессорного времени, памяти, нагрузки на сеть и дисковую систему.

Нагрузка по процессам

Проверить, нагружен ли сервер, а также понять, какой именно процесс больше всего потребляет ресурсов можно с помощью команд:

* по сути, все 3 вышеперечисленные команды выдают одну и туже информацию в разном виде. Какой-то из них может оказаться удобнее пользоваться. Утилита top встроена в систему, для использования остальных необходимо установить одноименные пакеты.

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

Для определения объема свободной и занимаемой памяти можно воспользоваться командой:

* предыдущие команды тоже показывали утилизацию памяти, но кому-то команда free может показаться нагляднее.

Нагрузка на диск

Для определения нагрузки на дисковую систему, используем утилиту iotop. Сначала ее нужно установить.

а) На системы Debian / Ubuntu:

apt-get install iotop

б) На системы Red Hat / CentOS:

После выполняем следующую команду:

Сетевая активность

Для измерения нагрузки на сеть необходимо установить утилиту nload.

а) В CentOS / Red Hat:

б) В Ubuntu / Debian:

apt-get install nload

После установки, запускаем утилиту командой:

* в данном примере будет запущена статистика для использования сетевого интерфейса eth0.

Что грузит систему

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

Использование lsof

lsof — утилита командной строки, которая отображает какие файлы используются процессами. Она позволит определить, к каким скриптам идет обращение со стороны веб-сервера. Для начала, необходимо установить lsof.

а) В CentOS / Red Hat:

б) В Ubuntu / Debian:

apt-get install lsof

Теперь можно выполнить следующие команды:

* первая команда покажет, к каким файлам обращается apache, вторая — php-fpm (часто можно увидеть в связке с nginx).

Анализ error-логов

Анализ логов ошибок позволит не только обнаружить проблемы в работе сайта, но и найти причину его медленной работы. По умолчанию, логи находятся в каталоге /var/log. Если мы не меняли расположение логов, запускаем следующие команды:

* лог ошибок apache в CentOS.

* лог ошибок apache в Ubuntu.

В первую очередь, нужно обратить внимание на повторяющиеся ошибки — они могут быть причиной проблем. Лучше всего, добиться полного отсутствия ошибок, внеся исправления в работу сайта. Возможно, это устранит проблемы производительности.

Статистика веб-сервера

Для веб-серверов можно воспользоваться служебной страницей просмотра статуса. Она может показать статистику запросов к веб-серверу.

Apache

Для Apache необходим модуль mod_status, который идет в комплекте с данным веб-сервером. Проверить подключение модуля можно в конфигурационном файле httpd.conf (в разных Linux системах может находится в различных каталогах).

По умолчанию, server-status не активен. Создаем конфигурационный файл.

Для CentOS / Red Hat:

Для Ubuntu / Debian:

* где 2 — используемая версия apache.

В открытый конфигурационный файл добавим:

servername 111.111.111.111

Sethandler server-status

* где 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:

В секцию http добавляем:

.
server <
listen 80;
server_name 111.111.111.111;
location /server-status <
stub_status on;
>
>
.

* где 111.111.111.111 — IP-адрес нашего веб-сервера.

Проверяем корректность настройки и перезапускаем nginx:

systemctl restart nginx

Открываем браузер и заходим на страницу 111.111.111.111/server-status. Мы должны увидеть статистику использования сервера:

Теперь настроим статистику для php-fpm. В конфигурационном файле nginx в нашу директиву server добавим:

* обратите внимание на закомментированную строку и строку под ней. В зависимости от того, как настроен php-fpm (слушает на порту или через сокетный файл) необходимо настроить nginx. В данном примере подразумевается, что php-fpm слушает на 9000 порту.

Открываем конфигурационный файл php-fpm:

Снимаем комментарий со следующей строки:

Проверяем настройку nginx, перезапускаем его и php-fpm:

systemctl restart nginx

systemctl restart 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 — путь до лога, куда будет сохранена информация о медленных запросах.

systemctl restart php-fpm

Непрерывный просмотр лога можно запустить командой:

Источник

Анализ нагрузки на сервер

Анализ нагрузки на сервер позволит быстро понять причины медленной работы. Это необходимо делать еще и для того, чтобы вовремя планировать покупку новых серверов.

Аппаратная часть любого сервера состоит из 4 основных компонент:

Анализ загруженности сервера заключается в сборе и обработке статистики каждой из этих компонент.

Процессор

Первым делом следует проверить процессор. Самый быстрый способ – использовать top:

Необходимо обратить внимание на выделенные участки. Загрузка процессора обычно не должна превышать 10…20%. Исключение составляют сервера специального назначения (например, пережиматоры фоток или медиа данных). Следующие показатели наиболее важные для анализа:

mpstat

Более развернутую статистику можно получить используя утилиту mpstat из пакета sysstat:

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

Инструмент htop умеет показывать нагрузку на процессор в удобном виде:

Анализ нагрузки на процессор

Если показатель загрузки процессора (us в top’e) превышает 20%, необходимо оценить возможность оптимизации приложения. Если возможная оптимизация уже была выполнена, необходимо приобретать дополнительные сервера.

В случае высокого показателя ожидания I/O (wa в top’e), необходимо провести дальнейший анализ дисковой и сетевой подсистемы (ниже).

Память

Прежде всего необходимо определить количество занятой и свободной памяти:

Покажет данные об использовании памяти:

## Результат команды free

Важно обратить внимание на значение free. Это количество свободной памяти. Очень важным показателем является Swap. Это используемое место на диске в том случае, когда оперативной памяти перестает хватать.

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

Среди прочего увидим такие сведения:

Анализ использования памяти

Малое количество свободной оперативной памяти не является проблемой. Но такая ситуация является предлогом для пристального наблюдения за сервером.

В случае же, если начинает расти Swap, необходимо срочно принимать меры:

Старайтесь всегда удерживать используемый своп нулевым.

Диски

Дисковая подсистема может быть нагружена, когда приложение работает с файлами. Кроме этого, диски может нагружать работа с базой данных.

Начать анализ дисков следует с проверки свободного места:

Покажет результат по всем разделам:

Колонка Use покажет занятое место. Для основных разделов старайтесь удерживать значение не выше 90%.

iotop

Инструмент iotop умеет показывать развернутую загрузку диска.

Также будет видно распределение по процессам, которые работают с диском:

В примере два процесса – mysqld и php-fpm (это php приложение) – используют операции записи на диск. Необходимо обратить внимание на показатели:

Анализ

Чтение

Если диск подвержен большому количеству чтений, правильными вариантами поведения будут:

Запись

Большое количество записей на диск обычно свидетельствуют о необходимости масштабироваться.

Утилита cbm позволяет увидеть сетевой трафик в реальном времени:

Увидим данные об объеме приема и передачи в секунду:

Высокий сетевой трафик сам по себе не является проблемой. Но близкие к пиковым показатели указывают на необходимость масштабироваться в ближайшем будущем. Например, средний трафик в 95 Мбит на интерфейсе в 100 Мбит скорее всего будет означать, что текущего сервера вскоре будет недостаточно.

Общая статистика

Удобная утилита dstat покажет общую статистику сервера в реальном времени:

Увидим данные о системе с интервалом в одну секунду:

Внимание следует обратить на:

Самое важное

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

Улучшение производительности Web сервера на Ubuntu

Источник

Нагрузка на сервер: определение причин

Виртуальная машина не всегда работает с ожидаемой скоростью. Сайт внезапно начинает тормозить, скрипты выполняются долго. В этой статье мы покажем каким образом можно анализировать производительность виртуальной машины и находить причины замедлений в работе.

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

Команда top

Главным инструментом в этом деле станет команда top. Результат её выполнения выглядит так:

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

Рассмотрим основные показатели, которые могут нас заинтересовать.

Средняя нагрузка на систему (load average)

Load Average — среднее значение загруженности системы за период времени (в дальнейшем LA). Три значения показывают усреднённую нагрузку за последние 1, 5 и 15 минут. LA является одним из самых спорных показателей. Можно найти множество противоречивых статей, какое значение считать нормальным. Обычно принимается, что значение 0 это простой ядра, а значение 1 это полная нагрузка ядра. Оценить показатель средней нагрузки можно только зная количество ядер в системе. Узнать сколько ядер доступно можно командой:

Видим, что на данной системе находится 12 физических ядер (6+6). Соответственно, нормальный показатель LA должен быть менее 12. Однако, на процессорах Intel используется технология Hyper-Threading, которая делит одно физическое ядро на два логических.

Соответственно, в данном случае в системе может быть одновременно 24 виртуальных процессора (потока).

Технология Turbo Boost позволяет процессору «разгоняться» и работать на частоте выше заявленной (т.е. выше 100%, выше единицы). Какой показатель LA считать нормальным в данном случае является предметом споров.

Параметр Cpu

Строка Cpu показывает сразу несколько параметров нагрузки:

Не будем углубляться в анализ значений hi и si в этой статье, поскольку проблемы с прерываниями встречаются очень редко. Скажем только, что наиболее вероятная причина высоких значений данных параметров — проблема с кодом, ядром или DDoS-атака.

Нагрузка на процессор (параметры sy, us, ni)

Однако надо учитывать, что однопоточные процессы будут выполнятся только на одном ядре. В этом случае даже при невысоком общем us могут наблюдаться проблемы.

Также нужно добавить, что высокое значение ni не всегда будет отрицательно влиять на работоспособность сервера. Возможно, приоритет процессов был понижен специально, чтобы они выполнялись только в том случае, когда процессор будет свободен. Данные процессы не оказывают влияния на работу системы. Например, это могут быть процессы создания бекапов.

Пример диагностики проблем при высоком us и sy

На сервере top показывает следующие значения:

При этом LA больше 100.

По результату анализа логов можно сделать вывод, что проблема в китайских ботах, которые постят рекламу в комментарии на сайте. Ставим капчу на комментирование или отключаем комментарии, чистим БД. Проблема решена.

Определение оверселлинга (параметр st)

Параметр st интересен для виртуальных машин. Можно сказать, что он отображает оверселлинг CPU на родительской ноде. Он будет отличаться от 0 в случае, если VDS требуется процессор, но гипервизор не может выделить CPU, так как он используется в данный момент другими VDS. В случае, если данный параметр принимает большие значения на вашей VDS (ориентировочно более 5-10% совместно с высоким LA) и это мешает вашей работе, то остается только написать в техподдержку с просьбой перенести VDS на другую ноду.

Нагрузка ввода-вывода (параметр wa)

Упрощенная модель состояний в Linux

Посмотреть состояние процессов в системе можно с помощью команды ps с опциями: ps aux

По практическому опыту, заметные проблемы начинаются при wa больше 10-30%. Нужно понимать, что большое значение этого параметра не всегда свидетельствует о проблемах. Но желательно установить причину такого поведения и по возможности исправить ситуацию.

Пример нахождения причин высокого wa и load average

Смотрим командой ps aux | grep D процессы в состоянии D.

Нужно знать, что высокий wa внутри VDS, не всегда означает проблемы внутри контейнера. Проблемы также возможны на «родительской» ноде. Например, на ней не хватает I/O диска для всех VDS. Поэтому ваши процессы попадают в состояние ожидания. В таком случае нужно создать тикет в тех поддержку.

Нагрузка ввода-вывода: копаем глубже (atop)

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

Рассмотрим его вывод:

В строке DSK мы видим использование диска в данный момент. В строке busy в процентах указывается примерно сколько «ресурсов» диска потребляется в данный момент. Если там будет значение около 100% значит на диске, скорее всего, наблюдаются проблемы с операциями ввода/вывода. В случае использования VDS, данной строки может не быть и пугаться не стоит.

В нижней части видим список процессов, которые в данный момент выполняют дисковые операции. Вверху списка будут процессы, потребляющие больше всего ресурсов.

Как мы видим, процесс с идентификатором pid 539189 в данный момент ведет активную запись на диск. Узнать в какие файлы пишет данные этот процесс можно с помощью команды lsof.

Видно, что данный процесс mysql пишет временные файлы на жесткий диск и этим создает нагрузку. Поэтому желательно провести его оптимизацию.

Более подробно проанализировать нагрузку на дисковую систему можно также с помощью специализированной утилиты iotop.

Заключение

В данной статье мы рассказали о малой части средств для мониторинга нагрузки на серверах. И даже в них мы охватили минимум возможностей. Для более полного знакомства с возможностями описанных утилит, читайте документацию (ссылки в статье на названиях команд). Но даже описанных в статье возможностей хватает для диагностики большинства возникающих проблем.

Источник