Когда диспетчер задач сообщает вам, что процессор загружен на все 100 %, вы можете подумать, что система работает изо всех сил и не имеет дополнительных вычислительных мощностей. А когда диспетчер задач сообщает о том, что ЦП загружен на 40 %, вы интуитивно полагаете, что он потребляет 40 % от всей общей доступной мощности. То было достаточно точное толкование как в Windows 7, так и Windows Server 2008 R2. Но с выходом нового дизайна, впервые представленного в Windows 8, вкладки Процессы и Производительность диспетчера задач теперь полагаются на разные метрики и показывают цифры, которые вводят в заблуждение и которые без дополнительного контекста совершенно бессмысленны.
Изменения диспетчера задач были предназначены для учета достижений в технологии микросхем. Относительно просто определить загрузку процессора: сколько времени в течение заданного интервала он тратит в режиме занятости против простаивания (*). Раньше, когда процессоры всегда работали с заданной частотой, простая арифметика говорила вам, сколько работы выполнял процессор. Современные процессоры предлагают улучшения в области энергоэффективности. Например, работают на пониженных частотах или полностью выключаются в периоды низкой потребляемой мощности, а ядро процессора работает быстрее, чем указанная частота в периоды повышения потребления мощности. Следовательно, загрузка ЦП сама по себе больше не дает нам столько информации, сколько она давала раньше, о том, сколько выполняется обработка.
(*) В более ранних версиях Windows это были грубые приближения. Точность доступных показателей улучшилась от Windows XP к Vista, а потом и к Win7, как и в соответствующих им серверных версиях ОС.
Чтобы попытаться учесть эти сложности, Windows ввела понятие служебной программы процессора вместе со счетчиками производительности, которые измеряют эту служебную программу. Windows определяет полезность процессора как объем выполненной работы в процентах от объема работы, которую он мог бы выполнить, если бы он постоянно работал на своем номинальном уровне производительности и никогда не включал режим повышенной производительности. Когда процессор включает режим повышенной производительности обычное вообще явление его процент полезности может легко превысить 100 %. Возможная верхняя граница неопределенна и зависит от множества факторов, которые Windows не может измерить напрямую. Вкладки Процессы и Производительность диспетчера задач теперь используют счетчик процент полезности процессора в качестве основы для показания их загруженности, а не счетчик процент загруженности процессора, на который полагался Диспетчер задач, который по-прежнему используется вкладкой Подробности диспетчера задач и Process Explorer, входящий в комплект Sysinternals.
В результате, поскольку динамически настраиваемые процессоры автоматически переходят в расширенный режим под нагрузкой, процент загруженности ЦП диспетчера задач на процесс, который активно выполняет код, обычно будет значительно больше, чем время его процессора. Но поскольку это число находится на шкале, которая ограничена 100 %, диспетчер задач создает впечатление, что процесс занимает больше вычислительных мощностей системы, чем есть на самом деле. Некоторое время сам диспетчер задач сообщал об общей загрузке ЦП более 100 %. Поскольку это противоречит здравому смыслу даже для людей, которые понимают концепцию полезности, диспетчер задач теперь ограничивает сообщаемые значения на отметке в 100 %. Это приводит в дальнейшем еще к большему искажению. Я покажу.
На приведенных ниже скриншотах Process Explorer и вкладка Производительность диспетчера задач подтверждают, что ровно половина из двенадцати потоков полностью загружены, а остальные процессоры почти полностью простаивают. Однако обратите внимание, что Process Explorer сообщает об общем проценте загруженности ЦП чуть более 50, а диспетчер задач сообщает о 83. Возможно, это должно быть 83 % по шкале 166 %. Но что это вообще значит? Процент буквально означает на сотню. Вкладка Производительность диспетчера задач также показывает, что базовая частота процессоров составляет 2,40 ГГц, но во время этого измерения скорость составляет 3,94 ГГц. Получается, что 83 % умножить на 2,40/3,94 это 50,56%, что близко к фактическому использованию. 83 процента в данном случае фактически находятся во временной шкале 164,17 (100 %*3,94/2,40). Это объясняет, как получаются числа, но не делает их интуитивно понятными или значимыми.
Диалоговое окно "Информация о системе" в
Process Explorer
Вкладка "Производительность" диспетчера задач
На вкладке Процессы диспетчера задач указано, что моя тестовая программа потребляет 82,8 %, то есть почти все из 83 % общего использования, о которых она сообщает. В то же время на вкладке Подробности диспетчера задач указано, что моя программа потребляет 50 % ресурсов ЦП. Цифры на вкладке "Подробности", основанные на "проценте загруженности процессора", а не на "процент полезности процессора" и более понятны, чем числа на вкладке "Процессы".
Вкладка "Процессы" диспетчера задач
И его
вкладка "Подробности"
Давайте возьмем его на ступеньку выше и запустим восемь потоков, привязанных к потокам ЦП, задействуя две трети процессора, оставив остальные простаивать. Вкладка Производительность диспетчера задач сообщает о 100 % загрузке ЦП, подразумевая, что система работает на максимальной мощности, в то время, как и она, и Process Explorer ясно показывают, что четыре из двенадцати процессоров простаивают и готовы к работе. На вкладке Процессы диспетчера задач указано, что тестовая программа использует 100 % ЦП, а на вкладке Подробности указано, что она потребляет только 67 % две трети доступной вычислительной мощности.
Process Explorer
Вкладка "Производительность" диспетчера задач
Вкладка "Процессы" диспетчера задач
Вкладка "Сведения" диспетчера задач
Суть в том, что показатели ЦП в диспетчере задач могут вводить в заблуждение, противоречащие здравому смыслу и в конечном итоге бессмысленны. Процент полезности процессора это в лучшем мистическая система мер, Диспетчер задач и не может выступать в качестве диагностической утилиты для конечного пользователя.
Здесь можно взглянуть на точку зрения моего коллеги Джеффа Стоукса по поводу данного вопроса.
