Comments 49
Тут не только нелинейность, бывает вообще немонотоность. Вот соптимизировали вы вашу программу, а % загрузки ЦПУ только подрос! Это потому, что ЦПУ сбрасывает частоту по возможности и уже меньший объем работы занимает более значительную часть сильно сжавшегося пирога. Это характерно лишь для некоторых типов работы, но так бывает, например, когда у вас куча слабо загруженных очередей задач да еще и с задержками перед выполнениями.
Более полезной метрикой оказывается потребляемая мощность процессора.
А что, если у меня установлен верхний предел энергопотребления, но моя задача настолько ресурсоемкая, что, скажем, выделяя на ее решение 12 из 16 ядер, я уже упираюсь в лимит? Получается, что часть ресурсов то фактически еще свободна, 4 ядра я не занял вообще.
что ж, похоже вам значит такой подход не подходит. У вас мобильная разработка?
Не, я вообще не разработчик. Просто у меня долгое время основным компьютером был ноутбук, в котором производителем установлен лимит TDP на процессор для продолжительных нагрузок в 35 ватт, и я часто при расчетах по работе сталкивался с ситуациями, когда я могу нагрузить 3 ядра из 4, и уже исчерпать лимит. Поэтому и предложил такую гипотетическую ситуацию.
Это беда, объективно посчитать мощность процессора. Но в целом логично, что если упор в TDP то надо считать метрики, если нет упора то лучше TDP. Но и с ним проблемы бывают, допустим на гибридных системах у тебя подсистема IO жрёт 15Вт, Е ядра 45Вт И ядра 70Вт, но так ли это? Вдруг E ядра отдыхают, а на самом деле Р ядра пашут на всю?
Это тема отлично подходит под GPU, из-за того что там нету возможности перепланировать конвейер на блокировках, бывает такое что видеокарта пишет 100% а по факту 15Вт всего.
Более полезной метрикой оказывается потребляемая мощность процессора
Это тоже не всегда работает. При наличии хорошей системы охлаждения мощность при 100% загрузке на разном коде может существенно различаться (например, код с avx512 потребляет куда больше энергии).
Скорее частоты опустит и сохранит прежний теплопакет. На десктопных zen4-zen5, по крайней мере, именно такое поведение. Лимиты можно выбрать любой многопоточной нагрузкой.
Нет же. Запускаю mprime, например, и смотрю потребление (у меня бп умеет показывать). На разных этапах потребление разное, при той же загрузке 100%. Разница чуть ли не в два раза.
На каком процессоре? На 7950X3D при любом типе нагрузок выше лимита в 160Вт не прыгает (это вместе с SOC).
А вы pbo включаете и лимиты tdp снимаете?
Правда, не помню, насколько это безопасно для процессоров с 3d кэшем.
у asus, например, есть режим pbo enchantment. В нём потребление процессора фактически не ограничивается пока температура не приблизится к установленной границе. При приближении же потребление мягко ограничивается чтобы температура была в установленных пределах. Получается, пока процессор не особо нагружен, он готов агрессивно повышать частоту в случае всплесков нагрузки. Когда же нагружен, фактическое потребление зависит от системы охлаждения.
И тут уже с СЖО я видел цифры под 400Вт на 9950x без дискретной видеокарты под тем же mprime. А код без simd может и 200Вт не набрать при той же загрузке 100%.
(речь про общее потребление, но львиная доля в ней — процессор)
Нет, никогда не увеличиваю TDP и лимиты по питанию. Это уже не штатный режим работы процессора, а разгон для энтузиастов, в котором поведение будет отличаться. Я про него даже в обзорах процессоров пропускаю и не читаю последние лет 15.
Ну и зря. Это уже давно штатные режимы процессора, и даже серверные процессоры идут с регулируемым tdp.
Вот curve (насколько можно понизить напряжение без риска сбоев), и оверрайт максимальной частоты зависят от удачности экземпляра процессора, и идеологически близки к разгону прошлых лет.
И у интела то же самое, всякие core boost
У обоих вендоров для серверных процессоров прописывается на какой максимальной частоте может работать отдельное ядро и на какой частоте все ядра; обычно эта частота существенно выше базовой, например у 9575f базовая частота 3.3, максимальная для одного ядра 5.0, максимальная при загрузке всех ядер — 4.5.
И если охлаждение позволяет, то на нагрузке без simd этот 9575f действительно выдаст 4.5ГГц при загрузке всех ядер.
У серверных и мобильных процессоров регулируемый cTDP задаётся в диапазоне (например 15-45Вт) и выбирается OEM производителем при сборке готовой системы и может меняться в зависимости от профилей работы. Всё что выше этих 45 уже не штатный режим. У 9575f по умолчанию уже максимальный TDP (400W), который настраивается в сторону уменьшения.
Аналогично и с десктопными, у них есть базовые лимиты, а всё что сверху это уже разгон, если это прямо не указано в спецификации.
Поэтому если говорить о поведении процессоров под нагрузкой, то правильно говорить о том, что не выходит за пределы спецификаций.
В играх примерно такая же проблема: из-за того, что большинство из них не умеет грамотно работать с потоками, может казаться, что при загрузке процессора в 50% у тебя остаётся запас по производительности, но на самом деле программа просто не до конца использует весь ресурс процессора, который может. Таким образом, независимо от загрузки процессора в диспетчере задач, это не покажет реальную производительность процессора, поскольку это просто сумма всех используемых потоков. Поэтому, если у тебя многоядерный процессор, это ещё не значит, что все программы будут использовать все ядра.
Именно поэтому производительность на ядро решает много проблем. В идеале иметь много мощных ядер и многопоточность, чтобы ни в одном из кейсов процессор не сел в лужу...
может казаться, что при загрузке процессора в 50% у тебя остаётся запас по производительности, но на самом деле программа просто не до конца использует весь ресурс процессора, который
Тут немного не так. Остаётся запас производительности у всей системы. Т.е. система (комп) может ещё решать задачи. Но кокнретно эта задача уже не может выполняться быстрее, ибо она не параллелится сильнее.
Это как взять в руки что-то объёмное. Рук уже не хватает, но можно ещё и идти, а не просто держать. Ноги-то не загружены.
В играх есть куда более простая метрика - загрузка видеокарты. Если (без ограничений частоты кадров и синхронизаций) загрузка видеокарты не упирается в 100+-5% - значит упор идет в процессор. Ну или сама игра криво написана, но тут уже ничем не поможешь.
Мне кажется вы(ну или исходный автор) немного неверно интерпретировали графики. Метрика нагрузки CPU действительно ложная метрика, но у вас она вышла таковой именно из-за того, что % нагрузки считается общим, а 0-11 и 12-23 воркеры друг другу не равны. Не все задачи могут эффективно выполняться на логических потоках процессора. А в статье идет прямо таки упор на это.
Для меня ложность %% нагрузки чего-либо заключается в том, что может внезапно оказаться, что даже при значениях близким к 100% - можно еще очень даже много полезной работы засунуть в конвеер, и наоборот (реже)
Это обобщенная сферическая в вакууме размазанная во времени характеристика, которая во многих кейсах совершенно неинформативная, а вот ее АНОМАЛЬНОЕ поведение, в совокупности с прочими параметрами - уже может что-то нам сказать. УПД: ее еще и разные системы по-разному считают. Поэтому она для меня всегда являлась косвенным параметром.
оказывается одна цифра плохо подходит для описания нагрузки современных процессоров с кучей ядер, потоков, гипертредингов и прочая, и прочая
А вот не уверен. То, что мы хотим измерить, это именно один показатель: можно ли нагрузить этот хост больше, какую долю текущая производительность составляет от максимальной на этой же нагрузке.
Проблема не в том, что это интегральный показатель, а в том, что непонятно как именно его измерять.
Вот ниже в тему: https://habr.com/ru/articles/944172/#comment_28802618
Но этот способ измерения неприемлем если нам важны задержки
Есть предложения, как следует правильно считать и отображать загрузку ядер процессора?:)
На однородных вычислениях - методом пробных возмущений. Проще говоря - нагружать пока глаза не выскочат. На неоднородных - никак.
Сравнивать эти две метрики, а не показатель использования CPU.
Автор предлагает решение. Но, оно тоже довольно сомнительное. Объем работы в рамках 1й единицы редко константен. Условно, если в чёрную пятницу х10 заказов, то надо не только сделать х10 актов процессинга, но и каждый из них будет чуть тяжелее, чем обычно (где-то алгоритм не О(1), а O от уже сделанных заказов сегодня, где-то кеш начал быстрее протухать из-за того, что объем RAM на кеш-сервере кончается быстрее, чем ttl, база отвечает медленно, сетевые интерфейсы перегружены, и так далее). Можно легко попасть в ситуацию, когда сервер делает 1/2 от своей нормальной работы, все зелёное в мониторинге, но, по факту, целостная система на пределе
Как будто бы, как раз тот случай, что надо тот же ML (или стат таблицы) использовать, и, оценивая текущую частоту, температуру, и загрузку каждого ядра, оценивать, сколько ещё можно с этой системы выжать
Не будет тут одной цифры. Так и останется %% для всего ЦП, частоты для каждого ядра, потребление на ядро + общее потребление ЦП и %% от лимита потребления. Ну и всегда есть лишний параметр, который не учли.
Вот если мы ОЗУ разгоним на 5%(сохранив тайминги, множители, не дойдя до перегрева и ошибок(сказочный сценарий)), как это скажется на тех же графиках(и на каких больше)?
Пока что самой честной метрикой работы ядра остаётся факт его работы🙃
Например из не учтённых (производителем учтённых конечно же) это финальное качество литографии и предрасположенность одной транзисторной сборки (ядро) лучше откликаться на подачу напряжения и иметь меньшие токи утечек, в следствии чего иметь лучшую предрасположенность к стабильному бусту частот с меньшим нагревом и/или меньшим потреблением, чем аналогичные соседние менее "качественные" ядра.
Ох... И, вправду, неприятная тема
Из реального опыта подкину ещё неочевидных парадоксов:
1) из-за энергоэкономии на сервере СУБД падал потоковый процессинг в неннагруженное время. Система состоит из очереди сообщений, сотен воркеров, и сервера СУБД на что-то типа 128 логических ядер. В моменты низкой нагрузки очередь необработанных сообщений летит в космос, но к вечеру, под нагрузкой, возвращается к риалтайму. То есть, утром, в моменты нагрузки до 10% на всем процессорах всех серверов, растут задержки. Оказалось, что ядра на сервере СУБД под общей нагрузкой сервера в 5-10% начинали работать где-то на частоте 0.6 ГГц, из-за чего череда последовательных запросов к СУБД взлетала по времени в разы, и время на обработку одного сообщения становилось несовместимым с потоком сообщений, и воркеры сидели на ожидании СУБД, а СУБД не получала достаточной нагрузки, чтобы поднять частоту. К вечеру нагрузка от других сервисов выводила камни из спячки на их базовую частоту, и сразу все становилось на свои места. Поменяв настройки энергопитания, проблема рассосалась, и более не вернулась
2) Обновление процессоров положило систему. Кластер блейд серверов с двумя xeon e5 в каждом (не помню уже, точно какой, но что-то с очень большой базовой частотой, как для северного железа, типа 3.6 и по 6 ядер в каждом) обслуживает довольно крупный сайт. Каждый отдельный воркер это многопоточный процесс на делфи под x86 с ограничением в 2 ГБ из-за архитектуры. В какой-то момент происходит перевооружение с заменой камней на другие E5 с совместимым сокетом, и все ещё допустимым TDP, хоть и на пределе, но с сильно большим количеством ядер и меньшей частотой. Как результат, время выполнения каждого отдельного запроса на апи с фронта выростает, и в конфигурации того же количества воркеров и потоков система падает под привычной нагрузкой. Девопсы поднимают количество воркеров на каждом блейде, и после этого падает СУБД, к который они ходят за обновлением кеша. Возвращают назад количество воркеров, поднимают количество потоков, и воркера начинают падать по out of memory (привет 2ГБ). В итоге в срочном порядке старые камни ставят назад.
3) Имел дело с уникальной системой, вмещающей 4 видеокарты 1080Ti/Titan X + 2 ксеона в 1U корпус. Отдельная история, как с ее глубиной ее впихнуть в стойку. Но, впихнув, видим, что камни упорно не хотят разгоняться выше 0.6 ГГц. Как уже не танцевали с бубном вокруг биоса, пока производитель не сказал, что с одного блока питания оно нормально работать не будет. С двух блоков таки зарабатало как надо. Реально, одного БП не хватает, и система работает, но с тротлингом
В этой статье не хватает бизнес-составляющей - хотя похоже, что написана она именно с её учётом. Не хватает четкого портрета целевой аудитории и четкого таргетирования сценария.
Ну то есть автор говорит: "Процент загрузки нам врёт, я его измерил всяко-разно и он не соответствует". А в реальности он хочет сказать: "Есть большое количество админов, которые измеряют загрузку своих систем по загрузке CPU. И системы проектируют исходя из этого. А загрузка эта врёт - и у вас всё может поломаться внезапно из-за такой вот ерунды. А всё потому, что измерять надо не просто загрузку, а десяток разных параметров, который у каждого свой".
Похоже, человек открыл для себя удивительный мир гипертрединга и турбо буста (или как оно на АМД называется - Core Boost?). Очевидным образом логические и физические ядра при включённом гипертрединге не равноценны. Если у меня 12 ядер и 24 логических и я займу двенадцатью потоками все 12 физических ядер (то есть через ядро), то резерва останется, конечно не половина, а сильно меньше, но операционки в основном будут показывать 50%, хотя это ни разу не 50%. Если я буду запускать два потока на двух логических ядрах одного физического, то это тоже будет сильно медленнее чем на двух физических, но общую загрузку СPU будет показывать одинаковую.
Ну то есть занимать ядра процессора вот так и сяк - это две большие разницы, вот тут ни разу не 50%, на самом деле:
А вот так примерно 50% и есть (хотя на i7 будет немножко меньше 50, потому что при загрузке оставшихся четырёх ядер частота первых четырёх дропнется):
Кроме того, при загрузке ядра проц поднимает его частоту (на интеле оно обычно так работает), однако если я займу второе и следующее, то он тоже частоту поднимет, но сбросит при этом немножко частоту первого (хотя это тоже зависит от, к примеру, Xeon, что у меня есть, равномерно поднимает частоту всех ядер в турбо буст, хотя он и небольшой). В этом случае рассчитать общую загрузку и спрогнозировать оставшийся резерв тоже непросто. Хотя теоретически можно придумать "калиброванный" индикатор загрузки процессора, который будет более-менее реалистичен. Там надо не вайб-кодить тесты, а аккуратно писать самому с пониманием что там происходит вплоть до уровня команд процессора и всё встанет на свои места.
Ха, я только что понял как работает гипертрединг. Он параллелит команды разных потоков, которые мог бы исполнить на разных конвейерах как если бы они исполнялись в одном потоке. Короче, факт в том, что при включённом гипертрединге мы вообще не можем спрогнозировать общую загрузку процессора, поскольку сколько резерва там осталось - это сильно зависит от данных, которыми мы будем кормить оставшиеся ядра, и, пожалуй, я готов это практически продемонстрировать, но вероятно, завтра к вечеру.
По моим наблюдениям, можно легко упереться не в производительность ядер, а в скорость доступа к DRAM. Применение CPU с бОльшим размером кеша помогает, но радикально проблему не решает.
Поэтому я всегда использую метрику использования процессора Average MHz из гипервизора. Тоже неидеально, но для сравнения ситуации "до" и "после" работает гораздо лучше процентов.
Используем старый проверенный "top" при работе новых технологий изменения частот ЦП и турбобуста, и удивляемся что "top" выдает неточные результаты. Нет сначала бы узнать, а умеет ли он учитывать плавающие частоты ЦП и турбобусты, и как учитывать? Ведь 50% ядра под бустом с повышенными частотами не равно 50% такого же ядра но без буста с частотами ниже. Удивительно? Нет, вполне ожидаемо, и ТС по синтетическим тестам это и получил. Просто "top" работает чопорно, он не заточен под эти ваши более точные метрики, и выдает среднюю температуру по больнице. Просто у него цели и задачи другие: это легковесное но грубое представление. Для ваших более точных целей нужен и инструмент поточнее. Это все равно что использовать деревянную линейку для измерения нанометров и сетовать на неточность. Используйте правильные инструменты. Возможно их ещё нет в свободном доступе или придется писать с учётом приведенных выше моментов и других технологий (по типу использования аппаратных блоков и т.д.).
Я таки набросал небольшое продолжение, алаверды, так сказать, как и обещал: Не смотрите на % использования процессора при гиперпоточности
Безжалостная самореклама: https://github.com/drivenet/cpumon
для рекламы не мешало бы хотя бы readme.md написать )
В основном было предназначено для внутреннего использования, но я в целом согласен что можно и дополнить. Так-то там один исходник на C, инструкция по сборке и запуску в комментариях.
А что хотелось бы видеть в readme? Как собирать? Как запускать?
Что это, какие проблемы решает, зачем нужно и т.п.
Я что-то написал, надеюсь более-менее понятно.
Это же не реалтайм система. Твои 80% загрузки могут выполнятся как за 0.5с так и за 2 и тд. Соответсвенно твоя загрузка по времени становится или под 100% за 0.5 или размазана по времени например 2с
Проценты использования процессора — это ложная метрика