TOC

Как контролировать использование ЦП на каплях DigitalOcean

Вступление

Объем памяти, размер кэша, скорость чтения с диска и записи на диск, а также скорость и доступность вычислительной мощности - все это ключевые элементы, влияющие на производительность вашей инфраструктуры. В этой статье мы сосредоточимся на вводных концепциях мониторинга ЦП и стратегиях оповещения. Мы опишем, как использовать две распространенные утилиты Linux, + uptime + и + top +, чтобы узнать о загрузке и использовании вашего ЦП, а также о том, как настроить Политики оповещения DigitalOcean, чтобы уведомлять вас о значительных изменениях, связанных с ЦП Droplet.

Предпосылки

Обсуждаемые нами две утилиты + uptime + и + top + доступны как часть стандартной установки большинства дистрибутивов Linux. Чтобы воспользоваться преимуществами функций DigitalOcean, таких как политики предупреждений, вам понадобится дроплет DigitalOcean с включенным мониторингом.

Руководство Как установить и использовать агент DigitalOcean для мониторинга объясняет, как включить мониторинг на новой капле, а также как добавить агент мониторинга в каплю, которая уже запущена.

Фон

Прежде чем углубиться в детали + uptime +, + top + и мониторинга DigitalOcean, мы рассмотрим, как измеряется загрузка ЦП и какие шаблоны желательны.

Загрузка процессора против Загрузка процессора

Загрузка ЦП и загрузка ЦП - это два разных взгляда на использование вычислительной мощности компьютера.

Чтобы осмыслить основное различие между ними, мы можем представить процессоров как кассиров в продуктовом магазине, а задачи - как клиентов. * Загрузка ЦП * подобна наличию единой линии проверки, когда клиенты ждут, когда станет доступным следующий кассир Нагрузка - это, по сути, подсчет количества людей в очереди, включая тех, кто находится в кассе Чем длиннее линия, тем дольше ожидание. Напротив, * загрузка ЦП * связана только с тем, насколько заняты кассиры, и не знает, сколько клиентов ждет в очереди.

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

  • Загрузка процессора * - это длина очереди запланированных задач, включая те, которые обрабатываются. Задачи могут переключаться в течение нескольких миллисекунд, поэтому один моментальный снимок нагрузки не так полезен, как среднее из нескольких показаний, выполненных за определенный период времени, поэтому значение нагрузки часто представляется как * среднее значение нагрузки. *

Загрузка ЦП говорит нам о том, как много требуется времени ЦП. Высокий спрос может привести к конфликту за процессорное время и снижению производительности.

  • Использование ЦП *, с другой стороны, сообщает нам, насколько заняты ЦП, не зная, сколько процессов ожидает. Мониторинг использования может показывать тенденции с течением времени, выделять всплески и помогать выявлять нежелательные действия,

Ненормализованные и нормализованные значения

В однопроцессорной системе общая емкость всегда равна 1. В многопроцессорной системе данные могут отображаться двумя разными способами. Суммарная мощность всех процессоров считается равной 100% независимо от количества процессоров, и это называется * нормализованным. * Другой вариант - считать каждый процессор как единое целое, чтобы полностью использовать двухпроцессорную систему на 200% емкости, 4-х процессорная система в полном использовании на 400% емкости и так далее.

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

Отображение информации о процессоре

Мы можем использовать команду + nproc + с опцией + - all + для отображения количества процессоров. Без флага + - all + будет отображаться количество процессорных единиц, доступных текущему процессу, которое будет меньше общего числа процессоров, если они используются.

nproc --all
Output of nproc2

В большинстве современных дистрибутивов Linux мы также можем использовать команду + lscpu +, которая отображает не только количество процессоров, но также архитектуру, название модели, скорость и многое другое:

lscpu
Output of lscpuArchitecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian

On-line CPU(s) list:   0,1
Thread(s) per core:    1
Core(s) per socket:    1
Socket(s):             2
NUMA node(s):          1
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 63
Model name:            Intel(R) Xeon(R) CPU E5-2650L v3 @ 1.80GHz
Stepping:              2
CPU MHz:               1797.917
BogoMIPS:              3595.83
Virtualization:        VT-x
Hypervisor vendor:     KVM
Virtualization type:   full
L1d cache:             32K
L1i cache:             32K
L2 cache:              256K
L3 cache:              30720K
NUMA node0 CPU(s):     0,1
Flags:                 fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon rep_good nopl eagerfpu pni pclmulqdq vmx ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm vnmi ept fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid xsaveopt arat

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

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

Оптимальное использование ЦП варьируется в зависимости от вида работы, которую сервер должен выполнять. Устойчивая высокая загрузка ЦП достигается ценой менее отзывчивого взаимодействия с системой. Часто для ресурсоемких приложений и пакетных заданий часто подходит постоянная работа на полной или почти полной мощности. Однако если ожидается, что система будет обслуживать веб-страницы или предоставлять отзывчивые интерактивные сеансы для таких служб, как SSH, может быть желательно иметь некоторую доступную вычислительную мощность в режиме ожидания.

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

Мониторинг процессора

Существует множество инструментов, которые могут предоставить информацию о состоянии процессора в системе. Мы рассмотрим две команды: + uptime + и + top +. Оба являются частью установки по умолчанию большинства популярных дистрибутивов Linux и обычно используются по требованию для исследования загрузки и загрузки процессора. В следующих примерах мы рассмотрим 2-ядерную каплю, которую мы представили выше.

Провел

Мы начнем с команды + uptime +, чтобы посмотреть нагрузку на ЦП, которая, хотя и показывает только базовую среднюю нагрузку на ЦП, может быть полезной, когда система медленно реагирует на интерактивные запросы, поскольку она требует мало системных ресурсов.

время работы показывает:

  • системное время на момент запуска команды

  • как долго работал сервер

  • сколько подключений пользователи имели к машине

  • средняя загрузка процессора за последние одну, пять и пятнадцать минут.

uptime
Output 14:08:15 up 22:54,  2 users,  load average: 2.00, 1.37, 0.63

В этом примере команда была запущена в 14:08 на сервере, который работал почти 23 часа. Два пользователя были подключены при запуске + uptime +. Поскольку этот сервер имеет 2 ЦП, в течение минуты, предшествующей выполнению команды, средняя загрузка ЦП 2,00 означает, что в течение этой минуты в среднем два процесса использовали ЦП, и ни один из них не ожидал. Среднее значение 5-минутной загрузки показывает, что в течение некоторого интервала в течение 60% времени использовался неработающий процессор. 15-минутное значение указывает, что было еще больше доступного времени обработки. Три фигуры вместе показывают увеличение нагрузки за последние пятнадцать минут.

Время безотказной работы дает полезный взгляд на среднюю нагрузку, но для получения более подробной информации мы обратимся к началу.

top

Как и + uptime +, top доступен как в системах Linux, так и в системах Unix, но помимо отображения средних значений нагрузки для предварительно установленных исторических интервалов, он предоставляет периодическую информацию об использовании ЦП в реальном времени, а также другие соответствующие показатели производительности. Принимая во внимание, что + uptime + запускается и завершается, top остается на переднем плане и обновляется через регулярные промежутки времени.

top

  • Блок заголовка * + Первые пять строк предоставляют сводную информацию о процессах на сервере:

Outputtop - 18:31:30 up 1 day,  3:17,  2 users,  load average: 0.00, 0.00, 0.00
Tasks: 114 total,   1 running, 113 sleeping,   0 stopped,   0 zombie
%Cpu(s):  7.7 us,  0.0 sy,  0.0 ni, 92.2 id,  0.0 wa,  0.0 hi,  0.0 si,  0.1 st
KiB Mem :  4046532 total,  3238884 free,    73020 used,   734628 buff/cache
KiB Swap:        0 total,        0 free,        0 used.  3694712 avail Mem

  • Первая строка практически идентична выводу + uptime +. Как + uptime +, отображаются средние значения загрузки за одну, пять и пятнадцать минут. Единственная разница между этой строкой и выводом + uptime + заключается в том, что в начале строки отображается имя команды + top +, а время обновляется каждый раз, когда + top + обновляет данные.

  • Во второй строке приводится сводная информация о состоянии задач: общее количество процессов, а затем количество запущенных, спящих, остановленных или зомби-процессов.

  • Третья строка говорит нам об использовании процессора. Эти цифры нормализованы и отображаются в процентах (без символа%), поэтому все значения в этой строке должны составлять до 100% независимо от количества процессоров.

  • Четвертая и пятая строки информации заголовка говорят нам об использовании памяти и подкачки соответственно.

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

В приведенном ниже примере блока заголовка среднее значение за минуту загрузки превышает число процессоров на 0,77, что указывает на короткую очередь с небольшим временем ожидания. Общая загрузка ЦП составляет 100%, а свободной памяти достаточно.

Output
Tasks: 117 total,   3 running, 114 sleeping,   0 stopped,   0 zombie

KiB Mem :  4046532 total,  3244112 free,    72372 used,   730048 buff/cache
KiB Swap:        0 total,        0 free,        0 used.  3695452 avail Mem
. . .

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

  • * us, user: время запуска незаметных пользовательских процессов *
    Эта категория относится к пользовательским процессам, которые были запущены без явного приоритета планирования. + Более конкретно, системы Linux https://www.digitalocean.com/community/tutorials/how-to-use-ps-kill-and-nice-to-manage-processes-in-linux#how-to-adjust- приоритеты процесса [используйте команду + nice + для установки приоритета планирования процесса], поэтому «незаметно» означает, что + nice + не использовалось для изменения значения по умолчанию. Значения * user * и * nice * учитывают все пользовательские процессы. Высокая загрузка ЦП в этой категории может указывать на ускоренный процесс, и вы можете использовать вывод в таблице процессов, чтобы определить, так ли это.

  • * sy, system: время запуска процессов ядра *
    Большинство приложений имеют как пользовательские компоненты, так и компоненты ядра. Когда ядро ​​Linux делает что-то вроде системных вызовов, проверки разрешений или взаимодействия с устройствами от имени приложения, здесь отображается использование ЦП ядром. Когда процесс выполняет свою собственную работу, он появится либо на рисунке * user *, описанном выше, либо, если его приоритет был явно установлен с помощью команды + nice +, на рисунке * nice *, который следует ниже.

  • * ni, nice: время запуска приятных пользовательских процессов *
    Как и * user *, это относится к задачам процесса, которые не связаны с ядром. В отличие от * user *, приоритет планирования для этих задач был установлен явно. Уровень детализации процесса указан в четвертом столбце таблицы процессов под заголовком * NI *. Процессы со значением добротности от 1 до 20, которые занимают много процессорного времени, обычно не являются проблемой, поскольку задачи с нормальным или более высоким приоритетом смогут получать вычислительную мощность, когда им это необходимо. Однако, если задачи с повышенной точностью, от -1 до -20, занимают непропорциональное количество ЦП, они могут легко повлиять на быстродействие системы и потребовать дальнейшего изучения. Обратите внимание, что многие процессы, которые выполняются с наивысшим приоритетом планирования, -19 или -20 в зависимости от системы, порождаются ядром для выполнения важных задач, влияющих на стабильность системы. Если вы не уверены в процессах, которые видите, разумно исследовать их, а не убивать.

  • * id, idle: время, проведенное в обработчике бездействия ядра *
    Эта цифра показывает процент времени, в течение которого процессор был доступен и простаивал. Система в целом находится в хорошем рабочем состоянии по отношению к процессору, когда совокупные значения * user *, * nice * и * idle * составляют около 100%.

  • * wa, IO-wait: время ожидания завершения ввода-вывода *
    На рисунке IO-wait показано, когда процессор начал чтение или запись и ожидает завершения операции ввода-вывода. Задачи чтения / записи для удаленных ресурсов, таких как NFS и LDAP, также будут учитываться в IO-wait. Как и в случае простоя, пики здесь нормальные, но любое частое или длительное время в этом состоянии предполагает неэффективную задачу, медленное устройство или потенциальную проблему с жестким диском.

  • * привет: время, потраченное на обслуживание аппаратных прерываний *
    Это время, затрачиваемое на физические прерывания, отправляемые в ЦП с периферийных устройств, таких как диски и аппаратные сетевые интерфейсы. Когда значение * аппаратное прерывание * высокое, одно из периферийных устройств может работать неправильно.

  • * si: время, потраченное на обслуживание программных прерываний *
    Программные прерывания отправляются процессами, а не физическими устройствами. В отличие от аппаратных прерываний, которые происходят на уровне процессора, программные прерывания происходят на уровне ядра. Когда значение * программного прерывания * использует много вычислительной мощности, исследуйте конкретные процессы, использующие ЦП.

  • * st: время, украденное у этого vm гипервизором *
    Значение «кража» относится к тому, сколько времени виртуальный ЦП проводит в ожидании физического ЦП, пока гипервизор обслуживает себя или другой виртуальный ЦП. По сути, объем использования ЦП в этом поле указывает, сколько вычислительной мощности ваша ВМ готова использовать, но которая не доступна для вашего приложения, поскольку она используется физическим хостом или другой виртуальной машиной. Как правило, наличие кражи до 10% в течение коротких периодов времени не является поводом для беспокойства. Большие объемы кражи в течение более длительных периодов времени могут указывать на то, что физический сервер требует больше ресурсов ЦП, чем может поддерживать.

Теперь, когда мы рассмотрели сводную информацию об использовании ЦП, представленную в блоке заголовка «+ top +», мы посмотрим на таблицу процессов, которая появляется под ней, обращая внимание на столбцы, специфичные для ЦП.

  • Таблица процессов * + Все процессы, запущенные на сервере, в любом состоянии перечислены под сводным блоком. Пример ниже включает первые шесть строк таблицы процессов из команды + top в разделе выше. По умолчанию таблица процессов сортируется по% ЦП, поэтому мы видим процессы, которые потребляют больше всего ЦП в первую очередь.

Output
 PID USER      PR  NI    VIRT    RES    SHR S   %MEM     TIME+ COMMAND
9966 sammy     20   0    9528     96      0 R    0.0   0:40.53 stress
9967 sammy     20   0    9528     96      0 R    0.0   0:40.38 stress
   7 root      20   0       0      0      0 S     0.0   0:01.86 rcu_sched
1431 root      10 -10    7772   4556   2448 S     0.1   0:22.45 iscsid
9968 root      20   0   42556   3604   3012 R     0.1   0:00.08 top
9977 root      20   0   96080   6556   5668 S     0.2   0:00.01 sshd
...

% ЦП представлен в виде процентного значения, но он не нормирован, поэтому в этой двухъядерной системе сумма всех значений в таблице процессов должна составлять до 200%, когда оба процессора полностью используются.

До сих пор мы рассмотрели две команды Linux, которые обычно используются для оценки загрузки процессора и его загрузки. В следующем разделе мы рассмотрим инструменты мониторинга ЦП, доступные без дополнительных затрат для DigitalOcean Droplets.

Мониторинг DigitalOcean для загрузки процессора

По умолчанию все капли отображают графики пропускной способности, ЦП и дискового ввода-вывода, когда вы щелкаете по имени капли на панели управления:

изображение: https: //assets.digitalocean.com/articles/monitor-cpu/droplet-control.png [Снимок экрана с именем капли на панели управления]

Эти графики отображают использование каждого ресурса за последние 6 часов, 24 часа, 7 дней и 24 часа. График ЦП предоставляет информацию об использовании ЦП. Синяя линия указывает на использование процессора пользовательскими процессами. Голубой цвет указывает на использование процессора системными процессами. Значения на графиках и их детализация нормализованы, поэтому общая емкость составляет 100% независимо от количества виртуальных ядер.

изображение: https: //assets.digitalocean.com/articles/monitor-cpu/default-cpu-graph.png [Снимок экрана графика ЦП по умолчанию]

Графики позволяют увидеть, есть ли у вас периодические или устойчивые изменения в использовании, и помогают определить изменения в схеме использования ЦП сервера.

В дополнение к этим графикам по умолчанию вы можете установить Агент DigitalOcean на Дроплет для сбора и отображения дополнительных данных. Агент также позволяет вам устанавливать Политики оповещения для системы. Как установить и использовать агент DigitalOcean для мониторинга может помочь вам установить вверх.

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

Пример оповещения

  • Мониторинг изменений: ЦП выше 1% * + Если вы используете Droplet в основном для интеграции и тестирования кода, вы можете установить предупреждение, которое чуть выше исторических шаблонов, чтобы определить, увеличил ли ЦП новый код, отправленный на сервер. использование. Для приведенного выше графика, где ЦП никогда не достигает 1%, порог использования ЦП в 1% в течение 5 минут может обеспечить раннее предупреждение об изменениях на основе кода, влияющих на использование ЦП.

image: https: //assets.digitalocean.com/articles/monitor-cpu/low-alert.png [Снимок экрана формы политики предупреждений, заполненной значениями в предыдущем абзаце]

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

  • Мониторинг в чрезвычайной ситуации: загрузка ЦП выше 90% * + Возможно, вы также захотите установить пороговое значение, намного превышающее среднее значение, которое вы считаете критическим и которое потребует незамедлительного расследования. Например, если сервер, который испытывал устойчивое использование ЦП в 50% с пятиминутными интервалами, довольно часто внезапно достигал 90%, вы можете немедленно войти в систему, чтобы исследовать ситуацию. Опять же, пороговые значения зависят от рабочей нагрузки системы.

Заключение

В этой статье мы рассмотрели + uptime + и + top +, две распространенные утилиты Linux, которые дают представление о процессоре в системах Linux, а также о том, как использовать DigitalOcean Monitoring, чтобы увидеть историю использования ЦП в Droplet и предупредить вас об изменениях и чрезвычайных ситуациях.

  • Чтобы узнать больше о мониторинге DigitalOcean, см. Https://www.digitalocean.com/community/tutorials/an-introduction-to-digitalocean-monitoring[A Введение в мониторинг DigitalOcean]

  • Для получения инструкций по выбору планов Standard, High Memory и High CPU см. Https://www.digitalocean.com/community/tutorials/choosing-the-right-droplet-for-your-application[Choosing Right Droplet для ваше приложение].

  • Если вы ищете более детальные сервисы мониторинга, вы можете узнать больше об использовании определенных инструментов, таких как Zabbix, https: / /www.digitalocean.com/community/tutorials/how-to-install-icinga-and-icinga-web-on-ubuntu-16-04[Icinga] и https://www.digitalocean.com/community/tutorials / Как контролировать систему метрик-с-тик-стеком-на-Ubuntu-16-04 [TICK] или просмотреть полный список https://www.digitalocean.com/community/tags/monitoring ? type = tutorials [DigitalOcean Monitoring] учебные пособия.

Related