ХостТрекер
Компания
58,33
рейтинг
25 апреля 2014 в 07:48

Разное → Практические рекомендации: устраняйте неполадки, используя команду 'Top' в Linux перевод

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

Load average может представлять собой непростой для понимания показатель производительности сервера. В этой статье мы попытаемся дать некоторое представление о том, что означают те величины, которые можно найти в выводе команды «top» и в других linux-командах. В статье, также объясняются параметры специфичные для виртуального хостинга, которые обычно не отображается в стандартном выводе команды top.

Вывод команды «top»

Если в коммандной строке линукс системы вы наберете команду top, то получите табличку со следующим заголовком:



Давайте разберем значение каждой из строк.

top – 17:15:19 up 32 days, 18:24, 6 users
Здесь показана команда и текущее системное время; «время бесперебойной работы», в нашем случае это 32 дня, 18 часов и 24 минуты; наконец, указывается количество зарегистрированных в системе пользователей; в данном примере, в системе зарегистрированы 6 пользователей. Они могут быть подключены по SSH, локально, быть неактивными и т.д.

load average: 0,00, 0,01, 0,05
В этой части показывается средняя нагрузка; она может сбивать с толку, особенно на виртуальной машине/в облаке.
Первая цифра показывает среднюю нагрузку «последней минуты», или «текущую» среднюю нагрузку; вторая цифра показывает «среднюю нагрузку за 5 минут», последняя цифра – «среднюю нагрузку за 15 минут».
Средняя нагрузка – мера среднего числа процессов, ожидающих своей очереди, чтобы совершить какое-либо действие в процессоре. Как и в супермаркете, приходится стоять в очереди, дожидаясь, пока кассир уделит вам все свое внимание. Причина, по которой средняя нагрузка растет, заключается в остальной статистике и счетчиках, находящихся ниже этой линии, поэтому, если ориентироваться строго на значения средней нагрузки, можно не увидеть всей картинки полностью.

Вот пример, взятый из узла distcc:

Данный сервер, кроме того, что является средой промежуточной обработки для скриптов и хостингом инструментов командной строки облака, предоставляет также распределенную службу C компилятора различным машинам, находящимся в нашей сети, поскольку она имеет 8 процессоров, 32 ГБ оперативной памяти и тонну псевдодискового пространства. При нормальной нагрузке, среднее ее значение остается относительно низким; при выполнении java-скриптов нагрузка может вырастать в два и более раза. Однако при выполнении службы компилятора при полной нагрузке (10 выполняемых процессов при загрузке процессора, равной 95% или выше), среднее значение нагрузки составляет 0,75… Как же так получается? Попытаемся разобраться

Строка Tasks

Tasks: 119 total, 1 running, 118 sleeping, 0 stopped, 0 zombie
Tasks: показывает количество процессов, когда вы набираете, например, “ps aux”.
total Общее количество задач полезно знать для выявления вышедшего из-под контроля сервера apache или экземпляра postgresql, но оно обычно остается достаточно стабильным.
running Количество запущенных процессов показывает вам, как в настоящее время используется ваш процессор. Приложения, не имеющие многопоточности, за один раз, как правило, могут использовать 1 процессор, поэтому обычным делом является ситуация, когда 1 процесс использует 25% процессора четырехъядерного сервера со средней нагрузкой ~1.
sleeping Количество ждущих процессов показывает, какие процессы выполняются, но не являются активными; обычно это фоновые задачи, системное ПО, драйвера принтера и т.д.
stopped Количество остановленных процессов должно, как правило, равняться 0, если вы не послали процессу сигнал a SIGSTOP или kill -STOP для устранения неисправностей. Если это число отличается от 0, то, в случае с рабочими серверами это может служить поводом для беспокойства.
zombie Зависшие процессы. Это означает, что многопоточное приложение запустило дочерний процесс, а затем было уничтожено или неожиданно завершено, оставив после себя повисший процесс, известный, как zombie-процесс. Apache может наплодить целую кучу таких процессов в случае, если происходит что-то из ряда вон выходящее. Обычно, их число тоже должно равняться 0.

Строка Cpu

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

Cpu(s): 0.0%us, 0.0%sy, 0.0%ni, 99.9%id,
Первые четыре величины, приведенные здесь, присутствуют на всех серверах с linux, и они привычны для большинства людей.
%us показывает использование отдельного процессора (пользовательскими процессами, такими, как apache, mysql и т.д.) до максимального значения, составляющего 100%. Таким образом, если в четырехъядерном процессоре 1 процесс использует 100% CPU, это даст значение %us, равное 25%. Значение 12,5% для 8-ядерного процессора означает, что занято одно ядро.
%sy означает использование CPU системой. Обычно это значение невысоко, высокие его значения могут свидетельствовать о проблеме с конфигами ядра, проблему со стороны драйвера, или целый ряд других вещей.
%ni означает процент CPU, используемого пользовательскими процессами, на которые повлияло использование команд nice или renice, т.е. по существу их приоритет был изменен по сравнению с приоритетом по умолчанию, назначаемому планировщиком, на более высокий или низкий. При назначении какому-либо процессу команды nice, положительное число означает более низкий приоритет (1 = 1 шаг ниже нормального), а отрицательное число означает более высокий приоритет. 0 – значение по умолчанию, что означает, что решение о приоритете принимает планировщик. Можно установить, какой планировщик используется вашей системой, но это более сложная тема для следующих статей. Кроме того, любая величина в процентах, приведенная в этот статье не накладывается на величину %us, которая показывает только пользовательские процессы с невыставленным приоритетом.
%id – результат, получающийся при вычитании трех предыдущих значений из 100,0%, и измеряющий «простаивающую» вычислительную мощность.

0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Второй набор значений связан с виртуализацией, и именно по ним мы можем точно отследить те проблемы, которые, возможно, вносят вклад в высокое значение средней нагрузки.

%wa – iowait, процент времени (циклов, секунд), в течение которого процессор простаивал, ожидая завершения операции ввода-вывода. Когда какой-либо процесс или программа запрашивает данные, он сначала проверяет кэш процессора (в нем имеется 2 или 3 кэша), затем проверяет память и, наконец, доходит до диска. Дойдя до диска, процессу или программе обычно приходится ждать, пока поток ввода-вывода передаст информацию в оперативную память, прежде чем иметь возможность снова на нем работать. Чем медленнее диск, тем выше будет значение IO Wait % для каждого процесса. Это происходит также с процессами записи на диск, если системный буфер заполнен и его необходимо прочистить при помощи ядра – обычно это наблюдается на серверах баз данных с высокой нагрузкой. Если значение IO Wait стабильно превышает {100 / (кол-во CPU * кол-во процессов)}%, это означает, что, возможно, имеется проблема хранения, с которой необходимо разобраться. Если вы наблюдаете высокую среднюю нагрузку, прежде всего, проверьте этот параметр. Если он высок, тогда узкое место в процессах, скапливающихся на диске, а не в чем-либо еще.
%hi означает прерывания на уровне железа; на плате электроны движутся по микросхемам предсказуемым образом. Например, когда сетевая карта получает пакет, перед передачей информации, содержащейся в пакете в процессор через ядро, она запросит прерывание в канале прерывания материнской платы. Процессор сообщает ядру, что у сетевой карты для него есть информация, а ядро имеет возможность решить, как поступить. Высокое значение времени, тратящегося на обработку прерываний на уровне железа встречается на виртуальной машине довольно редко, но по мере того, как гипервизоры предоставляют в распоряжение виртуальных машин все больше «железа», эта ситуация может измениться. Чрезвычайно высокая пропускная способность сети, использование USB, вычисления на графических процессорах, — все это может привести к росту этого параметра на величину, превышающую несколько процентов.
%si – прерывание на уровне софта; в ядре linux версии 2.4 реализована возможность запроса прерывания программным обеспечением (приложениями), а не элементом аппаратного обеспечения или устройством (драйвером), запрашивающим прерывание в канале прерывания материнской платы; запрос обслуживается ядром посредством его обработчика прерываний. Это означает, что приложение может запросить приоритетный статус, ядро может подтвердить получение команда, а программное обеспечение будет терпеливо ждать, пока прерывание не будет обслужено. Если мы применим утилиту tcpdump к гигабитному каналу с высоким трафиком, то значение может измениться примерно на 10%, — по мере заполнения выделенной памяти tcpdump, утилита посылает зарос на прерывание, чтобы переместить данные со стека на диск, экран, или куда угодно еще.
%st — самый важный параметр из всех в списке, по моему мнению, это IOSteal%. В виртуализированной среде множество логических серверов могут работать под одним фактическим гипервизором. Каждой виртуальной машине(VM) мы присваиваем 4-8 «виртуальных» CPU; хотя сами гипервизоры могут не иметь (кол-во VM * кол-во виртуальных CPU на одну VM). Причина этого заключается в том, что мы не перегружаем CPU использованием наших виртуальных машин, так что если мы дадим одной-двум VM возможность изредка использовать 8 процессоров, это не будет негативно влиять на весь пул в целом. Однако если виртуальными процессорами VM используется количество CPU, превышающее количество физических (или логических, в случае с гиперпотоковыми процессорами Xeon), тогда значение iosteal будет расти.

iosteal% — мера загруженности гипервизора; наличие в каком-либо пуле виртуальных машин, демонстрирующих стабильно высокое значение параметра iosteal% (более 15%) может свидетельствовать о необходимости переноса некоторых из VM в другую часть пула.

iowait% является показателем производительности диска. В системе хранения данных, поддерживаемой NetApp, у нас может не получиться решить проблему производительности без перемещения тома на менее используемый, или другой диск NetApp. В случае с локальным диском (SSD или SAS) это может означать, что в гипервизоре имеется слишком много VM, интенсивно использующих ресурсы диска, и может потребоваться перенести некоторые из этих VM в другую часть пула.

Подведем итоги:

• Средняя нагрузка, на самом деле, ни о чем не говорит.
• Параметр %userland (%us) важен для средней нагрузки, поскольку он говорит о том, что производятся вычисления. Например, mysql, займет всего один поток, поэтому при полной нагрузке будет использовать (1/кол-во виртуальных CPU, присвоенных VM). postgresql является многопоточным, и может использовать больше процессоров, если они будут выделены, – помните об этом, создавая виртуальные машины в гипервизоре, чтобы предотвратить:
%st – iosteal% — показатель загруженности гипервизора. Создание стека из 4-х postgresql и 6 серверов tomcat под одним гипервизором может быть разумным с точки зрения бизнеса, но вам придется все время конкурировать за процессорное время.
%wa – iowait% — показатель количества времени, которое уходит на отсылку ваших процессов на невероятно медленные диски, неважно какое решение для хранения данных вы используете. Диски, даже SSD, сравнительно медленные. Добавление ОЗУ для увеличения буфера ядра может немного смягчить проблему. ОЗУ дешевле диска, если учесть, насколько молниеносно она работает по сравнению с ним.

Дополнительные команды

iostat
Если вы столкнулись с высокими значениями параметров iowait или iosteal, можно с точностью отследить, какой диск является этому причиной, при помощи команды iostat. Запускается она таким образом:



Более подробно, см. руководство по iostat. Разбивка, выводимая каждую секунду, с каких и на какие диски идет чтение/ запись, а также все значения iosteal или iowait, связанные с доступом к этим дискам.

htop
Команда по использованию CPU и процессов на системе Linux. Он не показывает виртуальную статистику, но отображает дерево процессов, а также разбивку каждого процессора в системе, его использование; кроме того, он показывает статистику свопинга и памяти, позволяющую отследить неприятные утечки памяти, раскрашивая все это симпатичными цветами. По моему мнению, этот пакет должен быть обязательным для всех VM.

Небольшое объявление. Как мы сказали вначале, сейчас нами активно тестируется мониторинг внутренних параметров серверов, если Вы хотите поучаствовать в закрытом бета тестировании, то пишите нам на ht2support@host-tracker.com.
Автор: @Alex-HT David Van Rood
ХостТрекер
рейтинг 58,33
Компания прекратила активность на сайте

Комментарии (30)

  • +3
    Например, mysql, займет всего один поток, поэтому при полной нагрузке будет использовать (1/кол-во виртуальных CPU, присвоенных VM). postgresql является многопоточным, и может использовать больше процессоров, если они будут выделены, – помните об этом, создавая виртуальные машины в гипервизоре
    Шайтанама какая.
    • +3
      Мда… Писать по MySQL, что он однопоточный — это вы (обращение к автору статьи, а не к автору коммента) в каком году с ним последний раз имели дело?
      • +3
        А что тут удивительного? Всё зависит от приложения, которое с базой работает.

        Для примера, есть у нас сервачок с базой Oracle (Нормальный такой, на 4 socket-а (всего 64 треда), с подключением к SAN по FC).
        А приложение самописное — контора одна пишет. Оптимизации под многопоточность никакой.
        Как запускается отчёт — часа так на 2-3, один тред (логический cpu) загружен на 100%, остальные почти простаивают.
        А потом жалуются, что сервер у нас слабенький, не тянет их софт.

        Гнать бы таких программеров из этой конторы куда подальше, дык ведь других нет, монополисты они в нашем городе. Да и заточены под нашу специфику — металлургическое производство…
  • +4
    «время бесперебойной работы»

    Я бы лучше выразился, что это время с момента запуска ОС (операционной системы). Работа с момента запуска до текущей даты вполне может быть и «сбойной». Просто эти сбои не приводили с рестарту ОС.
  • 0
    Странно, что не упомянут atop.
    • –1
      ага, и htop впридачу.
      • +1
        Он-то как раз упомянут.
        • 0
          ох, точно. Последний абзац-то я как раз и проглядел.
  • +2
    Практические рекомендации: устраняйте неполадки, используя команду 'Top'
    Под катом увидел только куцый man top. С таким же успехом можно написать/перевести целый цикл статей «Практические рекомендации: устраняйте неполадки, используя команду 'man||ps||rm||killall||emerge||apt-get||ping...'» Новичкам, может и будет полезено, но заголовок ИМХО не отражает сути.

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

    Чем утилиты вроде nrpe не устроили?
    • +4
      Практические рекомендации: устраняйте неполадки, используя команду 'man'
      Чёрт, да такая статья просто необходима :)
  • +2
    Тут же был уже сто и один обзор всевозможных top'ов
    чем этот лучше? перевод мана на русский?..
    • 0
      По моему этот в разы хуже, чем тот
  • 0
    А вот мне интересно, какие значения system cpu load (который sy) стоит считать высокими? У меня вот на ноутбуке он держится в районе 10-15%, это много?
    • 0
      Смотря что нагружает. Лучше всего посмотреть по тому же топу или ps aux какие из ядерных процессов дают нагрузку.
    • 0
      Я бы смотрел не на cpu load, а на load average. Оно дает более вменяемую картину чем абстрактные проценты. Все хорошо если load average < 1.0 X количество CPU. Но в принципе можно жить с load average где то до 3-4 на ядро. Но это уже легкий хардкор.
  • +1
    Посмотрите еще вот этот доклад Михаила Епихина из Яндекс.
  • +3
    Сколько лжи и неполной информации!

    Больше всего меня поразило лженаучное объяснение про wa. Столько ереси про диск, память (смешались в кучу кони, люди) и ни слова про реальную природу wa.

    Пример, где нет никаких операций с диском и при это wa:99.8, и load average over 9000
    Пишем скрипт, который просто ждёт 100 секунд данных, которые никогда не придут:
    #!/usr/bin/python
    import socket, random
    sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
    sock.settimeout(100)
    sock.bind(('127.0.0.1', random.randrange(5000,50000)))
    data, addr = sock.recvfrom(1024)
    

    Запускаем его 1000 раз:
    ~$ for i in {1..1000}; do ./script.py & done

    Рекомендую сразу 1000 не запускать: всё ляжет. Начните с 20-30.
    • 0
      Странно как-то это. Вернее, что будет высткий iowait и la, не странно, а вот то, что ляжет — странно. По идее, для системы recv, безрезультатно ждущий 100 секунд, не должен отличаться от sleep(100). Разве что в пайтоновском recv баг с busywait. Может быть, 1000 пайтон-скриптов в sleep(100) точно так же все положат?
    • +3
      В вашем коде процесс будет висеть в S-state, и на iowait никак не будет влиять. На iowait влияют только процессы, которые висят в D-state.
      • 0
        Согласен, мой пример не самый удачный (призываю обратить внимание на этот комментарий — он толковый :-)).

        Но суть моего примера, думаю, всем понятна. На моей практике бывало множество случаев, когда wa зашкаливал из-за небрежной работы с сетью, а вот wa из-за дисковой подсистемы, мне кажется, — штука экзотическая.
    • 0
      Это Ваш пример лженаучен. Если запускать одновременно 1000 python-процессов, то, очевидно, подскочит LA и wait, т.к. необходимо обратиться к диску для инициализации библиотек, и процессы будут в R-state кратковременно. И не факт, что все обращения к диску отдадутся из page-кеша.

      Но в основной своей части Ваш скрипт, как уже ответили выше, находится в S-state и не оказывает влияния ни на iowait ни на LA.
    • 0
      Хоть и понимаю, что over 9000 — это устоявшаяся фраза, но все равно скажу, что на практике load average больше 1000 не поднимается (или может даже меньше, не помню точно). Потом происходит сброс. Кажется, даже проблемные процессы убиваются.

      Если кто-то помнит как там все на самом деле — напишите, пожалуйста.
      • +2
        Процитирую свой же комментарий в статье "CPU Load: когда начинать волноваться?"
        В старом посте про load average давали ссылку на замечательную статью, где я и прочитал про это самое «кспоненциально взвешенное скользящее среднее»,
        Очень рекомендую к прочтению, можно даже добавить в пост.
        Часть 1 www.teamquest.com/pdfs/whitepaper/ldavg1.pdf
        Часть 2 www.teamquest.com/pdfs/whitepaper/ldavg2.pdf
        • 0
          То, что нужно, спасибо.
      • +1
        Вот из личной практики пример, опровергающий ваше утверждение:
        image
        • 0
          Спасибо, верю. А на какой это системе? На OS X?
          • 0
            Debian. Консоль с макоси по ssh.
            • 0
              Тогда сдаюсь, нечем бить :)
              • 0
                Причем сервер даже как-то жил. И собирал и отдавал. Просто был такой самоблокирующийся код… Сейчас переписали — сатло значительно лучше.
  • 0
    >>iowait% является показателем производительности диска.

    Не только диска, а всей подсистемы ввода/вывода. Т.е. включаем сюда же сетевые интерфейсы, usb и прочее.
    К слову, работа дисковой подсистемы зависит еще от планировщика. Внутри гостевых систем (linux) прекомендуется выбирать шедулер noop, т.к. прочие оптимизации внутри гостя просто лишние.

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

Самое читаемое Разное