High CPU usage by the WMI Provider Host (WmiPrvSE.exe) process at regular intervals in Windows

This article provides a workaround for the issue of high CPU usage by WmiPrvSE.exe process at regular intervals.

Original product version: В Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, Window 10 — all editions
Original KB number: В 4483874

Symptoms

When you use a Windows-based computer, you notice that the Windows Management Instrumentation (WMI) Provider Host (WmiPrvSE.exe) process is using high CPU capacity (close to 100 percent) for several minutes every 15 to 20 minutes.

When the issue occurs, use Task Manager to identify the process identifier (PID) of the WmiPrvSE.exe process that’s consuming high CPU. Then, open an elevated command prompt and run the following command:

The list of WmiPrvSE.exe processes that have this module loaded will be displayed. ‎Usually only one process is listed. However, if you have both 32-bit and 64-bits clients, you may see two processes.‎ This is example output:

Image Name    PID    Modules
========== ======== ==========================
WmiPrvSE.exe   2140   WmiPerfClass.dll

If the PID of the listed process matches the one that you found in Task Manager, it is likely that you are encountering the issue that’s described in this article.

Cause

This issue can be caused by either of the following factors.

One or more processes are using a high number of handles

All the handles are stored in the kernel structure \BaseNamedObjects. The WMIPerfClass provider must scan this structure when creating the performance class that is related to the Job objects.

If this structure is bloated because of the high number of handles, the operation will have high CPU usage and will take longer than normal.

‎You may expect an impact for this condition when a process is using more than about 30,000 handles, or the total number of handles on the system exceeds 50,000.

An update that is released in March 2020 for supported operating system versions includes some performance optimization and addresses some variants of this issue. Refer to the Windows Updates history for more information on the update that applies to your Windows version.

One or more processes running on the system are using lots of memory

This affects the creation of the Process performance classes because the memory area of each running process will have to be queried. The memory that’s used by the process may be fragmented, and this makes the operation more resource-intensive. This happens because WMIPerfClass is also querying “Costly” performance counters.

‎You can check whether Costly performance counters are enabled by running the following PowerShell command:

If the command returns results, this indicates the Costly performance counters that are enabled. For example:

Win32_PerfFormattedData_PerfProc_FullImage_Costly
Win32_PerfRawData_PerfProc_FullImage_Costly
Win32_PerfFormattedData_PerfProc_Image_Costly
Win32_PerfRawData_PerfProc_Image_Costly
Win32_PerfFormattedData_PerfProc_ProcessAddressSpace_Costly
Win32_PerfRawData_PerfProc_ProcessAddressSpace_Costly
Win32_PerfFormattedData_PerfProc_ThreadDetails_Costly
Win32_PerfRawData_PerfProc_ThreadDetails_Costly

Workaround

To fix the issue, identify the process that’s using a large number of handles or a large amount of memory.‎ The process may have a memory leak or a handle leak issue. As a workaround, restart the process.

By default if you’re using Windows Server 2016 or a later version of Windows, the Costly performance counters are disabled starting from the following Cumulative Updates:

After the cumulative update is installed, if you need the classes that are related to the Costly performance counters, set the value Enable Costly Providers to 1 (DWORD) under the following registry subkey to make them available again:

The cumulative update will not affect the behavior when a process is using a large number of handles.

This issue happens when a client is querying the performance classes. This is usually a monitoring application.

As a workaround, you can also disable the monitoring application to prevent the creation of the performance classes.

More information

WMI provides several performance classes. For more information, see Performance Counter Classes.

These classes are created dynamically based on the Performance Counters that are available on the system. All the classes are created at the same time, not only the classes that are being queried.

WMIPerfClass is the module that handles creating these classes when the WMI client queries any of them or enumerates the available classes.

These performance classes are stored in a cache that’s invalidated after 15 to 20 minutes. ‎As soon as the cache is invalidated, the performance classes must be created again if a client requests them.

Высокая загрузка ЦП на SMB Server High CPU usage issue on the SMB server

В этой статье описывается, как устранить проблему высокой загрузки ЦП на сервере SMB. This article discusses how to troubleshoot the high CPU usage issue on the SMB server.

Высокая загрузка ЦП из-за проблем с производительностью хранилища High CPU usage because of storage performance issues

Проблемы с производительностью хранилища могут привести к высокой загрузке ЦП на серверах SMB. Storage performance issues can cause high CPU usage on SMB servers. Перед устранением неполадок убедитесь, что на сервере SMB установлен последний накопительный пакет обновления, чтобы устранить все известные проблемы в SRV2. sys. Before you troubleshoot, make sure that the latest update rollup is installed on the SMB server to eliminate any known issues in srv2.sys.

В большинстве случаев вы заметите проблемы высокой загрузки ЦП в системном процессе. In most cases, you will notice the issue of high CPU usage in the system process. Прежде чем продолжать, используйте обозреватель процессов, чтобы убедиться, что SRV2. sys или NTFS. sys потребляют чрезмерное количество ресурсов ЦП. Before you proceed, use Process Explorer to make sure that srv2.sys or ntfs.sys is consuming excessive CPU resources.

Сценарий сети хранения данных (SAN) Storage area network (SAN) scenario

На уровнях статистических вычислений общая производительность сети SAN может показаться неправильной. In aggregate levels, the overall SAN performance may appear to be fine. Однако при работе с проблемами SMB время ответа отдельного запроса — это наиболее важное значение. However, when you work with SMB issues, the individual request response time is what matters the most.

Как правило, эта проблема может быть вызвана некоторой формой очереди команд в сети SAN. Generally, this issue can be caused by some form of command queuing in the SAN. С помощью perfmon можно записать трассировку Microsoft-Windows-Storport и проанализировать ее, чтобы точно определить скорость реагирования хранилища. You can use Perfmon to capture a Microsoft-Windows-StorPort tracing, and analyze it to accurately determine storage responsiveness.

Задержка ввода-вывода диска Disk IO latency

Задержка ввода-вывода диска — это мера задержки между созданием и завершением запроса на ввод-вывод на диск. Disk IO latency is a measure of the delay between the time that a disk IO request is created and completed.

Задержка ввода-вывода, измеряемая в PerfMon, включает в себя все время, затраченное на аппаратные уровни, а также время, затраченное на очередь драйверов портов Майкрософт (Storport. sys для SCSI). The IO latency that is measured in Perfmon includes all the time that is spent in the hardware layers plus the time that is spent in the Microsoft Port Driver queue (Storport.sys for SCSI). Если запущенные процессы создают большую очередь Storport, то измеряемая задержка увеличивается. If the running processes generate a large StorPort queue, the measured latency increases. Это связано с тем, что операции ввода-вывода должны ожидать перед отправкой на аппаратные уровни. This is because IO must wait before it is dispatched to the hardware layers.

В PerfMon следующие счетчики показывают задержку физического диска: In Perfmon, the following counters show physical disk latency:

«Объект производительности физического диска»-> «среднее время чтения с диска (сек.)» — показывает среднюю задержку чтения. «Physical disk performance object» -> «Avg. Disk sec/Read counter» – This shows the average read latency.

«Объект производительности физического диска»-> «среднее время записи на диск (сек.)» — показывает среднюю задержку записи. «Physical disk performance object» -> «Avg. Disk sec/Write counter» – This shows the average write latency.

«Объект производительности физического диска»-> «среднее время обращения к диску (сек.)» — показывает Объединенные средние значения для операций чтения и записи. «Physical disk performance object» -> «Avg. Disk sec/Transfer counter» – This shows the combined averages for both reads and writes.

Экземпляр_Total — это среднее значение задержки для всех физических дисков на компьютере. The «_Total» instance is an average of the latencies for all physical disks in the computer. Каждый из других экземпляров представляет отдельный физический диск. Each of other instances represents an individual Physical Disk.

Не путайте эти счетчики со средним объемом обращений к диску/с. Это совершенно разные счетчики. Do not confuse these counters with Avg. Disk Transfers/sec. These are completely different counters.

Стек хранилища Windows: Windows Storage Stack follows

В этом разделе приводится краткое описание стека хранилища Windows. This section gives a brief explanation on the Windows Storage Stack follows.

Когда приложение создает запрос ввода-вывода, оно отправляет запрос в подсистему ввода-вывода Windows в верхней части стека. When an application creates an IO request, it sends the request to the Windows IO subsystem at the top of the stack. Затем операции ввода-вывода перемещаются вниз по стеку в аппаратную подсистему Disk. The IO then travels all the way down the stack to the hardware «Disk» subsystem. Затем ответ перемещается на все способы резервного копирования. Then, the response travels all the way back up. Во время этого процесса каждый слой выполняет свою функцию, а затем передает операции ввода-вывода на следующий слой. During this process, each layer performs its function and then hands the IO to the next layer.

PerfMon не создает никаких данных о производительности в секунду. Perfmon does not create any performance data per second. Вместо этого он потребляет данные, предоставляемые другими подсистемами в Windows. Instead, it consumes data that is provided by other subsystems within Windows.

Для объекта производительности «физический диск» данные фиксируются на уровне «Диспетчер секций» в стеке хранилища. For the «physical disk performance object,» the data is captured at the «Partition manager» level in the storage stack.

При измерении счетчиков, упомянутых в предыдущем разделе, мы измеряем все время, затрачиваемое запросом ниже уровня «Диспетчер секций». When we measure the counters that are mentioned in the previous section, we are measuring all the time that is spent by the request below the «Partition manager» level. Когда Диспетчер секций отправляет запрос на ввод-вывод по стеку вниз, он отмечает время. When the IO request is sent by the partition manager down the stack, we time stamp it. При возврате мы опять отметкам времени снова и вычислите разницу во времени. When it returns, we time stamp it again and calculate the time difference. Разница во времени — это задержка. The time difference is the latency.

Это делается для учета времени, затраченного на выполнение следующих компонентов: By doing this, we are accounting for the time that is spent in the following components:

Драйвер класса — управляет типом устройства, например дисками, лентами и т. д. Class Driver — This manages the device type, such as disks, tapes, and so on.

Драйвер порта — управляет транспортным протоколом, таким как SCSI, FC, SATA и т. д. Port Driver — This manages the transport protocol, such as SCSI, FC, SATA, and so on.

Драйвер минипорта устройства — это драйвер для адаптера хранилища. Device Miniport Driver — This is the device driver for the Storage Adapter. Он предоставляется изготовителем устройств, например RAID-контроллером, и FC HBA. It is supplied by the manufacturer of the devices, such as Raid Controller, and FC HBA.

Дисковая подсистема — включает все, что находится ниже драйвера минипорта устройства. Disk Subsystem — This includes everything that is below the Device Miniport Driver. Это может быть так же просто, как кабель, подключенный к одному физическому жесткому диску, или сложнее, чем сеть хранения данных. This could be as simple as a cable that is connected to a single physical hard disk, or as complex as a Storage Area Network. Если проблема определена как вызванная этим компонентом, можно обратиться к поставщику оборудования за дополнительными сведениями об устранении неполадок. If the issue is determined to be caused by this component, you can contact the hardware vendor for more information about troubleshooting.

Очередь дисков Disk queuing

Существует ограниченный объем операций ввода-вывода, которые дисковая подсистема может принимать в определенный момент времени. There is a limited amount of IO that a disk subsystem can accept at a given time. Избыточный ввод-вывод ставится в очередь до тех пор, пока диск не сможет снова принять ввод-вывод. The excess IO gets queued until the disk can accept IO again. Время, затрачиваемое вводом-выводом в очереди под уровнем «Диспетчер секций», учитывается в измерениях задержки физического диска системного монитора. The time that IO spends in the queues below the «Partition manager» level is accounted for in the Perfmon physical disk latency measurements. Так как очереди увеличиваются крупнее, а операции ввода-вывода должны ждать больше времени, измеряемая задержка также растет. As queues grow larger and IO must wait longer, the measured latency also grows.

Ниже уровня «Диспетчер секций» имеется несколько очередей, как показано ниже. There are multiple queues below the «Partition manager» level, as follows:

Очередь драйвера порта Майкрософт-порт/порт/Storport Microsoft Port Driver Queue — SCSIport or Storport queue

Очередь драйверов устройств, предоставленная изготовителем — драйвер устройства OEM Manufacturer Supplied Device Driver Queue — OEM Device driver

Очереди оборудования, такие как очередь контроллера диска, очередь коммутаторов SAN, очередь контроллера массива и очередь жестких дисков Hardware Queues – such as disk controller queue, SAN switches queue, array controller queue, and hard disk queue

Мы также будем учитывать время, затрачиваемое на то, что жесткий диск тратит на активное обслуживание операций ввода-вывода, и время, затрачиваемое на выполнение запроса на возврат к уровню «Диспетчер секций», помеченному как завершенный. We also account for the time that the hard disk spends actively servicing the IO and the travel time that is taken for the request to return to the «Partition manager» level to be marked as completed.

Наконец, необходимо уделить особое внимание очереди драйверов портов (для SCSI Storport. sys). Finally, we have to pay special attention to the Port Driver Queue (for SCSI Storport.sys). Драйвер порта — это последний компонент Майкрософт для сенсорного ввода-вывода, прежде чем мы переносимся к драйверу минипорта устройства, предоставленному изготовителем оборудования. The Port Driver is the last Microsoft component to touch an IO before we hand it off to the manufacturer-supplied Device Miniport Driver.

Если драйвер минипорта устройства не может принимать дополнительные операции ввода-вывода из-за того, что его очередь или очереди оборудования ниже, то мы начнем накопление операций ввода-вывода в очереди драйвера порта. If the Device Miniport Driver can’t accept any more IO because its queue or the hardware queues below it are saturated, we will start accumulating IO on the Port Driver Queue. Размер очереди драйвера Microsoft Port ограничивается только объемом доступной системной памяти (ОЗУ) и может увеличиваться очень большим. The size of the Microsoft Port Driver queue is limited only by the available system memory (RAM), and it can grow very large. Это приводит к большой измеряемой задержке. This causes large measured latency.

Высокая загрузка ЦП, вызванная перечислением папок High CPU caused by enumerating folders

Чтобы устранить эту проблему, отключите функцию перечисления на основе доступа (ABE). To troubleshoot this issue, disable the Access Based Enumeration (ABE) feature.

Чтобы определить, какие общие ресурсы SMB включены в параметр ABE, выполните следующую команду PowerShell: To determine which SMB shares have ABE enabled, run the following PowerShell command,

Unrestricted = ABE отключен. Unrestricted = ABE disabled.
Акцессбасе = ABE включен. AccessBase = ABE enabled.

Можно включить ABE в Диспетчер сервера. You can enable ABE in Server Manager. Перейдите к файлам и службам хранилища > Общие папки, щелкните общую папку правой кнопкой мыши, выберите пункт » Свойства«, перейдите в раздел » Параметры » и выберите » включить перечисление на основе доступа«. Navigatie to File and Storage Services > Shares, right-click the share, select Properties, go to Settings and then select Enable access-based enumeration.

Кроме того, можно уменьшить абелевел до более низкого уровня (1 или 2), чтобы повысить производительность. Also, you can reduce ABELevel to a lower level (1 or 2) to improve performance.

Если перечисление работает медленнее, можно проверить производительность диска, открыв папку локально через консоль или сеанс RDP. You can check disk performance when enumeration is slow by opening the folder locally through a console or an RDP session.