Что такое загрузка ЦП?

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

%CPU можно разбить на две составляющие

циклы с отложенными инструкциями и остановленные циклы, например, %INS и %STL.

IOWAIT !=Задержка

Неправильно интерпретировать высокий %CPU как означающий, что процессор является узким местом.

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

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

Контекст того, что вы измеряете, зависит от того, полезна ли эта работа или нет. Первоначальный доступ к буферу почти всегда останавливается (если вы не выполнили предварительную выборку более 100 инструкций назад). Но начать стримить эти данные в L1 — полезная работа.

Стремление к 100%+ IPC _запредельно_ сложно даже для простых алгоритмов и критически важных функций горячего тракта. Вам не только требуется взаимодействие ассемблера (чтобы обеспечить выравнивание декодера), но вам нужно знать, на каком процессоре вы работаете, чтобы знать ограничения его декодера, кэша uOP и выравнивания кэша uOP.

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

инструкции/цикл (IPC) (обратите внимание на общее количество IPC = количество ядер!)

Производительность низкого уровня может быть точно измерена с помощью IPC, инструкций за цикл. IPC показывает в среднем, сколько инструкций мы выполнили за каждый такт процессора. Чем выше, тем лучше (упрощение). Приведенный выше пример 0,78 звучит неплохо (78% занятости?), пока вы не поймете, что максимальная скорость этого процессора — это IPC 4,0. Это также известно как 4-wide, что относится к пути выборки/декодирования инструкций. Это означает, что ЦП может удалить (завершить) четыре инструкции за каждый такт. Таким образом, IPC 0,78 в системе с четырьмя процессорами означает, что ЦП работают на 19,5% от их максимальной скорости. Новые процессоры Intel могут перейти на 5-дюймовые.

Если ваш IPC равен ‹ 1,0, у вас, скорее всего, проблемы с памятью, и стратегии настройки программного обеспечения включают сокращение операций ввода-вывода в память, улучшение кэширования ЦП и локальности памяти, особенно в системах NUMA. Аппаратная настройка включает использование процессоров с большим кэш-памятью, более быстрой памятью, шинами и межсоединениями.

Если ваш IPC › 1.0, вы, скорее всего, привязаны к инструкции. Ищите способы уменьшить выполнение кода: исключите ненужную работу, операции с кешем и т. д. CPU flame graphs — отличный инструмент для этого исследования. Для аппаратной настройки попробуйте увеличить тактовую частоту и увеличить количество ядер/гиперпотоков.

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

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

Средняя нагрузка Linux

Средняя загрузка — это средняя загрузка системы, рассчитанная за заданный период времени 1, 5 и 15 минут.

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

Чтобы понять среднее число нагрузки, вам нужно знать, сколько процессоров есть в вашей системе. Среднее значение нагрузки 6,03 указывает на то, что система с одним ЦП сильно перегружена, но на компьютере с 8 ЦП все будет в порядке.

Более глубокие показатели

Когда средняя нагрузка на Linux увеличивается, вы знаете, что у вас более высокий спрос на ресурсы (ЦП, диски и некоторые блокировки), но вы не знаете, какие именно. Вы можете использовать другие показатели для уточнения. Например, для процессоров:

  • загрузка ЦП: например, с помощью mpstat -P ALL 1
  • загрузка ЦП для каждого процесса: например, top, pidstat 1 и т. д.
  • задержка очереди выполнения (планировщика) для каждого потока: например, в /proc/PID/schedstats, delaystats, perf sched
  • Задержка очереди выполнения ЦП: например, в /proc/schedstat, perf sched, мой инструмент runqlat bcc.
  • Длина очереди запуска ЦП: например, с помощью vmstat 1 и столбца «r» или моего инструмента runqlen bcc.

Первые две — это метрики использования, последние три — метрики насыщения. Показатели использования полезны для характеристики рабочей нагрузки, а показатели насыщения полезны для выявления проблем с производительностью. Лучшими показателями насыщения ЦП являются показатели задержки очереди выполнения (или планировщика): время, в течение которого задача/поток находились в состоянии готовности к выполнению, но должны были ждать своей очереди. Они позволяют вычислить масштаб проблемы с производительностью, например, процент времени, в течение которого поток находился в задержке планировщика. Вместо этого измерение длины очереди выполнения может указать на наличие проблемы, но оценить ее масштаб сложнее.

— -

использованная литература

http://www.brendangregg.com/blog/2017-08-08/linux-load-averages.html

http://www.brendangregg.com/blog/2017-05-09/cpu-utilization-is-wrong.html

https://www.howtogeek.com/194642/understanding-the-load-average-on-linux-and-other-unix-like-systems/