Високе навантаження CPU процесу System? Часто це драйвер — як це довести

February 12, 2026 • February 12, 2026 • Читання: 6 хв • Views: 0

Було корисно?

Ви відкриваєте Диспетчер завдань, бо система відчувається «липкою». RDP підвисає, аудіо потріскує, затримки на зберіганні ростуть, або ваші CI-агенти раптом працюють так, ніби їх живить картопля.
І ось воно: System жере CPU. Не ваш додаток. Не ваш сервіс. Просто… «System».

«System» — це ввічливий спосіб Windows сказати «час у ядрі горить». Хороша новина: найбільше випадків — це проблема з драйвером (або конфігурацією, пов’язаною з драйвером),
і ви можете довести це трасуваннями, лічильниками та кількома жорсткими експериментами — без гадань, перевстановлення Windows або звинувачень мережі як хобі.

Що насправді таке процес «System» (і чого він не є)

Процес System (PID 4 на більшості систем) не є «програмою» в тому сенсі, як ваш сервіс. Це контейнер для роботи в режимі ядра:
потоків, які виконуються в ядрі Windows та драйверів ядра. Коли він сильно навантажує CPU, щось у режимі ядра спалює цикли — часто обробляючи переривання,
виконуючи DPC (Deferred Procedure Calls) або опрацьовуючи I/O-шляхи.

Кілька уточнень, які врятують від дурних рішень на ранньому етапі:

Високе System CPU не є доказом наявності шкідливого ПЗ. Шкідливе ПЗ може його спричинити, але «System» частіше означає, що драйвер накопичив проблеми або має погану конфігурацію.
Високе System CPU не є багом застосунку — аж поки ним не стане. Застосунки можуть провокувати шляхи ядра (наприклад, I/O шторм, дрібні записи, mmap-ресурсне потрясіння), що виводять на явні дефекти драйвера або неправильні налаштування.
«System interrupts» у Диспетчері завдань — це симптом, а не процес. Це час, витрачений на обслуговування апаратних переривань, що теж зазвичай оповідає про драйвер чи апарат.
Вимикати випадкові сервіси рідко допомагає. Час у ядрі не турбує ваш індексатор Windows Search, коли черга DPC плавиться.

Мета не в тому, щоб «знизити System CPU» як естетичну задачу. Мета — ідентифікувати, який саме компонент ядра споживає час і чому,
а потім вибрати найменш ризикований крок виправлення: оновлення/відкат драйвера, виправлення прошивки, налаштування оффлоадів, видалення фільтр-драйвера,
корекція глибини черги або заміна проблемного пристрою.

Цікаві факти та трохи історії (бо це не почалося вчора)

«System» як видимий процес бере початок від лінійки NT — архітектури, яка підкреслювала чіткий поділ між користувацьким та ядерним режимами з усталеними моделями драйверів.
DPC існують тому, що не все можна робити в обробнику переривань. Обробники переривань мають бути швидкими; важку роботу відкладають у DPC, який все ще виконується з підвищеним пріоритетом.
ETW (Event Tracing for Windows) працює з Windows 2000 і досі є найнадійнішим способом довести, куди пішов час ядра.
Storport замінив старі сторідж-порт драйвери для продуктивності та масштабованості, але коли він працює неправильно, це робить це голосно: високий CPU, скидання та стрибки затримок.
NDIS оффлоади — це подарунок і прокляття для відладки: checksum offload, LSO, RSC, RSS. Добре, коли все правильно; драматично, коли є баг.
Фільтр-драйвери всюди: антивірус, DLP, агенти бекапу, шифрування, снапшоти, моніторинг. Вони сидять у «гарячих» шляхах і можуть перетворити «нормально» на «таємничо погано».
Планувальник і маршрутизація переривань Windows змінились між версіями (і апаратними поколіннями). Драйвер, що «працював на 2016», може поводитися інакше на 2022 з сучасними ядрами та NUMA.
Модерація переривань стала масовою через лінійний мережевий трафік. Зроблена неправильно — створює затримки; зроблена надто «агресивно» — породжує інтеррупти-шторм.
Високе CPU іноді ховає проблему живлення або прошивки. C-states, мікрокод BIOS і баги у прошивці проявляються як дивна поведінка переривань або таймерні штормі.

Корисна ментальна модель: час ядра рідко «випадковий». Частіше це петля, черга, шторм або повторна спроба.
Ваше завдання — знайти ту чергу.

Швидкий план діагностики (перші/другі/треті перевірки)

Перше: класифікуйте навантаження на CPU (user vs kernel vs interrupts)

Чи загальне завантаження CPU високе, чи лише одне ядро завантажене?
Чи час знаходиться в Kernel time (привілейований), чи в User time?
Чи Диспетчер завдань показує високий System та/або високі System interrupts?

Якщо домінує час ядра, перестаньте дивитися на flame-graph ваших застосунків і почніть збирати докази з ядра.

Друге: вирішіть, чи це I/O, мережа або «дивне обладнання»

Підозри щодо зберігання: висока затримка диска, довжина черги, попередження Storport, скидання, фільтр-драйвери, зміни multipath.
Підозри щодо мережі: втрати пакетів, повторні передачі, високі переривання на NIC, перемикання оффлоадів, попередження NDIS.
Підозри щодо дивного обладнання: USB-пристрої, аудіо, GPU, чіпсет, таймери енергозбереження.

Третє: захопіть доказ, який можна показати вендору або комітету змін

ETW-трейс (WPR/WPA), орієнтований на використання CPU драйвером, ISR, DPC.
Лічильники продуктивності для частоти переривань/DPC, затримок диска/черги, пакетів/переривань мережі.
Журнали подій: канал System для Storport, Disk, NVMe, NDIS, WHEA апаратних помилок.

Якщо ви не можете побудувати часову шкалу, що корелює «сплеск CPU» з «рутиною драйвера, яка домінує в DPC/ISR» або «штормом скидань storport», у вас не доказ — у вас відчуття.

Як довести, що це драйвер: ланцюжок доказів

Заява «це драйвер» — це твердження. Щоб перетворити її на доказ, потрібен ланцюжок доказів, який витримає допит у war room:
симптоми → вимірювання → атрибуція → контрольована зміна → результат.

1) Симптоми: те, що помічають користувачі, відповідає режимам збоїв ядра

Затримки в RDP, затримки клавіатури: часто тиск переривань/DPC, що призводить до голодування звичайних потоків.
Сплески затримки зберігання: Storport, NVMe-драйвер, прошивка HBA, фліпання multipath, фільтр-драйвери.
Мережеві джитери: переривання NIC, проблеми оффлоадів, некоректна налаштування RSS, баги в чергах драйвера.
Потріскування аудіо (на десктопах): класичні симптоми високої затримки DPC.

2) Вимірювання: підтвердіть, що проблема справді в часі ядра

Використовуйте лічильники та трасування. Не покладайтеся на один скріншот Диспетчера завдань, ніби це медична діагностика.

3) Атрибуція: ідентифікуйте компонент ядра, який виконує роботу

Тут перемагає ETW. Ви хочете бачити CPU sampled stacks, які приводять до модуля драйвера (наприклад, storport.sys, stornvme.sys, ndis.sys,
драйвер виробника NIC, фільтр шифрування, антивірусний мініфільтр).

4) Контрольована зміна: ізолюйте, не знищивши продукцію

Вибирайте зміни, що можна відкотити і які безпечні: відкат драйвера, вимкнення одного оффлоаду, відключення фільтр-драйвера у вікні обслуговування,
перемикання порту NIC, міграція VM на інший хост або зміна глибини черги. Потім перевиміряйте.

5) Результат: покажіть «до/після» тими самими інструментами

Якщо частота DPC падає, час ядра знижується, а затримки нормалізуються після вашої зміни — у вас є причинно-наслідковий зв’язок. Якщо ні — копайте далі.

Парафраз ідеї Вернера Фогельса (надійність/операції): «Усе рано чи пізно ламається; стійкі системи припускають відмову і автоматично відновлюються.»
У цьому контексті: припускайте, що драйвери можуть зламатися, і виробіть відтворювані докази та плани відкату у своїй оперативній пам’яті.

Практичні завдання: команди, виводи, значення та рішення (12+)

Тут навмисно перевага віддається тому, що ви можете зробити на реальному Windows Server без інсталяції підозрілих інструментів. Деякі завдання використовують вбудовані утиліти,
деякі — компоненти Windows Performance Toolkit, які часто вже є в корпоративних образах. Запускайте від імені Адміністратора, якщо не вказано інакше.

Завдання 1: Швидко підтвердити kernel vs user CPU (typeperf)

cr0x@server:~$ typeperf "\Processor(_Total)\% Privileged Time" "\Processor(_Total)\% User Time" -sc 5
"(PDH-CSV 4.0)","\\SERVER\Processor(_Total)\% Privileged Time","\\SERVER\Processor(_Total)\% User Time"
"02/04/2026 09:12:01.123","42.187500","7.031250"
"02/04/2026 09:12:02.125","45.312500","6.250000"
"02/04/2026 09:12:03.126","44.531250","5.468750"
"02/04/2026 09:12:04.128","46.093750","6.640625"
"02/04/2026 09:12:05.129","43.750000","6.250000"

Що це означає: Привілейований час значно перевищує користувацький. Це виконання в ядрі — драйвери, підпрограми ядра, переривання.

Рішення: Перестаньте оптимізувати застосунки. Почніть атрибутувати час ядра (DPC/ISR, драйвери, I/O-шляхи).

Завдання 2: Перевірити частоту переривань і час DPC (typeperf)

cr0x@server:~$ typeperf "\Processor(_Total)\Interrupts/sec" "\Processor(_Total)\% DPC Time" "\Processor(_Total)\% Interrupt Time" -sc 5
"(PDH-CSV 4.0)","\\SERVER\Processor(_Total)\Interrupts/sec","\\SERVER\Processor(_Total)\% DPC Time","\\SERVER\Processor(_Total)\% Interrupt Time"
"02/04/2026 09:13:10.111","182345.000000","28.125000","6.250000"
"02/04/2026 09:13:11.112","190220.000000","30.468750","6.640625"
"02/04/2026 09:13:12.114","188900.000000","29.687500","6.250000"
"02/04/2026 09:13:13.116","191450.000000","31.250000","6.640625"
"02/04/2026 09:13:14.117","187300.000000","29.296875","6.250000"

Що це означає: Interrupts/sec дуже велике; час DPC підвищений. Класична територія «шторм переривань/DPC».

Рішення: Ідентифікуйте, який пристрій/драйвер генерує переривання (часто NIC або зберігання). Перейдіть до ETW і кореляції з пристроями.

Завдання 3: Побачити перекіс по ядрах (одне ядро зайняте перериваннями)

cr0x@server:~$ typeperf "\Processor(0)\% Interrupt Time" "\Processor(1)\% Interrupt Time" "\Processor(2)\% Interrupt Time" "\Processor(3)\% Interrupt Time" -sc 3
"(PDH-CSV 4.0)","\\SERVER\Processor(0)\% Interrupt Time","\\SERVER\Processor(1)\% Interrupt Time","\\SERVER\Processor(2)\% Interrupt Time","\\SERVER\Processor(3)\% Interrupt Time"
"02/04/2026 09:14:30.010","18.750000","0.000000","0.000000","0.000000"
"02/04/2026 09:14:31.011","20.312500","0.000000","0.000000","0.000000"
"02/04/2026 09:14:32.013","19.531250","0.000000","0.000000","0.000000"

Що це означає: Одне CPU виконує роботу переривань. Часто вказує на проблеми з афінітетами переривань/маршрутизацією, неправильну налаштування RSS або пристрій застрягший на одному ядрі.

Рішення: Перевірте RSS NIC, модерацію переривань і драйвери; розгляньте BIOS/firmware і драйвери чіпсету.

Завдання 4: Знайти шумні події в System логах (зберігання/мережа/апарат)

cr0x@server:~$ wevtutil qe System /q:"*[System[(Level=2 or Level=3) and TimeCreated[timediff(@SystemTime) <= 3600000]]]" /f:text /c:20
Event[0]:
  Log Name: System
  Source: storport
  Date: 2026-02-04T09:02:11.0000000Z
  Event ID: 129
  Level: Warning
  Description:
    Reset to device, \Device\RaidPort3, was issued.

Event[1]:
  Log Name: System
  Source: Disk
  Date: 2026-02-04T09:02:12.0000000Z
  Event ID: 153
  Level: Warning
  Description:
    The IO operation at logical block address ... was retried.

Що це означає: Скидання Storport і повтори диска сильно корелюють зі сплесками CPU ядра і затримками. Шторм скидань дорого обходиться.

Рішення: Розглядайте це як проблему шляху зберігання поки не доведено протилежне: драйвер/firmware, HBA, multipath, SAN, кабелі, прошивка NVMe, фільтр-драйвери.

Завдання 5: Перевірити WHEA апаратні помилки (мовчазні саботажники)

cr0x@server:~$ wevtutil qe System /q:"*[System[Provider[@Name='Microsoft-Windows-WHEA-Logger'] and TimeCreated[timediff(@SystemTime) <= 86400000]]]" /f:text /c:10
Event[0]:
  Log Name: System
  Source: Microsoft-Windows-WHEA-Logger
  Date: 2026-02-04T02:44:19.0000000Z
  Event ID: 17
  Level: Warning
  Description:
    A corrected hardware error has occurred.

Що це означає: Виправлені помилки все одно коштують часу і можуть дестабілізувати драйвери (особливо для зберігання та PCIe-пристроїв).

Рішення: Витягніть версії прошивок, перевірте стан PCIe/NVMe і не ігноруйте виправлені помилки у кластері.

Завдання 6: Перелік драйверів і їх версій (швидкий список підозрюваних)

cr0x@server:~$ driverquery /v /fo table | findstr /i "storport stornvme ndis wdf01000"
storport.sys                10.0.20348.1      Kernel Driver
stornvme.sys                10.0.20348.1      Kernel Driver
ndis.sys                    10.0.20348.1      Kernel Driver
Wdf01000.sys                10.0.20348.1      Kernel Driver

Що це означає: Це показує лише основні компоненти Microsoft. Потрібно також бачити драйвери виробників (NIC/HBA) і фільтри (AV, бекап).

Рішення: Перелічіть немайкрософтові драйвери далі; якщо драйвер вендора нещодавно оновлювали, у вас є головний підозрюваний.

Завдання 7: Перелічити немайкрософтові драйвери (PowerShell)

cr0x@server:~$ powershell -NoProfile -Command "Get-CimInstance Win32_PnPSignedDriver | ? {$_.DriverProviderName -notmatch 'Microsoft'} | select DeviceName,DriverProviderName,DriverVersion,InfName | sort DriverProviderName | ft -Auto"
DeviceName                      DriverProviderName   DriverVersion     InfName
Intel(R) Ethernet Controller    Intel                2.1.4.0           oem42.inf
Vendor NVMe Controller          Contoso Storage Inc.  1.9.12.3          oem18.inf
Virtual Bus Enumerator          Fabrikam Virtual      3.2.0.7           oem77.inf

Що це означає: Тепер у вас є назви та версії драйверів виробників. Зіставте їх з хронологією змін.

Рішення: Якщо час збігається з розгортанням, протестуйте відкат на одній ноді (або перемістіть навантаження) і виміряйте знову.

Завдання 8: Перевірити фільтр-драйвери в стеку зберігання (fltmc)

cr0x@server:~$ fltmc filters
Filter Name                     Num Instances    Altitude    Frame
------------------------------  -------------    --------    -----
WdFilter                        12              328010      0
FileInfo                        12              45000       0
ContosoDlpFilter                12              370000      0
FabrikamBackupSnap              12              385000      0

Що це означає: Мініфільтри перехоплюють файлові I/O. Якщо час ядра високий під час інтенсивної роботи з диском, фільтри — часті підозрювані.

Рішення: Якщо на серверах є нефундаментальні фільтри (особливо агенти), плануйте контрольоване вимкнення/деінсталяцію на одному хості.

Завдання 9: Подивитися, до яких томів і екземплярів прикріплені фільтри (fltmc instances)

cr0x@server:~$ fltmc instances
Filter                      Volume Name                     Instance Name                 Altitude    Frame
--------------------------  ------------------------------  ----------------------------  --------    -----
ContosoDlpFilter            \Device\HarddiskVolume3         ContosoDlpFilter Instance     370000      0
FabrikamBackupSnap          \Device\HarddiskVolume3         FabrikamBackupSnap Instance   385000      0
WdFilter                    \Device\HarddiskVolume3         WdFilter Instance             328010      0

Що це означає: Якщо «гарячий» том збігається з тим, де стек фільтрів щільний, у вас правдоподібне підсилення гарячого шляху.

Рішення: Розгляньте, чи бізнес-цінність кожного фільтра виправдовує ризик продуктивності та надійності; якщо так — налаштуйте виключення/шлях.

Завдання 10: Захопити ETW-трейс WPR для CPU + DPC/ISR

cr0x@server:~$ wpr -start CPU -start DiskIO -start Network -filemode
WPR started. Logging to file...

Що це означає: Ви записуєте події ядра. Відтворіть проблему 30–120 секунд, потім зупиніть.

Рішення: Якщо ви можете відтворити, ви можете довести. Якщо не можете — логайте довше і корелюйте з часовими мітками скарг.

Завдання 11: Зупинити трейc і зберегти його (WPR)

cr0x@server:~$ wpr -stop C:\Temp\system-highcpu.etl
WPR stopped. ETL saved to: C:\Temp\system-highcpu.etl

Що це означає: У вас тепер є ETL-файл, який можна відкрити у Windows Performance Analyzer (WPA) щоб побачити використання CPU за стеком і модулем.

Рішення: Відкрийте ETL у WPA і подивіться CPU Usage (Sampled), DPC/ISR та call stacks. Якщо «гарячий» стек вказує на драйвер — у вас атрибуція.

Завдання 12: Швидкий знімок лічильників для затримки диска і черги

cr0x@server:~$ typeperf "\PhysicalDisk(_Total)\Avg. Disk sec/Read" "\PhysicalDisk(_Total)\Avg. Disk sec/Write" "\PhysicalDisk(_Total)\Current Disk Queue Length" -sc 5
"(PDH-CSV 4.0)","\\SERVER\PhysicalDisk(_Total)\Avg. Disk sec/Read","\\SERVER\PhysicalDisk(_Total)\Avg. Disk sec/Write","\\SERVER\PhysicalDisk(_Total)\Current Disk Queue Length"
"02/04/2026 09:18:01.000","0.035","0.120","48.000"
"02/04/2026 09:18:02.000","0.041","0.140","52.000"
"02/04/2026 09:18:03.000","0.038","0.131","49.000"
"02/04/2026 09:18:04.000","0.040","0.152","56.000"
"02/04/2026 09:18:05.000","0.039","0.145","54.000"

Що це означає: Записи повільні, черги глибокі. Час ядра може рости через повтори, скидання і шторм виконань завершень I/O.

Рішення: Підтвердіть за подіями Storport/Disk і ETW Disk I/O; розслідуйте драйвер/прошивку зберігання і стек фільтрів.

Завдання 13: Перевірити мережеві помилки та стан оффлоадів (netsh)

cr0x@server:~$ netsh int tcp show global
Querying active state...

TCP Global Parameters
----------------------------------------------
Receive-Side Scaling State          : enabled
Receive Segment Coalescing State    : enabled
Chimney Offload State               : disabled
NetDMA State                        : disabled
Direct Cache Access (DCA)           : disabled

Що це означає: Налаштування RSC/RSS мають значення. Якщо ви бачите високі переривання і CPU, баги оффлоадів або невідповідність налаштувань — підозра.

Рішення: Якщо ETW вказує на NDIS/NIC драйвер, тестуйте по черзі вимкнення оффлоадів на одному хості, потім перевиміряйте.

Завдання 14: Перевірити RSS-черги та відображення на CPU (PowerShell)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetAdapterRss | ft -Auto"
Name           Enabled  NumberOfReceiveQueues  MaxNumberOfReceiveQueues  ProcessorGroup  BaseProcessorNumber
----           -------  ---------------------  ------------------------  --------------  -------------------
Ethernet0      True     2                      16                        0               0

Що це означає: Якщо NIC 25/40/100Gb працює з 1–2 чергами, ви можете отримати проблему з завантаженням одного ядра.

Рішення: Збільшіть кількість черг (в межах рекомендацій виробника), забезпечте сумісність VMQ/RSS і перевірте розподіл переривань.

Завдання 15: Зіставити CPU «System» з конкретним модулем драйвера через live kernel sampling (xperf)

cr0x@server:~$ xperf -on PROC_THREAD+LOADER+PROFILE -stackwalk Profile -buffersize 1024 -MaxFile 256 -FileMode Circular -f C:\Temp\cpu-kernel.etl
xperf: Tracing session started.

cr0x@server:~$ timeout /t 60
Waiting for 60 seconds, press a key to continue ...

cr0x@server:~$ xperf -d C:\Temp\cpu-kernel.etl
xperf: Tracing session stopped.
xperf: Trace merged and written to C:\Temp\cpu-kernel.etl

Що це означає: Це CPU sampling trace, який можна відкрити в WPA. «CPU Usage (Sampled)» зі стеком часто висвітлює «гарячу» рутину драйвера.

Рішення: Якщо стеки сходяться на драйвері, ви перейшли від «можливо» до «доведено».

Завдання 16: Ідентифікувати процеси-порожні київці, що викликають шляхи ядра (перевірка I/O шторму)

cr0x@server:~$ powershell -NoProfile -Command "Get-Process | sort CPU -desc | select -first 10 Name,Id,CPU,WorkingSet64 | ft -Auto"
Name            Id    CPU  WorkingSet64
----            --    ---  ------------
System           4  942.2  287031296
sqlservr      2312  120.4  7423913984
MsMpEng       1880   88.7  514883584
svchost       1020   40.1  221421568

Що це означає: «System» зверху, але процеси користувача, як AV або база даних, можуть створювати навантаження, яке провокує накладні витрати ядра.

Рішення: Якщо ETW показує інтенсивний файловий I/O з витратами мініфільтра, налаштуйте виключення; якщо є скидання зберігання — спочатку фокус на шляху зберігання.

Жарт №1: Процес «System» — це співробітник, який завжди каже «я на нарадах» — і якось ваш проєкт все одно провалюється.

Три корпоративні міні-історії з реальних боїв

Міні-історія 1: Інцидент через хибне припущення

Середній фінтех мав флот VM на Windows Server для обробки інгесту повідомлень та шифрування. В один понеділок після планового вікна змін
інженер на виклику побачив, що CPU у кількох нодів зашкалює. Диспетчер завдань вказував на «System» і «System interrupts». Рефлекс: «Наш сервіс інгесту протікає потоками».

Команда масштабувала сервіс, подвоїла воркерів черги і навіть підправила налаштування GC. Нічого не допомогло. Флот став більш нестабільним, бо вони збільшили пропускну здатність у вузьке місце ядра.
Клієнти повідомляли про випадкові тайм-аути; дашборди показували зростання затримки запису на диск.

Хибне припущення було простим: «Якщо CPU високий — це user space». Вони не вимірювали привілейований час. Не перевіряли частоту DPC/переривань.
Не дивилися в System event log, бо «він завжди шумить».

Коли хтось нарешті зробив швидку перевірку лічильників, привілейований час домінував і переривання були абсурдними. Журнали подій показали скидання Storport.
ETW-трейси виявили CPU-стеки, які проводили час у рутині завершення збереження — узгоджувалося зі сценарієм драйвера, що скидує шлях повторно.

Причина: оновлення прошивки зберігання на хост-кластері вступило в протиріччя зі специфічною конфігурацією віртуального HBA. Відкат прошивки
(або переміщення VM на незатронуті хости) стабілізував середовище. Сервіс інгесту був у нормі; він просто кричав у зламаний шлях зберігання.

Тривкий урок: перш ніж торкатись вашого застосунку, класифікуйте CPU. Якщо це час ядра, сприймайте застосунок як генератор навантаження, а не підозрюваного.

Міні-історія 2: Оптимізація, яка відкотилася

Рітейл-компанія мала внутрішній файловий pipeline на Windows серверах з великим мережевим трафіком. Хтось помітив CPU-накладні витрати на приймачах
і запропонував увімкнути «усі оффлоади» на NIC, щоб знизити CPU хоста. Зміна була схвалена, бо звучала як безкоштовна оптимізація.

Спочатку CPU впав у бенчмарках. Потім в проді трафік у реалі: випадкові розміри пакетів, хвилі і мікс TLS та plaintext. За кілька годин
декілька нод почали показувати високий «System» CPU, і затримки погіршилися. Мережеві дашборди відзначали дивні мікропросадки і періодичні втрати.

ETW-трейси показали: час згорає в NDIS і драйвері NIC виробника, домінує обробка DPC. Модерація переривань була налаштована занадто агресивно для профілю трафіку,
і один шлях оффлоаду був багатий багом під навантаженням pipeline. Система не стала «швидшою»; вона коливалась між згорнутими бурстами та затримками DPC.

Команда відкотила зміни, потім по черзі повертала оффлоади, перевіряючи лічильники: interrupts/sec, DPC time і кінцеву затримку.
Вони зберегли RSS і налаштували кількість черг, але відключили проблемний оффлоад. CPU трохи піднявся, але jitter сильно впав — а jitter був справжнім порушником SLO.

Урок: «оптимізація CPU», що ігнорує хвостову затримку, дає швидку систему, яка відчувається повільною. І ще: трушення десяти налаштувань NIC одночасно — це не експеримент, а танець інтуїції.

Міні-історія 3: Нудна але правильна практика, що врятувала день

Healthcare SaaS тримав Windows-app сервери з суворим контролем змін. SRE команда підтримувала матрицю драйверів і прошивок: затверджені версії для NIC,
контролера зберігання, чіпсету, плюс документований план відкату. Це не було гламурно. Це були переважно таблиці та «ні, сьогодні оновлювати не можна».

Одного кварталу продавець випустив новий драйвер NIC через advisory з безпеки. Security хотіли розгорнути негайно.
Ops погодилися — але лише після стаджингу на канарці з типовою процедурою ETW під навантаженням.

Канарка одразу показала підвищений DPC time і більше interrupts/sec під специфічним профілем трафіку. Не катастрофа, але вимірено і тренд був поганий.
Вони призупинили розгортання, відкрили кейс у виробника з ETW-доказами і продовжили використовувати раніше затверджену версію при альтернативних заходах.

Через два тижні виробник надав виправлення. Канарка була чистою. Розгортання пройшло без інцидентів.
Ніхто не писав героїчний постмортем, бо нічого не впало. Оце і є суть.

Урок: нудні контролі — матриці версій, канарки, відтворювані трейсування — перемагають адреналін будь-коли.

Жарт №2: Якщо ви не зібрали трейс, ваш корінь проблеми — «вібрації були погані», і фінанси точно не приймуть це як статтю витрат.

Зберігання і CPU «System»: звичні підозрювані (Storport, фільтри, черги)

Проблеми зі зберіганням надзвичайно часто проявляються як «System» CPU. Ядро виконує бухгалтерію I/O: рутини завершення, повтори, таймаути,
управління чергами, скидання кешів і відновлення після помилок. Коли стек зберігання нещасний, він може спалювати CPU і одночасно погіршувати латентність. Ефективно.

Скидання Storport і таймаути: чому вони шкодять CPU

Скидання Storport (зазвичай Event ID 129) — це не просто «попередження». Воно означає, що Windows каже storage miniport: «я не отримую своєчасної відповіді; скинь пристрій/шлях».
Скидання може призвести до abort-команд, перезапитів, інвалідації кешів, подій multipath і шторму завершень. Усе це у контексті ядра.

Якщо бачите паттерн: стрибок латентності → event 129/153 → сплеск System CPU — вважайте це корельованим до спростування.

Стек фільтр-драйверів: податок на гарячий шлях, якого ви не планували

Мініфільтри можуть бути корисними і одночасно дорогими. Додайте два-три підряд — AV-сканування, DLP-інспекцію, фільтр бекапу — і ви можете помножити вартість I/O.
Під навантаженням це перетвориться на CPU ядра і тиск DPC, особливо якщо фільтр виконує синхронну роботу або викликає додаткові метадані-чити.

Глибина черги і «дрібні I/O»: самонанесена біль

Деякі робочі навантаження роблять багато маленьких випадкових записів і fsync-ів. Це не провина — так працюють певні бази даних і черги повідомлень.
Але якщо шлях зберігання налаштований для потокового I/O, ви можете змусити ОС і драйвер обробляти величезну кількість IOPS з високими накладними витратами на операцію.

Виправлення може бути в батчуванні на стороні застосунку. А може бути «перестати використовувати контролер/драйвер, який скидається під навантаженням».
Не робіть висновків про код, поки не маєте ETW-стеків.

Мережа і CPU «System»: NDIS, оффлоади, RSS та шторм пакетів

Мережеві драйвери живуть у світі переривань, DPC і акуратного батчування. Коли щось іде не так, CPU швидко йде в час ядра.
Якщо сплеск System CPU співпадає з хвилями трафіку, втратою пакетів або ретрансляціями — швидше за все, ви в NDIS-території.

Класичні патерни

Дуже велика interrupts/sec з одним ядром, що виконує більшість часу переривань: проблема афінітету переривань/RSS/налаштування черг.
Час DPC зростає при зростанні пропускної здатності: драйвер не справляється з обробкою прийому або шляхом коалесценції/сегментації.
Після оновлення драйвера: зміни в поведінці оффлоаду; дефолти змістилися; баг проявляється тільки з вашим трафіком.
Віртуальні комутатори та оверлеї: vSwitch, інкапсуляція та агенти безпеки додають шарів, що підсилюють накладні витрати.

Оффлоади: ставте їх як feature flags, а не догму

Оффлоади можуть бути корисні, але «увімкнені скрізь» — не стратегія. Правильний підхід:
ввімкнути мінімальний набір, виміряти під репрезентативним навантаженням, і тільки потім розширювати. Якщо налаштування знижує CPU, але погіршує хвостову латентність — це не виграш.

RSS і чергування: розподіліть роботу або платіть за податок одного ядра

Сучасні NIC можуть розподіляти обробку прийому по ядрах за допомогою RSS. Але дефолти не завжди адекватні, особливо у VM або коли включені інші функції (VMQ, SR-IOV).
Якщо бачите одне ядро, що завантажене перериваннями — RSS/афінітет це перший підозрюваний.

Віртуалізація та гіпервізори: коли хост невинний і одночасно винен

У віртуалізованих середовищах «драйвер» може означати:

Драйвери гостя (віртуальний NIC/драйвер зберігання)
Драйвери хоста (фізичний NIC/HBA), що викликають латентність, яку гість сприймає як скидання/таймаути
Віртуальні комутатори/шари фільтра в стеку хоста
Планування CPU і особливості віртуалізації переривань

VM з високим System CPU через скидання зберігання може бути спричинена проблемами черг на хості або проблемами фабрики. Доказ все одно починається в гості (ETW, журнали подій),
але ремедіація може потребувати участі платформи.

Практична порада: якщо ви можете відтворити проблему шляхом live-migrate VM на інший хост — це сильний доказ.
Це не ідеальна причинність, але сильний напрямковий сигнал — особливо в поєднанні з трейсами.

Типові помилки: симптом → корінь → виправлення

1) Симптом: «System» високий CPU, але ви лише дивитесь у Диспетчер завдань

Корінь проблеми: Немає атрибуції. «System» — це бакет, не діагноз.

Виправлення: Захопіть ETW (WPR/WPA) і перевірте CPU sampled stacks; підтвердіть DPC/ISR час і ідентифікуйте модулі драйверів.

2) Симптом: Одне ядро зайняте, інші простоюють; RDP жахливий

Корінь проблеми: Маршрутизація/афінітет переривань, RSS вимкнено/неправильно налаштовано, або пристрій застряг у одній черзі.

Виправлення: Перевірте RSS, кількість черг; оновіть драйвер/прошивку NIC; налаштуйте RSS і перевірте розподіл переривань.

3) Симптом: System CPU сплески під час бекапів або сканів AV

Корінь проблеми: Мініфільтри файлової системи виконують важку синхронну роботу, сканують гарячі набори даних або роблять дорогі шляхі метаданих.

Виправлення: Перегляньте вивід fltmc; налаштуйте виключення; розплануйте сканування; видаліть дублюючі агенти; тестуйте на канарці.

4) Симптом: Високе System CPU плюс Event ID 129 (storport reset)

Корінь проблеми: Таймаути/скидання зберігання через драйвер/прошивку/контролер, нестабільність фабрики або невідповідність глибини черги.

Виправлення: Корелюйте з лічильниками затримки диска; оновіть/відкатіть miniport драйвер; перевірте прошивку; вивчіть кабелі/фабрику; залучіть storage-команду з ETW-доказами.

5) Симптом: Висока interrupts/sec після увімкнення оффлоадів

Корінь проблеми: Баг в оффлоадному шляху або невідповідність; модерація переривань занадто агресивна/занадто помірна; взаємодія RSC/LSO.

Виправлення: Відкотіть і знову вмикайте по одному налаштуванню; вимірюйте interrupts/sec, DPC time і хвостову латентність; зберігайте відомо-гарну базу.

6) Симптом: Час ядра високий лише на «новому» поколінні апаратури

Корінь проблеми: Дефолти BIOS/firmware (стани живлення, PCIe ASPM), драйвер чіпсету або драйвер не валідовано для платформи.

Виправлення: Уніфікуйте налаштування BIOS відповідно до рекомендацій постачальника; оновіть прошивки і драйвери чіпсету; перевірте WHEA; тестуйте з узгодженим планом живлення.

7) Симптом: «System» високий CPU під час інтенсивних дрібних записів, особливо з шифруванням

Корінь проблеми: Накладні витрати криптографії/фільтрів і шаблони скидання кешу підсилюють вартість кожної I/O; підвищує чутливість до латентності шляху зберігання.

Виправлення: Виміряйте розподіл розмірів I/O через ETW; батчуйте записи там, де безпечно; перевірте версії драйвера шифрування; розгляньте апаратне прискорення та підтримувані режими.

Контрольні списки / покроковий план

Контрольний список A: Тріаж за 10 хвилин (безпечно для проду)

Запустіть лічильники привілейованого vs користувацького CPU; підтвердіть домінування часу ядра.
Перевірте interrupts/sec і DPC/interrupt time; помітте, чи є перекіс по ядрах.
Витягніть останню годину журналу System для попереджень/помилок; шукайте Storport/Disk/NDIS/WHEA патерни.
Перелічіть немайкрософтові драйвери та нещодавно змінені компоненти (NIC, зберігання, фільтри).
Вирішіть, чи виглядає це як проблема зберігання або мережі за лічильниками + логами.

Контрольний список B: Захоплення доказів (щоб припинити суперечки)

Запустіть WPR-трейс (CPU + DiskIO + Network) у filemode.
Відтворіть або зачекайте сплеск (60–120 секунд зазвичай достатньо).
Зупиніть трейс і збережіть ETL з часовою міткою в імені.
Захопіть одночасний знімок лічильників для латентності диска/черги і interrupts/sec.
Архівуйте зріз System event log для того ж вікна.

Контрольний список C: Експерименти із ізоляції (оберіть одне, не стріляйте з гармати)

Якщо мережеві симптоми: перемикайте один оффлоад за раз; вимірюйте; відкатуйте, якщо гірше.
Якщо зі зберіганням: протестуйте відкат драйвера на одній ноді; виміряйте; перевірте частоту event 129.
Якщо фільтрна проблема: вимкніть/деінсталюйте один не критичний фільтр на канарці; виміряйте I/O латентність і CPU ядра.
Якщо віртуалізовано: перемістіть навантаження/VM на інший хост; порівняйте трейс і логи.
Якщо апарат: змініть порт/cable NIC, оновіть прошивку, перевірте WHEA.

Контрольний список D: Контроль змін, що не зіпсує квартал

Підтримуйте затверджену матрицю драйверів/прошивок для кожної моделі платформи.
Канарьте кожне оновлення драйвера під репрезентативним навантаженням; захоплюйте ETW до/після.
Документуйте кроки відкату і зберігайте інсталятори локально для аварійних вікон.
Відстежуйте налаштування оффлоадів/RSS як конфігурацію, а не як «що GUI показує сьогодні».

Питання й відповіді

1) Чому CPU йде в «System», а не драйвер відображається як процес?

Драйвери ядра не виконуються як процеси користувача з власним PID. Їхня робота виконується в контексті ядра і часто оплачується процесу System.
ETW-стек-трейси — це спосіб атрибутувати цю роботу конкретному модулю.

2) Чи означає високі «System interrupts», що це завжди апаратна проблема?

Це апарат плюс програмне забезпечення. Апарат генерує переривання, але драйвери вирішують, як їх обробляти, згущувати і відкладати.
Багаті драйвери, невірні налаштування оффлоадів або прошивка можуть породжувати шторм переривань.

3) У чому різниця між ISR і DPC і чому це має значення?

ISR — це безпосередня рутина обслуговування переривань — має бути дуже швидкою. DPC — це відкладена робота, яка виконується трохи пізніше з підвищеним пріоритетом.
Якщо час DPC високий, система відчуває лаги, бо робота з високим пріоритетом витісняє звичайні потоки.

4) Чи справді антивірус може спричиняти сплеск «System» CPU?

Так. AV зазвичай використовує мініфільтри файлової системи. Під інтенсивною файловою активністю (build-сервери, лог-важкі застосунки, вікна бекапу)
фільтр може додати накладні витрати на кожен I/O і спричинити значний ріст часу ядра.

5) Якщо я оновлю драйвери, чи «найновіше» завжди краще?

Ні. «Найновіше» — це ризик, якщо воно не валідоване для вашого апаратного, OS-білду й робочого навантаження. Краще використовувати підтримувані вендором версії,
і запускати канарку з ETW-доказами перед широким розгортанням.

6) Скільки часу захоплювати ETW-трейс?

Достатньо, щоб включити сплеск і трохи нормальної бази — зазвичай 60–180 секунд вистачає для атрибуції CPU.
Якщо сплески рідкісні, використовуйте кругове буферизоване записування і захоплюйте вікно навколо інциденту.

7) Я бачу storport resets (Event 129). Чи це точно масив зберігання?

Не обов’язково. Це може бути масив, фабрика, прошивка HBA, драйвер, невідповідність глибини черги або навіть голодування CPU хоста, що викликає таймаути.
Корелюйте з латентністю диска, повторними спробами (Disk 153) і ETW стеками зберігання, щоб звузити коло.

8) Якщо ETW показує переважно ntoskrnl.exe замість драйвера вендора?

Таке може бути, коли символи/стек-проходження не розв’язуються добре, або коли гарячий шлях — це загальний код ядра, який викликають багато драйверів.
Забезпечте увімкнене стек-ходження, включіть події loader, і перехрестно перевірте провайдери DPC/ISR. Часто контекст виклику все одно вказує на драйвер-ініціатор.

9) Чи може користувацький застосунок спричинити високе «System» CPU, навіть якщо драйвер в порядку?

Так — генеруючи патологічні робочі навантаження: надвисокий IOPS дрібних операцій, аб’юзивні шаблони сокетів або постійний churn відкриття/закриття.
ETW допомагає відрізнити «баг драйвера» від «законної роботи ядра спричиненої навантаженням».

10) Чи варто використовувати Driver Verifier для виявлення цього?

Driver Verifier потужний, але ризикований у проді; він може спричинити аварії, щоб виявити дефекти драйвера.
Використовуйте його у стейджингу або на жертвоприношеному вузлі з планом відкату, а не на головному базі даних опівдні.

Висновок: практичні наступні кроки

Коли «System» їсть CPU, ставтеся до цього як до інциденту ядра, а не як до сесії налаштування застосунку. Ваш найшвидший шлях до істини:
лічильники для класифікації, логи для кореляції, ETW для атрибуції і одна контрольована зміна, щоб довести причинність.

Запустіть лічильники привілейованого/користувацького CPU і interrupts/DPC, щоб підтвердити клас проблеми.
Витягніть System журнали подій для сигналів storport/disk/ndis/whea в тому ж часовому вікні.
Захопіть короткий WPR-трейс і проаналізуйте CPU sampled stacks у WPA.
Ідентифікуйте драйвер/модуль і оберіть найменший зворотний крок (відкат/перемикання/вимкнення оффлоаду/фільтраційний тест).
Після виправлення знову захопіть ті самі лічильники/трейс, щоб довести покращення і запобігти регресіям.

Якщо ви зробите лише одну річ: отримайте трейс. Він перетворює «System високий» з скарги в кореневу причину, над якою можна діяти — або передати вендору без сорому.