Назад | Перейти на главную страницу

Hyper-Threading и htop / системный монитор

Я запускаю большой набор симуляций на четырехъядерном Xenon E5520 с включенной Hyper-Threading. Мое программное обеспечение автоматически определяет 8 (виртуальных) ядер и запускает 8 симуляций для параллельной работы. Однако htop и system-monitor показывают, что каждое из 8 ядер загружено на ~ 50%.

Это предполагаемое поведение? В каком-то смысле это имеет смысл, поскольку общая нагрузка будет составлять 400% или 100% для каждого физического ядра, но не следует ли мне получить немного больше? Я имею в виду, что это цель HT, верно? Используйте SMT, чтобы использовать неиспользуемые иначе исполнительные блоки для запуска другого потока. Значит, пропускная способность должна быть выше?

Я должен отметить, что нагрузка очень стабильная, по 50% на каждое ядро, все время. Моделирование выполняется Java, в одной JVM, GC не является проблемой, я намного ниже предела кучи JVM. Моделирование не привязано к памяти, есть много возможностей и никакой замены. Моделирование записывает много данных на диск, но есть большие буферы (буфер записи 128 МБ для каждого потока), а активность диска, как показано gkrellm, - это частые всплески ~ 90 МБ / с, но это не постоянная нагрузка, и я могу Не верю, что это могло быть узким местом.

Может ли кто-нибудь пролить свет на это?

Однако htop и system-monitor показывают, что каждое из 8 ядер загружено на ~ 50%.

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

но не следует ли мне получить немного больше?

Вы должны иметь возможность получить 100% на каждом ядре.

Теперь, если вы читаете половину знания Халедда ... вот правда:

  • Hyper-Threading означает, что оба ядра не имеют всего, это правда, поэтому оба ядра, например, не могут выполнять определенные операции одновременно.
  • Однако, к сожалению для него, для OS- это НЕ ВИДИМО. Факторы «нагрузки» ЦП основаны на том, «какой% времени было занято ядром в планировщике ОС». Таким образом, если ядро ​​ЦП имело активную задачу 400 мсек в секунду, оно занято 40%.

Истощение ресурсов Hyper-Threading (т.е. виртуальное ядро ​​должно ждать ресурс) просто означает, что виртуальному ядру требуется больше времени для выполнения операции, но это не видно планировщику ОС. Если ядро ​​тратит 100 мс на внутреннее ожидание, задача займет 500 мс вместо 400 мс. Довольно сложно попытаться выяснить, когда вы столкнулись с нехваткой ресурсов, и это не то, что ОС может сделать (т.е. это то, где вы запускаете специальный код и сравниваете время выполнения, чтобы увидеть, что он занимает больше времени, чем следует = Hyper-threading "плохо". Если ЦП не будет пропускать детализированную внутреннюю статистику использования, вы можете в значительной степени попрощаться с любой производительностью для начала - это ПУТЬ слишком много данных.

В результате второе ядро ​​просто не добавит 100% производительности - поэтому, если что-то занимает 100 мс на одном ядре, с гиперпоточностью и 2 ядрами может потребоваться 75, а не 50. Однако это сильно зависит от кода.

В вашем случае я бы начал с одного потока и выяснил, сможете ли вы довести одно ядро ​​до 100%. Если нет, то симуляция просто чего-то ждет - это проблема с переполнением стека, если вообще существует (программа должна быть изменена). Если это так (ввод-вывод, запись / чтение с диска), то может быть просто необходимость запустить более 1 моделирования на каждое ядро.