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

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

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

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

Команда 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 считать нормальным в данном случае является предметом споров.

Были попытки вычислить нормальное значение LA эмпирическим путем. Но мы считаем это бессмысленным занятием. Дело в том, что в LA попадают также процессы, стоящие в очереди чтения/записи и не имеющие отношение к процессору, а также процессы с приоритетом, измененным с помощью команды nice . В случае если команда запущенна с низким приоритетом, она будет находится в очереди, но не будет оказывать влияния на реальную производительность.

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

Параметр Cpu

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

us (user) Использование процессора пользовательским процессами sy (system) Использование процессора системным процессами ni (nice) Использование процессора процессами с измененным приоритетом с помощью команды nice id (idle) Простой процессора. Можно сказать, что это свободные ресурсы wa (IO-wait) Говорит о простое, связанным с вводом/выводом hi (hardware interrupts) Показывает сколько процессорного времени было потрачено на обслуживание аппаратного прерывания si (software interrupts) Показывает сколько процессорного времени было потрачено на обслуживание софтверного прерывания st (stolen by the hypervisor) Показывает сколько процессорного времени было «украдено» гипервизором

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

Рассмотрим подробнее остальные параметры Сpu .

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

Высокие значения sy , us и ni самые понятные и простые для диагностики, поскольку показывают нагрузку на CPU, создаваемую запущенными программами. Смотрим в выводе команды top процессы по столбцу %CPU и оптимизируем их при необходимости. Либо просто добавляем мощность CPU на сервер.

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

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

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

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

Явно видно, что проблемы в нехватке CPU для работы mysql , и в большом количестве http -соединений пользователя frekbok .

Заходим к пользователю frekbok и смотрим лог apache . Там видим такие POST -запросы, и множество им подобных:

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

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

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

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

Самый интересный показатель это wa . На современных серверах мощности процессора и памяти обычно хватает, а большинство проблем связаны с операциями ввода/вывода.

Высокие значения wa , а также высокий LA, обычно говорят о простое процессов в состоянии D-state , связанном с дисковой подсистемой или с сетевыми проблемами. Однако, нельзя забывать, что этот параметр относится ко всем операциям ввода/вывода. Например, на выделенном сервере это значение может вырасти при работе с USB-накопителем, ожидании ответа от сокета или быть вызвано другими причинами.

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

• D-state — состояние непрерывного сна (процессы, которые ожидают освобождения потока ввода-вывода)
• R-state — процесс активен в настоящее время (выполняется в данный момент)
• S-state — состоянии ожидания (sleeping), т.е. он ожидает какого-то события или сигнала
• Т-state — процесс приостановлен сигналом STOP или выполнением трассировки
• Z-state — «зомби», процесс, завершивший свое выполнение, но присутствующий в системе, чтобы дать родительскому процессу считать свой код завершения

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

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

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

Видим, что в состоянии ожидания висит множество процессов exim4 . Скорее всего сервер был взломан и с него массово рассылают спам. Останавливаем exim и находим источник рассылки.

В случае, если у вас несколько VDS на ноде и необходимо найти источник нагрузки, нужно найти ту, с которой рассылается спам. Для этого можно использовать команду tcpdump -n | grep "smtp" , с помощью неё мы проанализируем почтовый трафик на порту 25, и обнаружим IP-адрес с которого выполняется рассылка спама.

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

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

Удобный инструмент для определения причин нагрузки — это atop c опциями: atop -l -c -d1

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

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

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

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

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

Вызов команды lsof -p539189 (подставляем pid-идентификатор нужного процесса) показал такой результат:

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

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

Заключение

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