Cpu 0 что это

Анализ счетчиков производительности CPU

У специалиста с небольшим опытом анализ счетчиков производительности CPU, как собственно и любых других, часто вызывает достаточно много сложностей и это неудивительно , учитывая многообразие счетчиков. В этой статье я постараюсь рассмотреть основные случаи, которые могут встретиться среднестатистическому админу, а также расскажу алгориты принятия решений

Если вам интересны счетчики производительности Windows, рекомендую обратиться к основной статье тематики – Счетчики производительности.

Анализ счетчиков производительности CPU

Для начала хочу уточнить один момент – существует две группы счетчиков производительности процессора, это группы Процессор (Processor) и Сведения о процессоре (Processor Information). Обе они имеют разный набор счетчиков (подробнее читайте в статье Счетчики производительности процессора), но я буду рассматривать только те из них, которые присутствуют в обоих группах. То есть вы можете использовать любую группу на ваш выбор.

В первом случае полное название счетчика (на примере % Processor Time) будет иметь вид:

\Processor Information(_Total)\% Processor Time (русскоязычная версия – \Сведения о процессоре(_Total)\% загруженности процессора)

, во втором случае:

\Processor(_Total)\% Processor Time (русскоязычная версия – \Процессор(_Total)\% загруженности процессора)

Первым делом нужно для себя определить на какие именно счетчики обращать внимание в первую очередь. В случае с основными показателями производительности CPU главным счетчиком является % Processor Time. Именно с его показаний и нужно искать проблему. При этом, по моим наблюдениям, нормальной считается средняя нагрузка до 60%, нагрузка 85% и выше уже представляет из себя большую проблему. Учитывая тот факт, что даже на стресс-тестах загрузка ЦП находится в районе 95%, то для серверов в продакшене 85% – это критическая загруженность.

Норма % Processor Time – до 60%, критическая – 85% и выше

1. Смотрим показания % Processor Time и, допустим, в вашем случае нагрузка ЦП действительно близка к критической и нужно что-то делать. Увеличивать процессорную мощность спешить не нужно, для начала посмотрите другие счетчики и уже после этого делайте выводы.

2. Чтобы на всякий случай убедиться в корректности показаний % Processor Time, открываем счетчик % Idle Time и смотрим какие средние значения он имеет. Этот счетчик показывает % простоя ЦП, то есть % времени, в которое ваш процессор не выполнял никаких задач. Следуя логике, показания этого счетчика должны быть = 100 – % Processor Time.

Норма % Idle Time обратно пропорциональна % Processor Time и составляет не ниже 40%, критическое значение – ниже 15%

С % Idle Time все в порядке, но легче нам не стало, идем дальше.

Пришло время посмотреть что нам покажут счетчики % Privileged Time и % User Time.

3. Смотрим счетчик % Privileged Time – время работы в привилегированном режиме – и если он в среднем держится выше 10%, это повод задуматься.

Норма % Privileged Time составляет 20%

Стоит отметить, что норму для % User Time определить достаточно трудно, ведь этот счетчик говорит о полезной нагрузке, которую выполняет ваш сервер. Грубо говоря, счетчик отображает % времени ЦП, которое тратится на обработку данных приложений, которые вы и запустили. Учитывая тот факт, что % Processor Time = % User Time + % Privileged Time, то в идеале значения % User Time должны стремиться к % Processor Time, а доля % Privileged Time стремиться к 0. Но это в идеале, в реальности же никак не убрать ту нагрузку, которую генерирует ядро ОС (она как раз и составляет % времени работы в привилегированном режиме).

Предположим % Privileged Time действительно показывает неприличные значения и нам надо что-то с этим делать.

4. Самое время обратиться к счетчику % Interrupt Time. Он отображает % времени, которое ЦП тратит на обработку прерываний. В идеале значение должно стремиться к 0, но на практике это бывает редко. Чаще всего нормальные значения составляют меньше 1%.

Норма % Interrupt Time – 5%

Если вы заметили ненормальные показания счетчика % Interrupt Time, это может говорить о проблемах с оборудованием, которое является причиной генерирования большого количества прерываний. Вообще отслеживать значения счетчика рекомендуется сразу после изменения аппаратной конфигурации и в случае аномального увеличения количества прерываний, принимать какие-то меры (например подобрать драйверы, с которыми устройство ведет себя лучше всего). Чтобы подкрепить свои наблюдения, можно обратить внимание на счетчик Interrupts/sec. Он показывает абсолютные значения прерываний в секунду.

Норма Interrupts/sec на каждом процессоре своя, оптимальные значения нужно определять эмпирическим путем совместно с данными % Interrupt Time

Допустим проблема была в недавно установленной сетевой карте. Вы поставили драйверы и проблема ушла сама собой и значения % Processor Time вернулись в нормальный диапазон. А что, если у вас изначально была другая ситуация? Про исключения из озвученного выше сценария я расскажу ниже.

Исключения из правил

• нехватка оперативной памяти;
• недостаточная производительность дисковой подсистемы;
• маленькая пропускная способность сетевой карты.

В этих случаях нужно обратиться к счетчикам производительности других групп и в рамках этой статьи я не буду рассматривать эти сценарии (мы ведь тут говорим о процессоре, а не о дисках или оперативке). Тем не менее, даже если проблем с RAM, HDD, сетью нет, узким местом все равно может быть процессор! Но в какую сторону копать? Для начала посмотрите показания счетчика % C3 Time. Он говорит о % времени, которое ЦП провел в одном из состояний пониженного энергопотребления, а именно в состоянии C3 (реально их значительно больше 1 ).

В норме ЦП не должен переходить в состояние C3, то есть показания % C3 Time должны быть = 0

Подкрепить ваши наблюдения поможет счетчик C3 Transitions/sec, показывающий абсолютные значения переходов в состояние C3 в секунду. Почему именно C3? Дело в том, что начиная с C3, выход из состояний занимает значительное время и ЦП может попросту заниматься не тем, чем должен. Тем не менее, бывают проблемы и с C1, C2. Есть мнение 2 , что работе всем известного сервера 1С Предприятие может очень сильно мешать переход в состояния пониженного энергопотребления и рекомендуют вообще отключать такую возможность на уровне BIOS вашего сервера (правда рекомендация касается C1E).

Постоянный мониторинг счетчиков % C1 Time, % C2 Time, C1 Transitions/sec, C2 Transitions/sec, C3 Transitions/sec на мой взгляд излишен, но периодически стоит обращать на них внимание.

Причиной может быть морально устаревшее оборудование (медленная шина данных, небольшой процессорный кэш и т.п.). В некоторых компаниях серверы могут работать десятилетиями, но придет все же тот час, когда сервер устанет и апгрейдить его возможности не будет не потому что денег нет, а потому что запчасти к нему уже давно не выпускаются. Проводите плановую замену своих “вёдер”, товарищи.

3.а Имеем норму % Privileged Time, но стабильно высокие значения % Processor Time. Это классический случай нехватки процессорной мощности для нормального выполнения возложенных на сервер задач. Единственная рекомендация – увеличьте количество vCPU (в случае с виртуальными машинами) или перенесите роли сервера на другое оборудование/произведите апгрейд имеющегося.

Пожалуй, выше были рассмотрены самые часто встречающиеся сценарии и на этом статью можно завершить. Делитесь своим опытом в комментариях.

1. Технологии энергосбережения процессоров: C-States и P-States↩
2. Настройка сервера 1С и MS SQL Server↩

Вы неверно измеряете загрузку процессора

Та метрика, которую мы называем «загрузкой процессора» на самом деле многими людьми понимается не совсем верно. Что же такое «загрузка процессора»? Это то, насколько занят наш процессор? Нет, это не так. Да-да, я говорю о той самой классической загрузке CPU, которую показывают все утилиты анализа производительности — от диспетчера задач Windows до команды top в Linux.

Вот что может означать «процессор загружен сейчас на 90%»? Возможно, вы думаете, что это выглядит как-то так:

А на самом деле это выглядит вот так:

«Работа вхолостую» означает, что процессор способен выполнить некоторые инструкции, но не делает этого, поскольку ожидает чего-то — например, ввода-вывода данных из оперативной памяти. Процентное соотношение реальной и «холостой» работы на рисунке выше — это то, что я вижу изо дня в день в работе реальных приложений на реальных серверах. Есть существенная вероятность, что и ваша программа проводит своё время примерно так же, а вы об этом и не знаете.

Что это означает для вас? Понимание того, какое количество времени процессор действительно выполняет некоторые операции, а какое — лишь ожидает данные, иногда даёт возможность изменить ваш код, уменьшив обмен данных с оперативной памятью. Это особенно актуально в нынешних реалиях облачных платформ, где политики автоматического масштабирования иногда напрямую завязаны на загрузку CPU, а значит каждый лишний такт «холостой» работы стоит нам вполне реальных денег.

Что же такое загрузка процессора на самом деле?

Та метрика, которую мы называем «загрузкой процессора» на самом деле означает нечто вроде «время не-простоя»: то есть это то количество времени, которое процессор провёл во всех потоках кроме специального «Idle»-потока. Ядро вашей операционной системы (какой бы она ни была) измеряет это количество времени при переключениях контекста между потоками исполнения. Если произошло переключение потока выполнения команд на не-idle поток, который проработал 100 милисекунд, то ядро операционки считает это время, как время, потраченное CPU на выполнение реальной работы в данном потоке.

Эта метрика впервые появилась в таком виде одновременно с появлением операционных систем с разделением времени. Руководство программиста для компьютера в лунном модуле корабля «Апполон» (передовая на тот момент система с разделением времени) называла свой idle-поток специальным именем «DUMMY JOB» и инженеры сравнивали количество команд, выполняемых этим потоком с количеством команд, выполняемых рабочими потоками — это давало им понимание загрузки процессора.

Так что в этом подходе плохого?

Сегодня процессоры стали значительно быстрее, чем оперативная память, а ожидание данных стало занимать львиную долю того времени, которое мы привыкли называть «временем работы CPU». Когда вы видите высокий процент использования CPU в выводе команды top, то можете решить, что узким местом является процессор (железка на материнской плате под радиатором и кулером), хотя на самом деле это будет совсем другое устройство — банки оперативной памяти.

Ситуация даже ухудшается со временем. Долгое время производителям процессоров удавалось наращивать скорость их ядер быстрее, чем производители памяти увеличивали скорость доступа к ней и уменьшали задержки. Где-то в 2005-ом году на рынке появились процессоры с частотой 3 Гц и производители сконцентрировались на увеличении количества ядер, гипертрейдинге, много-сокетных конфигурациях — и всё это поставило ещё большие требования по скорости обмена данных! Производители процессоров попробовали как-то решить проблему увеличением размера процессорных кэшей, более быстрыми шинами и т.д. Это, конечно, немного помогло, но не переломило ситуацию кардинально. Мы уже ждём память большую часть времени «загрузки процессора» и ситуация лишь ухудшается.

Как же понять, чем на самом деле занят процессор

Используя аппаратные счетчики производительности. В Linux они могут быть прочитаны с помощью perf и других аналогичных инструментов. Вот, например, замер производительности всей системы в течении 10 секунд:

# perf stat -a -- sleep 10 Performance counter stats for 'system wide': 641398.723351 task-clock (msec) # 64.116 CPUs utilized (100.00%) 379,651 context-switches # 0.592 K/sec (100.00%) 51,546 cpu-migrations # 0.080 K/sec (100.00%) 13,423,039 page-faults # 0.021 M/sec 1,433,972,173,374 cycles # 2.236 GHz (75.02%) stalled-cycles-frontend stalled-cycles-backend 1,118,336,816,068 instructions # 0.78 insns per cycle (75.01%) 249,644,142,804 branches # 389.218 M/sec (75.01%) 7,791,449,769 branch-misses # 3.12% of all branches (75.01%) 10.003794539 seconds time elapsed

Ключевая метрика здесь это «количество инструкций за такт» (insns per cycle: IPC), которое показывает, сколько инструкций в среднем выполнил процессор на каждый свой такт. Упрощённо: чем больше это число, тем лучше. В примере выше это число равно 0.78, что, на первый взгляд кажется не таким уж плохим результатом (78% времени выполнялась полезная работа?). Но нет, на этом процессоре максимально возможным значением IPC могло бы быть 4.0 (это связано со способом получения и выполнения инструкций современными процессорами). То есть наше значение IPC (равное 0.78) составляет всего 19.5% от максимально возможной скорости выполнения инструкций. А в процессорах Intel начиная со Skylake максимальное значение IPC уже равно 5.0.

В облаках

Когда вы работаете в виртуальном окружении, то можете и не иметь доступа к реальным счетчикам производительности (это зависит от используемого гипервизора и его настроек). Вот статья о том, как это работает в Amazon EC2.

Интерпретация данных и реагирование

Если у вас IPC > 1.0, то ваше приложение страдает не столько от ожидания данных, сколько от чрезмерного количества выполняемых инструкций. Ищите более эффективные алгоритмы, не делайте ненужной работы, кэшируйте результаты повторяемых операций. Применение инструментов построения и анализа Flame Graphs может быть отличным способом разобраться в ситуации. С аппаратной точки зрения вы можете использовать более быстрые процессоры и увеличить количество ядер.

Как вы видите, я провёл черту по значению IPC равному 1.0. Откуда я взял это число? Я рассчитал его для своей платформы, а вы, если не доверяете моей оценке, можете рассчитать его для своей. Для этого напишите два приложения: одно должно загружать процессор на 100% потоком выполнения инструкций (без активного обращения к большим блокам оперативной памяти), а второе должно наоборот активно манипулировать данным в ОЗУ, избегая тяжелых вычислений. Замерьте IPC для каждого из них и возьмите среднее. Это и будет примерная переломная точка для вашей архитектуры.

Что инструменты мониторинга производительности на самом деле должны показывать

Я считаю, что каждый инструмент мониторинга производительности должен показывать значение IPC рядом с загрузкой процессора. Это сделано, например, в инструменте tiptop под Linux:

tiptop - [root] Tasks: 96 total, 3 displayed screen 0: default PID [ %CPU] %SYS P Mcycle Minstr IPC %MISS %BMIS %BUS COMMAND 3897 35.3 28.5 4 274.06 178.23 0.65 0.06 0.00 0.0 java 1319+ 5.5 2.6 6 87.32 125.55 1.44 0.34 0.26 0.0 nm-applet 900 0.9 0.0 6 25.91 55.55 2.14 0.12 0.21 0.0 dbus-daemo

Другие причины неверной трактовки термина «загрузка процессора»

Процессор может выполнять свою работу медленнее не только из-за потерь времени на ожидание данных из ОЗУ. Другими факторами могут быть:

• Перепады температуры процессора
• Вариирование частоты процессора технологией Turboboost
• Вариирование частоты процессора ядром ОС
• Проблема усреднённых расчётов: 80% средней загрузки на периоде измерений в минуту могут не быть катастрофой, но могут и прятать в себе скачки до 100%
• Спин-локи: процессор загружен выполнением инструкций и имеет высокий IPC, но на самом деле приложение стоит в спин-локах и не выполняет реальной работы

Выводы

Загрузка процессора стала сегодня существенно недопонимаемой метрикой: она включает в себя время ожидания данных от ОЗУ, что может занимать даже больше времени, чем выполнение реальных команд. Вы можете определить реальную загрузку процессора с помощью дополнительных метрик, таких, как количество инструкций на такт (IPC). Значения меньшие, чем 1.0 говорят о том, что вы упираетесь в скорость обмена данными с памятью, а большие — свидетельствуют о большой загруженности процессора потоком инструкций. Инструменты замера производительности должны быть улучшены для отображения IPC (или чего-то аналогичного) непосредственно рядом с загрузкой процессора, что даст пользователю полное понимание ситуации. Имея все эти данные, разработчики могут предпринять некоторые меры по оптимизации своего кода именно в тех аспектах, где это принесёт наибольшую пользу.

• Блог компании Инфопульс Украина
• Высокая производительность
• Анализ и проектирование систем
• Системное программирование
• Разработка под Linux

Внезапная перезагрузка и следующая ошибка panic(cpu 0 caller 0xffffff7f972d53c5). Что необходимо исправить в системе?

Доброго времени суток!
Данная проблема возникает довольно часто и ноут уходит в перезагрузку не по моей воле, текст ее такой
Вы бы не могли подасказать, пожалуйста, что необходимо исправить в системе? Ноут был после ремонта, на него пролили жидкость и после этого он перестал заряжаться -> заменили на плате порты thunderbolt Mac 2017 года
код ошибки:
panic(cpu 0 caller 0xffffff7f972d53c5): «XHC2(MacBookPro14,2): thunderbolt power on failed 0xffffffff\n»@/AppleInternal/BuildRoot/Library/Caches/com.apple.xbs/Sources/IOPCIFamily/IOPCIFamily-370.141.1/IOPCIBridge.cpp:1398
Backtrace (CPU 0), Frame : Return Address
0xffffff914ba7ba60 : 0xffffff801651a65d
0xffffff914ba7bab0 : 0xffffff8016654a75
0xffffff914ba7baf0 : 0xffffff80166465fe
0xffffff914ba7bb40 : 0xffffff80164c0a40
0xffffff914ba7bb60 : 0xffffff8016519d27
0xffffff914ba7bc60 : 0xffffff801651a117
0xffffff914ba7bcb0 : 0xffffff8016cc1abc
0xffffff914ba7bd20 : 0xffffff7f972d53c5
0xffffff914ba7bd40 : 0xffffff7f972bcfab
0xffffff914ba7bda0 : 0xffffff7f972bd4ea
0xffffff914ba7bdc0 : 0xffffff7f972bb6d2
0xffffff914ba7be10 : 0xffffff7f972c6023
0xffffff914ba7be30 : 0xffffff8016c137e4
0xffffff914ba7bea0 : 0xffffff8016c135ea
0xffffff914ba7bec0 : 0xffffff801655c605
0xffffff914ba7bf40 : 0xffffff801655c131
0xffffff914ba7bfa0 : 0xffffff80164c013e
Kernel Extensions in backtrace:
com.apple.iokit.IOPCIFamily(2.9)[B130A8B7-967F-330E-942F-E0BB93C71C56]@0xffffff7f972b4000->0xffffff7f972ecfff

BSD process name corresponding to current thread: kernel_task

Mac OS version:
19G73

Kernel version:
Darwin Kernel Version 19.6.0: Sun Jul 5 00:43:10 PDT 2020; root:xnu-6153.141.1~9/RELEASE_X86_64
Kernel UUID: 783946EA-6F11-3647-BF90-787AEA14B954
Kernel slide: 0x0000000016200000
Kernel text base: 0xffffff8016400000
__HIB text base: 0xffffff8016300000
System model name: MacBookPro14,2 (Mac-CAD6701F7CEA0921)
System shutdown begun: NO
Panic diags file available: YES (0x0)

System uptime in nanoseconds: 164839299338777
last loaded kext at 25745412314392: >usb.cdc.acm 5.0.0 (addr 0xffffff7f99424000, size 36864)
loaded kexts:
>AudioAUUC 1.70
>!AHIDALSService 1
>AGPM 111.4.4
>!APlatformEnabler 2.7.0d0
>X86PlatformShim 1.0.0
@fileutil 20.036.15
@filesystems.autofs 3.0
>!AUpstreamUserClient 3.6.8
>!AHDAHardwareConfigDriver 283.15
>!AHDA 283.15
>!AGraphicsDevicePolicy 5.2.6
@AGDCPluginDisplayMetrics 5.2.6
>!AHV 1
|IOUserEthernet 1.0.1
|IO!BSerialManager 7.0.6f7
>!AEmbeddedOSSupportHost 1
>!A!IKBLGraphics 14.0.7
>pmtelemetry 1
@Dont_Steal_Mac_OS_X 7.0.0
>!AFIVRDriver 4.1.0
>ACPI_SMC_PlatformPlugin 1.0.0
>!A!ISlowAdaptiveClocking 4.0.0
>AGDCBacklightControl 5.2.6
>eficheck 1
>!A!IKBLGraphicsFramebuffer 14.0.7
>!AThunderboltIP 3.1.4
>!ABacklight 180.3
>!AMCCSControl 1.14
>!A!IPCHPMC 2.0.1
>!AGFXHDA 100.1.429
@filesystems.apfs 1412.141.1
>!AFileSystemDriver 3.0.1
>!AVirtIO 1.0
@filesystems.hfs.kext 522.100.5
@!AFSCompression.!AFSCompressionTypeDataless 1.0.0d1
@BootCache 40
@!AFSCompression.!AFSCompressionTypeZlib 1.0.0
>!ATopCaseHIDEventDriver 3430.1
>AirPort.BrcmNIC 1400.1.1
@private.KextAudit 1.0
>!ASmartBatteryManager 161.0.0
>!AACPIButtons 6.1
>!ARTC 2.0
>!ASMBIOS 2.1
>!AACPIEC 6.1
>!AAPIC 1.7
$!AImage4 1
@nke.applicationfirewall 303
$TMSafetyNet 8
@!ASystemPolicy 2.0.0
|EndpointSecurity 1
>usb.cdc.acm 5.0.0
>usb.serial 6.0.0
>!UMergeNub 900.4.2
>usb.!UHub 1.2
Владимир.triggers 1.0
>DspFuncLib 283.15
Владимир.OSvKernDSPLib 529
>!AGraphicsControl 5.2.6
|IOAVB!F 850.1
>!ASMBusPCI 1.0.14d1
|IO!BHost!CUARTTransport 7.0.6f7
|IO!BHost!CTransport 7.0.6f7
>IOPlatformPluginLegacy 1.0.0
>X86PlatformPlugin 1.0.0
@!AGPUWrangler 5.2.6
|IOSlowAdaptiveClocking!F 1.0.0
@!AGraphicsDeviceControl 5.2.6
|IOAccelerator!F2 438.7.3
>!AHDA!C 283.15
|IOHDA!F 283.15
>!AThunderboltEDMSink 4.2.3
>!AThunderboltDPOutAdapter 6.2.6
>!ABacklightExpert 1.1.0
>!ASMBus!C 1.0.18d1
>IOPlatformPlugin!F 6.0.0d8
|IONDRVSupport 576.1
|IOGraphics!F 576.1
>usb.IOUSBHostHIDDevice 1.2
>!A!ILpssUARTv1 3.0.60
>!A!ILpssUARTCommon 3.0.60
>!AOnboardSerial 1.0
PlugIN.IOgPTPPlugin 840.3
|IOEthernetAVB!C 1.1.0
>usb.cdc.ecm 5.0.0
>usb.cdc.ncm 5.0.0
>!UAudio 323.4
>usb.!UiBridge 1.0
>usb.cdc 5.0.0
>usb.networking 5.0.0
>usb.!UHostCompositeDevice 1.2
>!AXsanScheme 3
|IOAudio!F 300.2
@vecLib.kext 1.2.0
|IOSerial!F 11
|IOSurface 269.11
@filesystems.hfs.encodings.kext 1
>!AActuatorDriver 3440.1
>!AHIDKeyboard 209
>!AHS!BDriver 3430.1
>IO!BHIDDriver 7.0.6f7
|IO!B!F 7.0.6f7
|IO!BPacketLogger 7.0.6f7
>!AMultitouchDriver 3440.1
>!AInputDeviceSupport 3440.8
>!AHSSPIHIDDriver 59
>!AThunderboltDPInAdapter 6.2.6
>!AThunderboltDPAdapter!F 6.2.6
>!AThunderboltPCIDownAdapter 2.5.4
>!AHPM 3.4.4
>!A!ILpssI2C!C 3.0.60
>!AHSSPISupport 59
>!AThunderboltNHI 5.8.6
|IOThunderbolt!F 7.6.1
>!A!ILpssSpi!C 3.0.60
>!A!ILpssDmac 3.0.60
|IO80211!F 1200.12.2b1
>mDNSOffloadUserClient 1.0.1b8
>corecapture 1.0.4
|IOSkywalk!F 1
|IONVMe!F 2.1.0
>!A!ILpssGspi 3.0.60
>!A!ILpssI2C 3.0.60
>usb.!UXHCIPCI 1.2
>usb.!UXHCI 1.2
>usb.!UHostPacketFilter 1.0
|IOUSB!F 900.4.2
>!AEFINVRAM 2.1
>!AEFIRuntime 2.1
|IOSMBus!F 1.1
|IOHID!F 2.0.0
$quarantine 4
$sandbox 300.0
Владимир.!AMatch 1.0.0d1
>DiskImages 493.0.0
>!AFDEKeyStore 28.30
>!AEffaceable!S 1.0
>!ASSE 1.0
>!AKeyStore 2
>!UTDM 489.120.1
|IOSCSIBlockCommandsDevice 422.120.3
>!ACredentialManager 1.0
>KernelRelayHost 1
>!ASEPManager 1.0.1
>IOSlaveProcessor 1
|IOUSBMass!SDriver 157.140.1
|IOSCSIArchitectureModel!F 422.120.3
|IO!S!F 2.1
|IOUSBHost!F 1.2
>!UHostMergeProperties 1.2
>usb.!UCommon 1.0
>!ABusPower!C 1.0
|CoreAnalytics!F 1
>!AMobileFileIntegrity 1.0.5
Владимир.CoreTrust 1
|IOTimeSync!F 840.3
|IONetworking!F 3.4
|IOReport!F 47
>!AACPIPlatform 6.1
>!ASMC 3.1.9
>watchdog 1
|IOPCI!F 2.9
|IOACPI!F 1.4
@kec.pthread 1
@kec.corecrypto 1.0
@kec.Libm 1

• Вопрос задан более двух лет назад
• 4409 просмотров

2 комментария

Сложный 2 комментария

Включить все ядра процессора в Windows 10/11

15.02.2023

Max

Windows 10, Windows 11, Вопросы и ответы

комментариев 46

Почти на всех современные процессоры являются многоядерными. Все современные версии Windows поддерживают мультипроцессорные CPU и все ядра на них по умолчанию активны.

В Windows есть ограничение на максимальное поддерживаемое количество физических CPU и ядер (логических процессоров) в зависимости от версии и редакции:

Сколько процессоров и ядер доступно в Windows?

Проще всего проверить, сколько физических CPU, ядер и логических процессоров доступно в Windows с помощью Task Manager.

1. Запустите taskmgr.exe и перейдите на вкладку Performance;
2. Выберите CPU;
3. В правом окне указано количество доступных процессоров (sockets), физических ядер (24 cores) и логических процессоров (logical processors).

Логические процессоры показывают число доступных ядер с учетом того, что на компьютере включен HyperThreading.

В диспетчере устройств ( devmgmt.msc ) также отображается количество доступных логических ядер.

Также информация о физических CPU и количестве ядер на них отображается в разделе Processor утилиты msinfo32.exe

Processor Intel(R) Xeon(R) CPU E5-2673 v3 @ 2.40GHz, 2394 Mhz, 12 Core(s), 24 Logical Processor(s) Processor Intel(R) Xeon(R) CPU E5-2673 v3 @ 2.40GHz, 2394 Mhz, 12 Core(s), 24 Logical Processor(s)

Вы можете получить информацию о количестве ядер и логических процессорах с помощью PowerShell:

Get-WmiObject -class Win32_processor | ft NumberOfCores,NumberOfLogicalProcessors

NumberOfCores NumberOfLogicalProcessors ------------- ------------------------- 12 24 12 24

В переменной окружения Windows также есть информация о количестве логических процессоров в Windows:

Как включить все ядра процессора в Windows?

Если в Windows недоступны все ядра CPU, проверьте включены ли они в настройках BIOS/UEFI. Здесь могут быть два параметра:

• HyperThreading – возможность использовать оба логических процессора ядра CPU
• Active Processor Cores – разрешено ли использовать все ядра процессора

Перезагрузите Windows и войдите в настройки BIOS (обычно для этого используются клавиши F2 , Del , F10 или F1 .

Конкретные названия пунктов и их наличие зависит от версии BIOS и модели процессора. В моем случае все ядра и логические процессоры включены в разделе Processor Configuration:

• Hyper-Threading ALL: Enabled
• Active Processor Cores: All

Эти настройки могут находится в разделах Advanced, Extreme Tweaker и называться Processor Options, AMD Core Select, Processor Core, Active Processor Cores, Core Multi-Processing, CPU Cores и т.д.

Как запускать программу в Windows только на определенных ядрах?

В Windows вы можете разрешить программе выполняться только на одном или нескольких ядрах. По-умолчанию запущенное приложение Windows может выполняться на любом ядре.

Если вам нужно привязать программу к определенным ядрам, можно воспользоваться функцией Processor Affinity. Это может понадобится, если вы хотите ограничить использование CPU программой, или запускать программу только на одном ядре (это бывает нужно для запуска старых приложений, которые некорректно работают на многоядерных компьютерах.

Вы можете изменить привязку запущенного приложения к ядрам с помощью Task Manager:

Перейдите на вкладку Details;

Щелкните правой кнопкой по процессу и выберите Set affinity;

Отметьте физические ядра, на которых разрешено выполнять инструкции приложения.

Если нужно сразу запустить приложение на одном ядре, например, CPU0. Воспользуйтесь командой:

cmd.exe /c start «Acrobat DC» /affinity 1 «C:\Program Files\MyApp\yourappname.exe»

Включить все ядра Windows при загрузке

В Windows при загрузке компьютера всегда используется одно ядро. Вы можете разрешить использовать все ядра при загрузке Windows через System Configuration:

1. Запустите утилиту msconfig ;
2. Перейдите на вкладку Boot и выберите загрузочную запись вашей Windows;
3. Нажмите Advanced options;
4. Включите опцию Number of processors в окне BOOT Advanced Options;
5. Выберите количество логических процессоров (потоков), которые можно использовать при загрузке .

Вы не заметите существенного ускорения загрузки Windows, если увеличите число доступных процессоров. Кроме того, в некоторых случаях эта опция может вызвать проблемы с загрузкой Windows, особенно при включении опции PCI lock (ошибка загрузки BAD SYSTEM CONFIG INFO). Поэтому в большинстве случаев не рекомендуется включать и настраивать эту опцию.

Предыдущая статья Следующая статья