Измерение загрузки процессора с гиперпоточностью в Linux


12

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

Например, давайте рассмотрим 2-ядерный процессор, выражающий 4 виртуальных ядра.

Однопоточная рабочая нагрузка теперь будет отображаться как 100% top, так как одно ядро ​​виртуальных ядер полностью используется. Процессор и topработает как положено, словно будет 4 реальных ядра.

С двумя потоками, однако, дела обстоят неуклюже: если все работает хорошо, они сбалансированы с двумя реальными ядрами, поэтому мы получили 200% использования: два раза по 100% и два неактивных виртуальных ядра и используют всю доступную мощность ЦП. , Кажется, хорошо для меня.

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

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

Мне также интересно, как гиперпоточность балансирует два виртуальных на реальном ядре. Если два потока занимают разное количество циклов, виртуальные ядра «адаптируются» так, что оба показывают 100% -ную нагрузку, даже если реальная загрузка отличается?


1
Вы понимаете, что операторская система не знает о разнице между виртуальным ядром с гиперпоточностью и физическим ядром, верно?
Ramhound

Вроде так, но не обязательно? Отображение реального и виртуального ядра представляет собой простую карту одно-двух. Проблема заключается в том, как измерить нагрузку на виртуальное ядро, которое на самом деле меняет доступную производительность, планируя с другим на реальном ядре. Но все данные доступны, я думаю, вопрос только в том, где инструменты, которые получают надлежащий результат из них?
Дронус

1
Мне просто нравится иметь показатель нагрузки, где 100% будет означать, что используется каждый цикл каждого реального ядра.
Дронус

1
Проще говоря: как определить в данный момент, будет ли мой процессор способен выполнять дальнейшую работу, не замедляя текущую работу?
Дронус

1
@ Ramhound, так что, если у меня есть физический 4-ядерный процессор с 8 логическими ядрами, и моя средняя нагрузка скажет 4,00, я использую 100% или 50%?
Баттл Буткус

Ответы:


5

Мартин Тегтмайер из Oracle написал интересный пост в блоге об этом в прошлом году: https://blogs.oracle.com/solaris/cpu-utilization-of-multi-threaded-architectures-explained-v2

Краткий ответ; Гиперпоточность действительно портит способность top сообщать об общем проценте использования ЦП / простоя ЦП.

В худшем случае 2-ядерный 4-виртуальный процессор с двумя потоками при 100% -ной загрузке на ядро ​​может почти насыщать процессор. (В зависимости от использования порта выполнения; только потоки, которые используют совершенно разные вычислительные ресурсы на процессоре, могут по-прежнему работать без влияния на производительность текущего потока.) Однако в этом случае top все равно сообщит о 50% простоя.


1
Текущая рабочая ссылка: blogs.oracle.com/partnertech/…
Ян Лалинский

4

Загрузка ядра сильно отличается от нагрузки на систему. Использование ядра показывает только то, сколько ядро ​​что-то вычисляет или ждет инструкций. Это может быть 100%, что соответствует любому заданному времени, когда процессор что-то вычисляет.

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

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

Это не важно, если загрузка процессора составляет 100 или 10 процентов. Средняя нагрузка может достигать 200 или 300, в этом случае система будет реагировать слабо.

В нормальных рабочих условиях средняя нагрузка на сервер не должна превышать количество ядер в течение длительного времени. Короткие шипы не важны на мой взгляд. 3 числа, которые вы увидите в wвыводе - это загрузка av. на 1/5/15 минут.


0

На мой взгляд, ни один из приведенных выше ответов не является удовлетворительным.

Я думаю, что статья, на которую я ссылаюсь по следующей ссылке, хорошо предназначена для ответа на этот вопрос: http://perfdynamics.blogspot.ch/2014/01/monitoring-cpu-utilization-under-hyper.html

QUOTE:

Идея, лежащая в основе HT, состоит в том, чтобы позволить другому потоку приложения работать, когда текущее приложение останавливается; из-за неправильного прогнозирования веток, пузырей в конвейере и т. д. Чтобы это стало возможным, должен быть другой порт или регистр AS. Этот регистр становится видимым для ОС, когда HT включен. Тем не менее, ОС (и весь путь к пищевой цепочке, независимо от того, какие инструменты для перфорирования вы используете) теперь думает, что в два раза больше ресурсов процессора, то есть 100% ЦП на каждом порту AS.

Но под капотом все еще есть только один исполнительный блок: одно физическое ядро, с которым вы работали до включения HT. Разница в том, что он каким-то образом распределяется между двумя портами AS. То, как одно ядро ​​переключается между двумя портами, очень сложно, но наиболее легко понять с точки зрения опрашиваемых очередей. Я вхожу в этот уровень детализации в моих классах GCaP.

Тестовые измерения в лучшем случае, которые я имею, показывают, что каждый порт HT не может быть занят более чем на 75%, в среднем, или на 150% от общей ожидаемой емкости 200% в зависимости от ОС. «Недостающая» пропускная способность в 50%, о которой я говорил ранее, является иллюзией. Intel утверждает, что для общих приложений можно ожидать что-то в диапазоне от 120% до 130%.

На самом деле, я уверен, что операционная система может достигать 100% на каждом виртуальном ядре, без сомнения об этом. Я только что сделал:

mvn clean install -DskipTests -T 5

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

Короче говоря, вы можете предположить следующее, если общая загрузка ЦП превышает 100%, как вы, и, скорее всего, довольно точно, используя ровно 100% физического ядра. Это меню, если у вас есть физическое ЯДРО 1, разделенное на ЦП 1 операционной системы и ЦП 2. А на ЦП 1 вы используете 50%, а на ЦП 2 - 50%, скорее всего, в реальной жизни вы оказывая давление на общее использование 100% на этом процессоре. Вы максимизировали это.

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

Спасибо

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.