Утилита top linux load average

CPU Load: когда начинать волноваться?

Данная заметка является переводом статьи из блога компании Scout. В статье дается простое и наглядное объяснение такого понятия, как load average . Статья ориентирована на начинающих Linux-администраторов, но, возможно, будет полезна и более опытным админам. Заинтересовавшимся добро пожаловать под кат.

Вероятно, Вы уже знакомы с понятием load average . Load average — это три числа, отображаемые при выполнении команд top и uptime . Выглядят они примерно так:

Большинство интуитивно понимают, что эти три числа обозначают средние значения загрузки процессора на прогрессивно увеличивающихся временных промежутках (одна, пять и пятнадцать минут) и чем меньше их значения — тем лучше. Большие числа свидетельствуют о слишком большой нагрузке на сервер. Но какие значения считать предельными? Какие значения являются «плохими», а какие — «хорошими»? Когда Вам следует просто волноваться о занчениях средней загрузки, а когда следует бросать другие дела и решать проблему так быстро, как это возможно?
Для начала, давайте разберемся, что же означает load average . Рассмотрим простейший случай: предположим, что у нас в наличии один сервер с одноядерным процессором.

Аналогия транспортного потока

Одноядерный процессор похож на дорогу с одной полосой движения. Представьте себе, что Вы управяете движением машин по мосту. Иногда, Ваш мост загружен настолько сильно, что машинам приходится ждать в очереди чтобы проехать по нему. Вы хотите дать людям понять, как долго им придется ждать чтобы перебраться на другую сторону реки. Хорошим способом сделать это будет показать как много машин ждут в очереди в конкретный момент времени. Если машин в очереди нет, подъезжающие водители будут знать, что они сразу смогут проехать по мосту. В противном случае, они будут понимать, что придется ждать своей очереди.
Итак, Управляющий Мостом, какую систему обозначений Вы будете использовать? Как насчет такой:

• 0.00 означает, что на мосту нет ни одной машины. Фактически, значения от 0.00 до 1.00 означают отсутствие очереди. Подъезжающая машина может воспользоваться мостом без ожидания;
• 1.00 означает, что на мосту находится как раз столько автомобилей, сколько он может вместить. Все еще идет хорошо, но, в случае увеличения потока машин, возможны проблемы;
• Значения, превышающие 1.00 означают наличие очереди на въезде. Насколько большой? Например, значение 2.00 показывает, что в очереди стоит столько же автомобилей, сколько движется по мосту. 3.00 означает, что мост полностью занят и в очереди ожидает в два раза больше машин, чем он может вместить. И так далее.

load average = 1.00
load average = 0.50
load average = 1.70
Вот базовое значение загрузки процессора. «Машины» обрабатываются с использованием промежутков процессорного времени («пересекают мост»), либо ставятся в очередь. В Unix это называется длина очереди выполнения: количество всех процессов, выполняемых в данный момент времени, плюс количество процессов, ожидающих в очереди.
Вам, как управляющему мостом, хотелось бы, чтобы машины-процессы никогда не ждали в очереди. Таким образом, предпочтительно, чтобы загрузки процессора была всегда ниже 1.00. Периодически возможны всплески трафика, когда загрузка будет превышать 1.00, но если она постоянно превышает данное значение — это повод начать волноваться.

Так Вы говорите, 1.00 — идеальное значание load average?

Что насчет многопроцессорных систем? Мой сервер показывает загрузку 3.00 и все ОК!

У Вас четырехпроцессорная система? Все в порядке, если load average равен 3.00.
В мультипроцессорных системах загрузка вычисляется относительно количества доступных процессорных ядер. 100% загрузка обозначается числом 1.00 для одноядерной машины, числом 2.00 для двуядерной, 4.00 для четырехъядерной и т.д.
Если вернуться к нашей аналогии с мостом, 1.00 означает «одну полностью загруженную полосу движения». Если на мосту всего одна полоса, 1.00 означает, что мост загружен на 100%, если же в наличии две полосы, он загружен всего на 50%.
То же самое с процессорами. 1.00 означает 100% загрузки одноядерного процессора. 2.00 — 100% загрузки двуядерного и т.д.

Многоядерность vs. многопроцессорность

Сведем все вместе

Давайте посмотрим на средние значения загрузки с помощью команды uptime :

Здесь представлены показатели для системы с четырехъядерным процессором и мы видим, что имеется большой запас по нагрузке. Я даже не буду задумываться о ней, пока load average не превысит 3.70.

Какое среднее значение мне следует контролировать? Для одной, пяти или 15 минут?

Количество ядер важно для правильно понимания load average. Как мне его узнать?

Команда cat /proc/cpuinfo выводит информацию обо всех процессорах в вашей системе. Чтобы узнать количество ядер, «скормите» ее вывод утилите grep :

Примечания переводчика

Выше представлен перевод самой статьи. Также много интересной информации можно почерпнуть из комментариев к ней. Так, один из комментаторов говорит о том, что не для каждой системы важно иметь запас по производтельности и не допускать значения загрузки выше 0.70 — иногда нам нужно чтобы сервер работал «на всю катушку» и в таких случаях load average = 1.00 — то, что доктор прописал.

Хабраюзер dukelion добавил в комментариях ценное замечание, что в некоторых сценариях, для достижения максимального КПД «железа», стоит держать значение load average несколько выше 1.00 в ущерб эффективности работы каждого отдельного процесса.

Хабраюзер enemo в комментариях добавил замечание о том, что высокий показатель load average может быть вызван большим количеством процессов, выполняющих в данный момент операции чтения/записи. То есть, load average > 1.00 на одноядерной машине не всегда говорит о том, что в Вашей системе отсутствует запас по загрузке процессора. Требуется более внимательное изучение причин такого показателя. Кстати, это хорошая тема для нового поста на Хабре 🙂

Источник

Understand Linux Load Averages and Monitor Performance of Linux

In this article, we will explain one of the critical Linux system administration tasks – performance monitoring in regards to system/CPU load and load averages.

Before we move any further, let’s understand these two important phrases in all Unix-like systems:

• System load/CPU Load – is a measurement of CPU over or under-utilization in a Linux system; the number of processes which are being executed by the CPU or in waiting state.
• Load average – is the average system load calculated over a given period of time of 1, 5 and 15 minutes.

In Linux, the load-average is technically believed to be a running average of processes in it’s (kernel) execution queue tagged as running or uninterruptible.

Note that:

• All if not most systems powered by Linux or other Unix-like systems will possibly show the load average values somewhere for a user.
• A downright idle Linux system may have a load average of zero, excluding the idle process.
• Nearly all Unix-like systems count only processes in the running or waiting states. But this is not the case with Linux, it includes processes in uninterruptible sleep states; those waiting for other system resources like disk I/O etc.

How to Monitor Linux System Load Average

There are numerous ways of monitoring system load average including uptime which shows how long the system has been running, number of users together with load averages:

The numbers are read from left to right, and the output above means that:

• load average over the last 1 minute is 1.98
• load average over the last 5 minutes is 2.15
• load average over the last 15 minutes is 2.21

High load averages imply that a system is overloaded; many processes are waiting for CPU time.

We will uncover this in the next section in relation to number of CPU cores. Additionally, we can as well use other well known tools such as top and glances which display a real-time state of a running Linux system, plus many other tools:

Top Command

Glances Tool

The load averages shown by these tools is read /proc/loadavg file, which you can view using the cat command as below:

On desktop machines, there are graphical user interface tools that we can use to view system load averages.

Understanding System Average Load in Relation Number of CPUs

We can’t possibly explain system load or system performance without shedding light on the impact of the number of CPU cores on performance.

Multi-processor Vs Multi-core

• Multi-processor – is where two or more physical CPU’s are integrated into a single computer system.
• Multi-core processor – is a single physical CPU which has at least two or more separate cores (or what we can also refer to as processing units) that work in parallel. Meaning a dual-core has 2 two processing units, a quad-core has 4 processing units and so on.

Furthermore, there is also a processor technology which was first introduced by Intel to improve parallel computing, referred to as hyper threading.

Under hyper threading, a single physical CPU core appears as two logical CPUs core to an operating system (but in reality, there is one physical hardware component).

Note that a single CPU core can only carry out one task at a time, thus technologies such as multiple CPUs/processors, multi-core CPUs and hyper-threading were brought to life.

With more than one CPU, several programs can be executed simultaneously. Present-day Intel CPUs use a combination of both multiple cores and hyper-threading technology.

To find the number of processing units available on a system, we may use the nproc or lscpu commands as follows:

Another way to find the number of processing units using grep command as shown.

Now, to further understand system load, we will take a few assumptions. Let’s say we have load averages below:

On a single core system this would mean:

• The CPU was fully (100%) utilized on average; 1 processes was running on the CPU (1.00) over the last 1 minute.
• The CPU was idle by 60% on average; no processes were waiting for CPU time (0.40) over the last 5 minutes.
• The CPU was overloaded by 235% on average; 2.35 processes were waiting for CPU time (3.35) over the last 15 minutes.

On a dual-core system this would mean:

• The one CPU was 100% idle on average, one CPU was being used; no processes were waiting for CPU time(1.00) over the last 1 minute.
• The CPUs were idle by 160% on average; no processes were waiting for CPU time. (0.40) over the last 5 minutes.
• The CPUs were overloaded by 135% on average; 1.35 processes were waiting for CPU time. (3.35) over the last 15 minutes.

You might also like:

In conclusion, if you are a system administrator then high load averages are real to worry about. When they are high, above the number of CPU cores, it signifies high demand for the CPUs, and low load averages below the number of CPU cores tells us that CPUs are underutilized.

If You Appreciate What We Do Here On TecMint, You Should Consider:

TecMint is the fastest growing and most trusted community site for any kind of Linux Articles, Guides and Books on the web. Millions of people visit TecMint! to search or browse the thousands of published articles available FREELY to all.

If you like what you are reading, please consider buying us a coffee ( or 2 ) as a token of appreciation.

We are thankful for your never ending support.

Источник

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

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

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

Постараемся ответить на вопрос: что делать в случае проблем на сервере, какие инструменты использовать и на что обращать внимание для диагностирования проблем производительности в операционной системе 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 не всегда будет отрицательно влиять на работоспособность сервера. Возможно, приоритет процессов был понижен специально, чтобы они выполнялись только в том случае, когда процессор будет свободен. Данные процессы не оказывают влияния на работу системы. Например, это могут быть процессы создания бекапов.

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

На сервере 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%. Нужно понимать, что большое значение этого параметра не всегда свидетельствует о проблемах. Но желательно установить причину такого поведения и по возможности исправить ситуацию.

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

Смотрим командой 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.

Заключение

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

Источник