Поиск по сайту:

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


Введение

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

Мы начнем с понимания двух наиболее часто упоминаемых показателей использования ресурсов на любом сервере Linux: загрузка ЦП и средняя нагрузка. Мы рассмотрим разницу между этими двумя показателями, а затем посмотрим, как проверить их значения с помощью двух утилит командной строки, uptime и top. Наконец, мы рассмотрим, как отслеживать эти показатели с течением времени с помощью мониторинга DigitalOcean и установить политику оповещения, чтобы вы могли получать уведомления по электронной почте или в Slack, когда показатели превышают свои обычные значения.

Предпосылки

Чтобы следовать этому руководству, вам необходимо:

  • Двухъядерный дроплет DigitalOcean с включенным мониторингом. Прочтите, как установить агент DigitalOcean Metrics, чтобы узнать, как включить мониторинг в новой капле или добавить агент мониторинга в существующую каплю.
  • Утилита stress, установленная на вашем дроплете. Используйте apt или dnf, чтобы установить stress из репозиториев вашего дистрибутива.

Две утилиты командной строки, представленные в этом руководстве, uptime и top, доступны по умолчанию в большинстве дистрибутивов Linux.

Фон

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

Загрузка ЦП по сравнению со средней нагрузкой

Эти две часто проверяемые метрики иногда объединяют, потому что обе связаны с ЦП, и обе могут быть высокими, когда сервер явно перегружен. Но они не измеряют одно и то же и не всегда напрямую коррелируют друг с другом. Использование ЦП показывает, насколько заняты ЦП в данный момент, а средняя загрузка показывает, сколько задач ожидает или выполняется на ЦП в среднем за последнее время. .

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

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

Конечно, эти две метрики связаны: одна очевидная причина, по которой очереди на кассе могут быть хронически длинными, заключается в том, что в магазине слишком медленные (или слишком мало) кассиры. Но линии могут быть заблокированы и по другим причинам. Если покупатель просит проверить цену товара, кассир просит сделать это другого сотрудника. Кассир может продолжать сканировать другие товары, ожидая проверки цен, но если чек не вернулся к тому времени, когда другие товары были отсканированы (возможно, проверяющий ненадолго отошел в сторону), кассир и покупатель будут ждать. лениво, пока линия растет. Это похоже на ожидание задачи на каком-то медленном или недоступном устройстве ввода-вывода (например, на диске), и действительно, рабочие нагрузки с большим объемом операций ввода-вывода могут привести к высокой средней нагрузке, но низкой загрузке ЦП.

А теперь представьте, что ценник ушел на 30 минут в обеденный перерыв. В то же время, еще несколько клиентов нуждаются в проверке цен. (Предположим, что бездействующий кассир не может сам проверять цены, так же как ЦП не может выполнять функции диска.) Кассир откладывает всех этих покупателей в сторону и работает с оставшимися покупателями, освобождая очередь на кассе. Кассир сейчас простаивает (использование ~0%), но есть еще несколько клиентов, стоящих рядом (ненулевая нагрузка), которым все еще нужно ее время, даже если она еще не может завершить свои проверки, потому что все ждут возвращения проверяющего цены. Спрос на кассу есть, но она не занята, поэтому если к кассе подойдет новый покупатель, его сразу же обслужат.

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

  1. Средняя загрузка не является косвенным показателем использования ЦП. Это не одно и то же.
  2. Загрузка ЦП означает потребность в ЦП. ЦП с недостаточной мощностью могут увеличить этот спрос, но то же самое может произойти и с другими вещами, а именно с ожиданием ввода-вывода. Средняя загрузка обычно считается метрикой, связанной с ЦП, но речь идет не только о ЦП. И так,
  3. Высокую среднюю нагрузку не всегда можно уменьшить, добавив больше или более быстрые процессоры.

Так как же сервер представляет эти показатели?

Единицы измерения

Загрузка ЦП указывается в процентах от общей емкости ЦП в системе. В однопроцессорной системе общая мощность ЦП всегда равна 100%. В многопроцессорной системе емкость может быть представлена двумя разными способами: нормализованным или ненормализованным.

Нормализованная мощность означает, что совокупная мощность всех процессоров считается равной 100 %, независимо от количества процессоров. Если оба ЦП в двухпроцессорной системе загружены на 50 %, нормализованная общая загрузка составляет 50 %.

При ненормализованной мощности каждый процессор считается единицей со 100%-ной мощностью, поэтому двухпроцессорная система имеет 200%-ю производительность, четырехпроцессорная система — 400%-ю и так далее. Если оба процессора в двухпроцессорной системе загружены на 50 %, ненормализованное общее использование равно 100 % (половина от максимального значения в 200 %), что может сбивать с толку, если вы не понимаете, что смотрите на ненормализованная цифра на двухпроцессорной системе.

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

Значения средней нагрузки никогда не нормализуются. Ни один инструмент не сообщит о случае с четырьмя процессорами и четырьмя задачами как со средней нагрузкой 1,0. Если в среднем имеется четыре задачи, выполняющиеся или ожидающие ЦП, средняя нагрузка всегда будет равна 4,0, независимо от количества ЦП.

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

Сколько у вас процессоров?

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

  1. nproc --all
Output of nproc
2

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

  1. lscpu
Output of lscpu
Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 2 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

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

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

Хотя вы никогда не захотите увидеть устойчивую загрузку ЦП на уровне 100 % (нормализованную) на любом сервере, для приложения с интенсивными вычислениями уместно колебаться чуть ниже 100 %. Если это не так, у вас может быть больше мощности процессора, чем вам нужно, и, возможно, понижение версии сервера (или использование меньшего количества серверов) поможет вам сэкономить деньги.

Оптимальное значение средней нагрузки равно или меньше числа ЦП. Пока средняя загрузка двухпроцессорной системы остается ниже 2,0, вы можете быть уверены, что конкуренция за процессорное время возникает редко. (Хотя очереди почти наверняка на короткое время увеличиваются.)

Проверка средней нагрузки с временем безотказной работы

Команда uptime — это быстрый способ проверить среднюю загрузку. Это может быть полезно, потому что оно легкое и работает быстро, даже если система в противном случае медленно отвечает в командной строке (например, из-за высокой нагрузки).

Команда uptime показывает:

  • системное время
  • как долго работает сервер
  • сколько пользователей сейчас вошли в систему
  • средняя нагрузка за последние одну, пять и пятнадцать минут

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

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

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

Проверка загрузки ЦП с помощью top

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

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

  1. stress -c 2

Теперь откройте другой терминал для своего дроплета и запустите top:

  1. top

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

Блок заголовка

Вот первые пять строк в top:

Output
top - 22:05:28 up 1:02, 3 users, load average: 2.26, 2.27, 2.19 Tasks: 109 total, 3 running, 106 sleeping, 0 stopped, 0 zombie %Cpu(s): 99.8 us, 0.0 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.2 st MiB Mem : 1975.7 total, 1134.7 free, 216.4 used, 624.7 buff/cache MiB Swap: 0.0 total, 0.0 free, 0.0 used. 1612.0 avail Mem

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

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

Третья строка сообщает вам об использовании процессора. Эти цифры нормализованы и отображаются в процентах (без символа %), так что все значения в этой строке должны составлять в сумме 100% независимо от количества процессоров. Поскольку вы запустили команду stress с параметром -c (CPU) непосредственно перед запуском top, первая цифра — нас или пользовательские процессы — должно быть около 100%.

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

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

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

Output
top - 14:36:05 up 23:22, 2 users, load average: 2.77, 2.27, 1.91 Tasks: 117 total, 3 running, 114 sleeping, 0 stopped, 0 zombie %Cpu(s): 98.3 us, 0.2 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.2 si, 1.3 st KiB Mem : 4046532 total, 3244112 free, 72372 used, 730048 buff/cache KiB Swap: 0 total, 0 free, 0 used. 3695452 avail Mem . . .

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

мы, пользователь: время работы незащищенных пользовательских процессов

sy, system: время выполнения процессов ядра

ni, nice: время запуска приятных пользовательских процессов

id, idle: время, проведенное в обработчике простоя ядра

wa, IO-wait: время ожидания завершения ввода/вывода

привет, аппаратные прерывания: время, потраченное на обслуживание аппаратных прерываний

si, программные прерывания: время, затрачиваемое на обслуживание программных прерываний

st,steal: время, украденное у этой виртуальной машины гипервизором

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

Таблица процессов

Вот первые шесть строк таблицы процессов в некотором примере вывода top:

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

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

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

Примечание. Если вы предпочитаете видеть здесь нормализованные значения, нажмите SHIFT+I, чтобы переключить дисплей из режима Irix в режим Solaris. Теперь сумма значений %CPU не будет превышать 100%. Когда вы переключитесь в режим Solaris, вы получите краткое сообщение о том, что режим Irix отключен, и в этом примере значения для ваших процессов stress изменятся с почти 100 % каждый на примерно 50 % каждый. .

Output
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 10081 sammy 20 0 9528 96 0 R 50.0 0.0 0:49.18 stress 10082 sammy 20 0 9528 96 0 R 50.0 0.0 0:49.08 stress 1439 root 20 0 223832 27012 14048 S 0.2 0.7 0:11.07 snapd 1 root 20 0 39832 5868 4020 S 0.0 0.1 0:07.31 systemd

Вы можете интерактивно управлять top — и процессами сервера — с помощью различных нажатий клавиш, в том числе:

  • SHIFT-M для сортировки процессов по использованию памяти.
  • SHIFT-P для сортировки процессов по загрузке ЦП.
  • k, за которым следует идентификатор процесса (PID) и сигнал для уничтожения неуправляемого процесса. После ввода PID сначала попробуйте сигнал 15 (SIGTERM), который используется по умолчанию. Не используйте 9 (SIGKILL) небрежно.
  • r, за которым следует идентификатор процесса, чтобы изменить (изменить приоритет) процесс.
  • c, чтобы переключать описания команд между кратким описанием (по умолчанию) и полной строкой команды.
  • d, чтобы изменить интервал обновления для рисунков в top.

И многое другое. Прочтите справочную страницу top (man top) для получения более подробной информации.

До сих пор вы изучили две команды Linux, которые обычно используются для просмотра средней нагрузки и использования ЦП. Какими бы полезными ни были эти инструменты, они дают представление о состоянии вашего сервера только в течение короткого промежутка времени. Только так долго можно сидеть и смотреть top. Чтобы получить лучшее представление о долгосрочных закономерностях использования ресурсов сервера, вам нужно какое-то решение для мониторинга. В следующем разделе вы кратко рассмотрите инструменты мониторинга, доступные бесплатно для дроплетов DigitalOcean.

Отслеживание показателей с течением времени с помощью мониторинга DigitalOcean

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

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

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

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

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

Примечание: при установке агента мониторинга DigitalOcean:

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

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

Мониторинг изменений: ЦП выше 1%

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

На панели управления DigitalOcean в меню «УПРАВЛЕНИЕ» слева нажмите «Мониторинг». На вкладке «Оповещения о ресурсах» (которая выделена по умолчанию) нажмите «Создать оповещение о ресурсах». Заполните форму и нажмите Создать оповещение о ресурсе.

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

Мониторинг аварийной ситуации: загрузка ЦП выше 90%

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

Заключение

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

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