АК
Предпологаю, что на какой-нибудь вебсфере всё это учтено, что не обязательно так на всех установках всех никсов.
Size: a a a
2021 March 24
AA
троттлинг в нормальной станции? даже если он включился то утилизация такая что нормальным поведением это не назвать, использование ресурсов больше 80 даже процентов (пики не в счет) имхо уже повод докидывать ресурсов или что то делать с системо
ВС
Ух ты, какая мякотка!
https://support.microsoft.com/kb/3200459
Сейчас процессоры могут менять частоту.
Например, у проца cm8070104290715s
Частота 2.9 ГГц и 4.3 ГГц в режиме Turbo
В связи с этим в ms поменяли метрику, показывающую утилизацию cpu в диспетчере задач:
Если раньше она основывалась на времени, которое процессор потратил на работу, то теперь она основывается на объёме работы.
Как было раньше (примерно):
- вы нагружали проц на 50%
- и увеличиваете нагрузку на 30%
- проц разгонялся (пусть на те же 30%)
- значит запас мощности увеличивался
- и утилизация cpu оставалась 50%, хотя нагрузка на систему возросла.
Теперь же:
- вы нагружали проц на 50%
- и увеличиваете нагрузку на 30%
- проц разгонялся (пусть на те же 30%)
- метрика отображает увеличивающуюся нагрузку, рисуя вам 80% утилизации cpu (хотя по-факту, пока работает турбо-режим, проц нагружен наполовину)
- а если вы увеличите нагрузку вдвое, метрика покажет вам 130% утилизации cpu
Иначе говоря, старые метрики больше подходят для отображения запаса ресурсов
А новые - для отображения нагрузки на систему.
В перфмоне же доступны все метрики, и старые и новые.
Ps Надеюсь, не налажал в понимании.
https://support.microsoft.com/kb/3200459
Сейчас процессоры могут менять частоту.
Например, у проца cm8070104290715s
Частота 2.9 ГГц и 4.3 ГГц в режиме Turbo
В связи с этим в ms поменяли метрику, показывающую утилизацию cpu в диспетчере задач:
Если раньше она основывалась на времени, которое процессор потратил на работу, то теперь она основывается на объёме работы.
Как было раньше (примерно):
- вы нагружали проц на 50%
- и увеличиваете нагрузку на 30%
- проц разгонялся (пусть на те же 30%)
- значит запас мощности увеличивался
- и утилизация cpu оставалась 50%, хотя нагрузка на систему возросла.
Теперь же:
- вы нагружали проц на 50%
- и увеличиваете нагрузку на 30%
- проц разгонялся (пусть на те же 30%)
- метрика отображает увеличивающуюся нагрузку, рисуя вам 80% утилизации cpu (хотя по-факту, пока работает турбо-режим, проц нагружен наполовину)
- а если вы увеличите нагрузку вдвое, метрика покажет вам 130% утилизации cpu
Иначе говоря, старые метрики больше подходят для отображения запаса ресурсов
А новые - для отображения нагрузки на систему.
В перфмоне же доступны все метрики, и старые и новые.
Ps Надеюсь, не налажал в понимании.
Технически, можно отключать режим энергосбережения. Тогда будет шумнее, затратнее, горячее, но быстрее. Какое-то время. Потом начнется нагрев материнской платы и пропускная способность шины будет снижаться - доступ к памяти замедлится. Но если процесс работает с малым объемом памяти, и все в кеше, то он не заметит и будет работать стабильно быстро.
АК
троттлинг в нормальной станции? даже если он включился то утилизация такая что нормальным поведением это не назвать, использование ресурсов больше 80 даже процентов (пики не в счет) имхо уже повод докидывать ресурсов или что то делать с системо
А почему нет? Троттлинг это просто пропуск такта, что уменьшает доступный объём работы и снижает потребление энергии, тепловыделение, без изменения частоты ЦПУ. Когда-то давно, помнится, троттлинг мог быть организован (на уровне ос) в качестве отдельного процесса. Соответсвенно, утилизация считалась достоверно. Сейчас - не знаю 🙂
P
Технически, можно отключать режим энергосбережения. Тогда будет шумнее, затратнее, горячее, но быстрее. Какое-то время. Потом начнется нагрев материнской платы и пропускная способность шины будет снижаться - доступ к памяти замедлится. Но если процесс работает с малым объемом памяти, и все в кеше, то он не заметит и будет работать стабильно быстро.
Не понял про нагрев и шину
АК
AA
А почему нет? Троттлинг это просто пропуск такта, что уменьшает доступный объём работы и снижает потребление энергии, тепловыделение, без изменения частоты ЦПУ. Когда-то давно, помнится, троттлинг мог быть организован (на уровне ос) в качестве отдельного процесса. Соответсвенно, утилизация считалась достоверно. Сейчас - не знаю 🙂
я про то что троттлинг не появляется просто так, по идеи это высокий нагрев цпу, ну причина ес-но высокая нагрузка с которой система охлаждения не справляется
По идеи кстати современные цпу вроде и частоты режут при нагреве сильном а не только пропуск тактов
По идеи кстати современные цпу вроде и частоты режут при нагреве сильном а не только пропуск тактов
АК
Be aware that simple CPU utilization numbers may be unintuitive in the context of advanced processor features:
АК
я про то что троттлинг не появляется просто так, по идеи это высокий нагрев цпу, ну причина ес-но высокая нагрузка с которой система охлаждения не справляется
По идеи кстати современные цпу вроде и частоты режут при нагреве сильном а не только пропуск тактов
По идеи кстати современные цпу вроде и частоты режут при нагреве сильном а не только пропуск тактов
Не обязательно, зависит от железа. Если у нас нет динамического изменения множителей и плавающей частоты шины, то троттлинг решает вопрос нагрева в простое. 100% так было, может быть сейчас отказались?
АК
я про то что троттлинг не появляется просто так, по идеи это высокий нагрев цпу, ну причина ес-но высокая нагрузка с которой система охлаждения не справляется
По идеи кстати современные цпу вроде и частоты режут при нагреве сильном а не только пропуск тактов
По идеи кстати современные цпу вроде и частоты режут при нагреве сильном а не только пропуск тактов
И режут, и пропуск. Я к тому и веду, что они могут много чего делать и хрен знает как это всё учитывается. Тротлинг может не учитываться в объёме утилизации времени, а может учитываться, т.к. представлен отдельным процессом на уровне ос, например.
АК
Видит ли ОС пропущенный такст? ИМХО ответ “смотря по железу и ос”.
AA
если не видит то мы в странной ситуации когда мониторинг вроде нужен а вроде и не дает картины😱
АК
The current implementation of [CPU utilization]... shows the portion of time slots that the CPU scheduler in the OS could assign to execution of running programs or the OS itself; the rest of the time is idle... The advances in computer architecture made this algorithm an unreliable metric because of introduction of multi core and multi CPU systems, multi-level caches, non-uniform memory, simultaneous multithreading (SMT), pipelining, out-of-order execution, etc.
АК
В общем да, сфера, которая сама-по-себе даёт некислый такой оверхед, кажется считает утилизацию по старому, а именно как распределение работа-отдых внутри шедъюлера ОС и как будто бы не смотрит на частоту, буст и так далее.
АК
если не видит то мы в странной ситуации когда мониторинг вроде нужен а вроде и не дает картины😱
О чём и речь. Это может не иметь значения на больших величинах, но даже сведения вида “50% тактов ЦПУ что-то делает” не дают нам ответа, сколько реальной работы он ещё может проделать дополнительно. Может быть там все релевантные блоки и так уже заняты на 100%, а может горлышко в какой-нибудь трансляции.. но это кажется глубина, не нужная для типовых кейсов.
ВС
Не понял про нагрев и шину
Может сильно зависит от конкретной системы. Читал так - так как ОЗУ не встроена в ЦПУ, ЦПУ работает с ней по шине памяти, частота которой тоже может снижаться. В ноутбуках может более актуально, чем на серверах.
AA
Может сильно зависит от конкретной системы. Читал так - так как ОЗУ не встроена в ЦПУ, ЦПУ работает с ней по шине памяти, частота которой тоже может снижаться. В ноутбуках может более актуально, чем на серверах.
хм интересно, вот про это не слышал. но по идеи например для ryzen их шина infinityfabric точно настраивается ручками, а так выходит мы настраиваем только верхний порог?🤫
P
Может сильно зависит от конкретной системы. Читал так - так как ОЗУ не встроена в ЦПУ, ЦПУ работает с ней по шине памяти, частота которой тоже может снижаться. В ноутбуках может более актуально, чем на серверах.
у нас на тестовых стендах в грубе intel_pstate=disable и пр. - там ничего не гуляет (но это не точно)))
АК
даже при 20-30% утилизации обычно частоты уже максимальные при условии использования нескольких ядер
Собственно, возможен кейс, что предел утилизации ЦПУ, скажем, 25%. Потому что 1 из 4 серваков “должен” тянуть весь объём нагрузки “если что”. С учётом оверхеда мониторинга и логирования, там уже 4 сервака не влезут, может быть 3. Вот и получим граничное значенеи утилизации, где у нас может быть “постоянные 24%…ааааа.. всё плохо и и на грани”, либо “ооо, новый патч всё пофиксил и стало 17%!” (тогда как нагрузка возросла и частота ЦПУ стала выше).