Продуктивність Windows: «Високе завантаження ЦП» без підказок — єдина необхідна триаж

February 7, 2026 • February 7, 2026 • Читання: 5 хв • Views: 0

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

10:17 ранку. Хтось у Slack повідомляє: «CPU завантажено на 95% на файловому сервері». Жодних інших симптомів. Ніякого свіжого деплою (нібито). Користувачі кажуть «все повільно», що є найменш придатною для дій метрикою у світі.

Якщо ви дивитеся на «Високе завантаження ЦП» у Windows і не маєте підказок, вам не потрібні тисячі регуляторів. Потрібна дисциплінована процедура триажу, яка за кілька хвилин скаже, який тип проблеми з ЦП у вас є, і що робити далі без перетворення сервера на наукову виставку.

Що насправді означає «високе завантаження ЦП» (і чого воно не означає)

«ЦП високе» — це не діагноз. Це симптом, який може означати щонайменше чотири різні класи проблем:

Справжнє насичення обчислень: один або декілька процесів виконують легітимну роботу (або нелегітимну, наприклад, спінінг). Ви побачите велику процесну CPU-активність.
Навантаження ядра/драйверів: ЦП зайнятий, але не «в процесі» так, як ви очікуєте — шторм переривань, високий час DPC, фільтр-драйвери, драйвери зберігання/мережі, інтеграції антивірусу.
Конкуренція планувальника/віртуалізації: ОС хоче CPU, але не отримує його надійно (ready time, overcommit, contention на хості). Всередині гостьової ОС це виглядає як «високе ЦП» або «повільно без причини».
Неправильні вимірювання: ви дивитесь не на той лічильник або на правильний, але з невірними очікуваннями (математика багатоядерності, процес System, процес Idle або інструменти вибірки занадто повільні).

Мета триажу проста: класифікувати, до якої корзини належить випадок, а потім заглибитися. Не починайте з перевстановлення «чогось», відключення безпеки або зміни плану живлення лише тому, що блог вам так сказав. Ви можете швидко зробити реальну шкоду й все одно не знати, що сталося.

Правило для виробничого середовища: ви не виправляєте «високе ЦП». Ви визначаєте вузьке місце, а потім вирішуєте: пом’якшити, відкотити чи розв’язувати корінну причину за допомогою трасування.

План швидкої діагностики: першочергові/другорядні/контрольні перевірки

Це послідовність, яку я використовую на реальних системах, бо вона уникає двох класичних марнотрат: витріщання на графіки Task Manager і суперечок про «свіжі зміни».

Першочергово: це процес, ядро чи «не зовсім ЦП»?

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

Другорядно: чи прогресує система насправді?

Шукайте черги: run queue, переключення контексту, CPU ready (VM), черги диска, втрати пакетів мережі.
Корелюйте з латентністю: затримка диска, RPC, час запитів БД, web p95. Високе CPU іноді є наслідком, а не причиною.

Контроль: вирішіть «миттєво пом’якшити» або «захопити докази»

Пом’якшити, якщо користувачі недоступні: перезапустити завислу службу, обмежити завдання, переключити на резерв, тимчасово масштабувати, заблокувати галасливого клієнта або відкотити зміни.
Захопити докази, якщо можете: трасування WPR, лічильники PerfMon та дамп процесу для підозрюваного процесу.

Одне правило для пам’яті: якщо ви не можете пояснити завантаження ЦП списком процесів, це зазвичай драйвери, contention у віртуалізації або тротлінг.

Єдині потрібні інструменти (переважно вбудовані)

Windows дає вам багато інструментів; проблема в тому, що люди використовують найголосніший (Task Manager) і ігнорують точніші.

Task Manager: швидко бачити головних «балакучих», але поверхнево.
Resource Monitor: краща кореляція процес→CPU/диск/мережа.
PerfMon / typeperf: авторитетні лічильники, які можна логувати і порівнювати.
PowerShell: швидкі запити і повторювані команди триажу.
WPR + WPA: коли потрібно довести, куди йде час ЦП (і це потрібно).
Event Viewer: нудна правда про оновлення, драйвери та збої.

Парафраз ідеї від Gene Kim (автор з надійності): покращення приходить від зроблення роботи видимою та обмеження її — інакше ви просто швидше створюєте хаос.

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

Все нижче має бути виконуваним і відтворюваним. Запускайте ці команди в піднятому PowerShell, де зазначено. Для кожного завдання: команда, що типовий вивід означає і яке рішення ви приймаєте.

Завдання 1: Підтвердити насичення ЦП і визначити головні процеси (PowerShell)

cr0x@server:~$ powershell -NoProfile -Command "Get-Process | Sort-Object CPU -Descending | Select-Object -First 10 Name,Id,CPU,WorkingSet | Format-Table -Auto"
Name           Id      CPU    WorkingSet
----           --      ---    ----------
sqlservr     4216  18234.5  12488929280
MsMpEng      1832   2210.9    468135936
w3wp         6120   1402.1    913756160
svchost      1024    812.6    164184064
System          4    700.3     10289152

Що це означає: колонка CPU — це накопичувані секунди CPU з моменту запуску процесу, а не миттєве використання. Але список топ-процесів все одно показує, хто виконував роботу.

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

Завдання 2: Миттєве вибіркове зняття показників CPU (PowerShell loop)

cr0x@server:~$ powershell -NoProfile -Command "1..5 | % { Get-Counter '\Processor(_Total)\% Processor Time' | Select-Object -ExpandProperty CounterSamples | Select-Object CookedValue; Start-Sleep 1 }"
96.3125
94.875
97.0625
95.53125
96.0

Що це означає: CPU дійсно зафіксовано високо, це не транзієнтний сплеск або застарілий графік.

Рішення: Якщо навантаження стійке — продовжуйте. Якщо воно сплескоподібне, можливо потрібне трасування для виявлення винуватця або перевірте заплановані завдання/сканування антивірусу.

Завдання 3: Розбити час на user vs privileged (kernel)

cr0x@server:~$ powershell -NoProfile -Command "Get-Counter '\Processor(_Total)\% User Time','\Processor(_Total)\% Privileged Time' | Select-Object -ExpandProperty CounterSamples | Format-Table Path,CookedValue -Auto"
Path                                           CookedValue
----                                           -----------
\\server\processor(_total)\% user time              35.125
\\server\processor(_total)\% privileged time        60.8125

Що це означає: Високий час у привілейованому режимі означає роботу в kernel-mode: драйвери, фільтр-драйвери антивірусу, файлові системи, мережевий стек, інтенсивні переключення контексту.

Рішення: Якщо привілейований час домінує, не витрачайте годину на звинувачення прикладної програми. Переходьте до System, переривань/DPC та інвентаризації драйверів/фільтрів.

Завдання 4: Перевірити Interrupts і DPC час

cr0x@server:~$ powershell -NoProfile -Command "Get-Counter '\Processor(_Total)\% Interrupt Time','\Processor(_Total)\% DPC Time' | Select-Object -ExpandProperty CounterSamples | Format-Table Path,CookedValue -Auto"
Path                                             CookedValue
----                                             -----------
\\server\processor(_total)\% interrupt time          12.4375
\\server\processor(_total)\% dpc time                18.25

Що це означає: Подвійні цифри для Interrupt/DPC — це яскрава стрілка на драйвер, зазвичай storage, мережа або фільтр-драйвер.

Рішення: Захопіть WPR трасування для вибірки CPU та аналізу DPC/ISR, а також перевірте нещодавні оновлення драйверів і налаштування NIC/зберігання.

Завдання 5: Виявити потоки процесу `System`, що споживають CPU (швидка перевірка реальності)

cr0x@server:~$ powershell -NoProfile -Command "$p=Get-Process -Id 4; $p.Threads | Sort-Object TotalProcessorTime -Descending | Select-Object -First 10 Id,ThreadState,WaitReason,TotalProcessorTime | Format-Table -Auto"
Id   ThreadState WaitReason TotalProcessorTime
--   ----------- ---------- ------------------
3120     Running             00:08:12.5310000
1984     Running             00:05:44.8120000
4028     Running             00:03:19.1090000

Що це означає: Ви бачите «гарячі» потоки, але не стек викликів ядра цим методом. Це підказка, не доказ.

Рішення: Якщо потоки System гарячі і привілейований/переривання/DPC високі — припиніть здогадки: зробіть трасування (Завдання 10).

Завдання 6: Перевірити частоту ЦП і тротлінг (Perf counters)

cr0x@server:~$ powershell -NoProfile -Command "Get-Counter '\Processor Information(_Total)\% Processor Performance','\Processor Information(_Total)\% Processor Utility' | Select-Object -ExpandProperty CounterSamples | Format-Table Path,CookedValue -Auto"
Path                                                             CookedValue
----                                                             -----------
\\server\processor information(_total)\% processor performance        38.0
\\server\processor information(_total)\% processor utility            96.5

Що це означає: Висока utility при низькій performance може вказувати, що ЦП зайнятий, але працює на зниженій частоті (план живлення, термотротлінг, політика прошивки, управління живленням хоста).

Рішення: Перевірте план живлення, налаштування BIOS, політики віртуалізаційного хоста та події охолодження/термальні події. Не «оптимізуйте код» для CPU, якому наказано «підбігати».

Завдання 7: Перевірити план живлення (і не залишайте це на випадок)

cr0x@server:~$ powercfg /getactivescheme
Power Scheme GUID: 381b4222-f694-41f0-9685-ff5bb260df2e  (Balanced)

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

Рішення: Якщо ви бачите тротлінг або чутливість до затримок, розгляньте High performance або рекомендований постачальником план. Змінюйте свідомо та з вимірюванням.

Завдання 8: Перевірити наявність втілених запланованих завдань

cr0x@server:~$ powershell -NoProfile -Command "Get-ScheduledTask | ? {$_.State -eq 'Running'} | Select-Object TaskName,TaskPath | Format-Table -Auto"
TaskName                       TaskPath
--------                       --------
\Microsoft\Windows\UpdateOrchestrator\Reboot
\Microsoft\Windows\Defender\MP Scheduled Scan
\Vendor\DailyIndexMaintenance

Що це означає: «Високе ЦП щодня о 10:00» зазвичай не привид. Це розклад.

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

Завдання 9: Перевірити активність Windows Update (звично, нудно, реально)

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -LogName System -MaxEvents 20 | ? {$_.ProviderName -match 'WindowsUpdate|Servicing|TrustedInstaller'} | Select-Object TimeCreated,ProviderName,Id,Message | Format-Table -Wrap"
TimeCreated           ProviderName                 Id Message
-----------           ------------                 -- -------
02/04/2026 10:03:12   Microsoft-Windows-Servicing  1  The update installation started.
02/04/2026 10:04:01   Microsoft-Windows-Servicing  2  The update installation completed.

Що це означає: Обслуговування та оновлення можуть сильно навантажувати ЦП (і диск), особливо на старіших образах або серверах з надлишком компонентів у сховищі.

Рішення: Якщо це причина, припиніть ставитися до цього як до «випадкового». Виправте вікна патчів, стадіювання та гігієну образів.

Завдання 10: Захопити трасування CPU за допомогою WPR (серйозний крок)

cr0x@server:~$ wpr -start CPU -start GeneralProfile
WPR started with profile(s): CPU, GeneralProfile

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

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

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

Рішення: Якщо проблема неочевидна, зупиніться. Не змінюйте п’ять налаштувань одночасно. Аналізуйте трасу або передайте її тому, хто вміє.

Завдання 11: Швидкий інвентар драйверів мережі / NIC (звинувачення драйвера потребує доказів)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetAdapter | Select-Object Name,InterfaceDescription,Status,LinkSpeed | Format-Table -Auto"
Name    InterfaceDescription                   Status LinkSpeed
----    --------------------                   ------ ---------
Ethernet Intel(R) Ethernet Controller X710     Up     10 Gbps

cr0x@server:~$ powershell -NoProfile -Command "Get-NetAdapterDriver -Name 'Ethernet' | Select-Object Name,DriverVersion,DriverDate | Format-Table -Auto"
Name     DriverVersion DriverDate
----     ------------ ----------
Ethernet 2.1.4.0      06/12/2025

Що це означає: У вас є точна модель NIC і версія драйвера. Це має значення, коли DPC/ISR гарячі або після циклів патчів.

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

Завдання 12: Перевірити затримку диска і чергу (чи є CPU жертвою?)

cr0x@server:~$ powershell -NoProfile -Command "Get-Counter '\PhysicalDisk(_Total)\Avg. Disk sec/Read','\PhysicalDisk(_Total)\Avg. Disk sec/Write','\PhysicalDisk(_Total)\Current Disk Queue Length' | Select-Object -ExpandProperty CounterSamples | Format-Table Path,CookedValue -Auto"
Path                                                         CookedValue
----                                                         -----------
\\server\physicaldisk(_total)\avg. disk sec/read                 0.045
\\server\physicaldisk(_total)\avg. disk sec/write                0.120
\\server\physicaldisk(_total)\current disk queue length          18

Що це означає: 120ms записи і черга 18: зі сховищем проблеми. Високе CPU може бути вторинним (потоки спінять, повторні спроби, накладні витрати на стиснення/шифрування або таймаути програм, що створюють шторм).

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

Завдання 13: Корелювати CPU з контекстними переключеннями (індикатор накладних витрат)

cr0x@server:~$ powershell -NoProfile -Command "Get-Counter '\System\Context Switches/sec','\System\Processor Queue Length' | Select-Object -ExpandProperty CounterSamples | Format-Table Path,CookedValue -Auto"
Path                                     CookedValue
----                                     -----------
\\server\system\context switches/sec        145000
\\server\system\processor queue length          28

Що це означає: Дуже велика кількість context switches разом із довгою чергою процесора вказують на contention: занадто багато runnable-потоків, блокування або завантаження, що складається з багатьох дрібних робіт.

Рішення: Якщо топ-процес — runtime (java, dotnet, sqlservr), це може вказувати на тиск GC, проблеми з пулом потоків або spinlock—знову ж таки, трасування і/або профілювання додатку краще за здогадки.

Завдання 14: Перевірити підказки віртуалізації (Hyper-V Integration Services і синхронізація часу не завжди ваш CPU, але)

cr0x@server:~$ powershell -NoProfile -Command "systeminfo | findstr /I /C:'System Manufacturer' /C:'System Model'"
System Manufacturer:           Microsoft Corporation
System Model:                  Virtual Machine

Що це означає: Ви у віртуальній машині. Тепер CPU може бути «ready time» (контенція хоста) або політикою живлення на хості.

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

Завдання 15: Знайти гарячі служби всередині `svchost` (бо «svchost високий» — це крик про допомогу)

cr0x@server:~$ tasklist /svc /fi "imagename eq svchost.exe"
Image Name                     PID Services
========================= ======== ============================================
svchost.exe                   1024 DcomLaunch, PlugPlay
svchost.exe                   1200 wuauserv, bits
svchost.exe                   1468 Dhcp, dnscache

Що це означає: Ви можете зіставити гарячий PID svchost зі службами в ньому.

Рішення: Якщо PID 1200 споживає CPU і містить wuauserv, то це вже про Windows Update, а не «випадковий svchost». Цільте виправлення саме туди.

Жарт №1: Task Manager — як сигналізація диму, яка ще й кричить адресу — корисно, але все одно не скаже, яка кімната горить.

Коли це не «процес»: переривання, DPC, драйвери

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

Типові причини у продакшні:

Драйвери NIC та offload: неправильна конфігурація RSS, баги в checksum offload, проблеми з large send offload або регрес драйвера після оновлення.
Драйвери зберігання та multipath: проблеми HBA/RAID драйверів, флапання шляхів, невідповідність глибини черги, несумісності прошивки.
Фільтр-драйвери: антивірус, DLP, шифрування, знімки резервних копій — все, що перехоплює файлові/мережеві операції.
USB і «хто це підключив»: рідше на серверах, частіше на робочих станціях, але буває.

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

У WPA ви зазвичай робите pivot через:

CPU Usage (Sampled) за процесом/потоком/стеком
DPC/ISR за модулем/стеком
Мережеві send/receive і вартість CPU (якщо захоплено)

Погляд інженера зберігання: ЦП, що видається за I/O (і навпаки)

Збої зі зберіганням і CPU люблять імітацію один іншого. Проблема зі зберіганням може підвищувати CPU через повторні спроби, таймаути, накладні витрати на стиснення/шифрування і трешинг кешів. Водночас проблема CPU може підвищувати затримку I/O, позбавляючи потоки, які годують чергу, ресурсів, затримуючи обробку завершень або обробку переривань.

Режим відмови: «ЦП високе», але справжня біда — затримка диска

Типово при вікнах резервного копіювання, індексації, антивірусі та «корисних» завданнях дедуплікації/стиснення. CPU працює, так, але користувачі страждають через переповнену чергу сховища.

Шаблон рішення: Якщо Avg. Disk sec/Read або Write зростають і черга подовжується разом з CPU — вважайте диск первинним вузьким місцем. Ваше пом’якшення — зменшити паралелізм I/O і випадкові записи, а не шукати апгрейд CPU.

Режим відмови: фільтр-драйвери підвищують вартість I/O на ЦП

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

Що робити: підтвердіть виключення для баз даних, VM-сторів, build-кешів і резервних репозиторіїв. Якщо не знаєте, що виключати — порадьтеся з власником додатку і командою безпеки і документуйте. Потім протестуйте і виміряйте.

Режим відмови: SMB-сервери і CPU

Файлові сервери можуть витрачати CPU на шифрування/підпис, обробку метаданих або роботу з «балакучими» клієнтами. Іноді виправлення — ніяк не гламурне: оновити драйвер NIC, перевірити RSS, налаштувати SMB multichannel і припинити безперервне сканування всього шару.

Цікаві факти та історичний контекст (видання про CPU у Windows)

«System Idle Process» не є реальним процесом. Він представляє CPU, що нічого не робить. Високий «Idle» — це хороша новина, навіть якщо люди панікують, коли бачать його.
Windows перейшов до ізоляції за службами з часом. Історично багато служб ділили svchost.exe; сучасні версії Windows можуть розділяти служби більш детально, покращуючи діагностичність.
Затримка DPC прославилася через збої аудіо. Ті самі механізми, що викликають потріскування в аудіо, можуть також знищити пропускну здатність серверів — просто з менш драматичними симптомами.
PerfMon лічильники існують довше за більшість сучасної спостережуваності. Вони працюють десятиліттями; і досі одне з найнадійніших джерел істини на хості Windows.
ETW (Event Tracing for Windows) — основа серйозної роботи з продуктивністю Windows. WPR/WPA — дружні двері до ETW, який є ядром трасування з часів розвитку NT-лінійки.
Зміна плану «balanced» — не лише маркетинг. Сучасні CPU мають швидке масштабування частоти, але серверні навантаження з жорсткими бюджетами латентності все ще можуть страждати від агресивних збережень енергії.
Інтеграція антимальвару змінила правила гри. Defender та сторонні AV все більше інтегруються через kernel hooks і фільтр-драйвери, тому можуть з’являтись як «ядрований» CPU, а не акуратно в користувацькому режимі.
Віртуалізація зробила CPU ресурсом, що ділиться з політикою. Коли ви гість, CPU залежить від сусідів і політики хоста; «моя VM повільна» іноді означає «хтось інший зайняв весь CPU».

Три корпоративні міні-історії з реального життя

Міні-історія 1: Інцидент через неправильне припущення

Алерт був простий: «Windows Server: CPU > 90% протягом 15 хвилин». Це був mid-tier app server, нічого екзотичного. On-call відкрив Task Manager, побачив w3wp.exe вгорі й оголосив: «IIS тане». Вони перезапустили пул додатків. CPU впав. Усі видихнули. Через дві хвилини CPU знову в піку.

Вони робили звичні ритуали: перезапустити службу, очистити тимчасові файли, зробити жорсткіший ресайкл. Це не план — це інтерпретаційний танець. Тим часом привілейований час був у небі, але ніхто не дивився, бо Task Manager не кричав про це голосно.

Через годину хтось запустив кілька лічильників: % Privileged Time домінував, а % DPC Time був у підліткових значеннях. «IIS» CPU було колатеральною шкодою: треди запитів кружляли у спінінгу і таймаутились, поки ядро обробляло мережеві переривання.

Корінна причина — оновлення драйвера NIC, розгорнуте як частина «рутинного» бандлу постачальника. На цій моделі, із тією конфігурацією offload, воно породжувало патерн з високим DPC під певним трафіком. Відкат драйвера NIC виправив усе миттєво. Неправильне припущення було в тому, що топ-процес означає причинність. Ні — воно означає близькість до болю.

Тривале виправлення не було «ніколи оновлювати драйвери». Воно полягало в: закріпленні протестованих версій драйверів, моніторингу лічильників DPC/interrupt та поводженні з «бандловими» оновленнями як із змінами з потенційним blast radius.

Міні-історія 2: Оптимізація, що обернулась проти

Команда хотіла прискорити доступ до файлів на Windows VM з build-артефактами. Хтось запропонував увімкнути агресивне реальне сканування «бо безпека», а потім компенсувати це збільшенням кількості vCPU. На тихих середовищах виглядало нормально. У продакшні це було катастрофою: CPU виріс, файлові операції сповільнились, і build-ферма почала таймаутитись.

Потім вони «оптимізували», ввімкнувши більше паралелізму у збірці, щоб «краще використовувати CPU». Так створюють натовп. Фільтр-драйвер антивірусу зробив кожне торкання файлу дорожчим. Більше паралелізму помножило накладні витрати і додало переключень контексту. CPU досягнув стелі, черги диска забилися, а агенти збірки стали повторювати спроби, погіршуючи проблему.

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

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

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

Ще одна організація мала набір Windows баз даних серверів, що час від часу підіймали CPU під час кінця місяця. Відмінність була в тому, що вони мали звичку постійно збирати невеликий набір PerfMon лічильників і зберігати їх з розумною ретенцією. Не назавжди — просто достатньо, щоб відповісти на питання «це нове?»

Коли знову стався сплеск, on-call не почав з думок. Вони витягли лічильники й порівняли з попереднім циклом. Цього разу CPU високий, але % Processor Performance був незвично низьким, і сплеск корелював з підвищенням кількості скоригованих помилок апаратури в логах платформи.

Виявилось, що після вікна обслуговування змінилася політика кривої вентилятора в прошивці — сервер мав проблему охолодження. CPU тротлився під навантаженням. База даних робила ту саму роботу, повільніше і довше, з більшим часом у «високе ЦП».

Виправлення не було перестановкою індексів або переписуванням запитів. Це було відновлення очікуваної термальної політики прошивки та перевірка телеметрії навколишнього середовища. Вони уникнули тижня безглуздого тюнінгу, бо мали базу і дисципліну її перевіряти.

Жарт №2: Високе ЦП — це спосіб всесвіту спитати, чи маєте ви базові дані. Якщо ні — спитає ще голосніше.

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

Це частина, де ви припиняєте витрачати години на ті самі пастки.

1) «Task Manager показує 100% CPU, але топ-процес лише 5%»

Корінна причина: CPU в kernel-часі: переривання/DPC, робота драйверів, або ви збираєте занадто рідко / дивитесь не той вигляд.

Виправлення: Перевірте % Privileged Time, % DPC Time, % Interrupt Time. Зробіть WPR трасування. Перевірте версії драйверів і нещодавні оновлення.

2) «System процес високий, значить Windows зламався»

Корінна причина: System — це відро для активності ядра, часто викликаної апаратним/драйверним поведінням або фільтр-драйверами.

Виправлення: У WPA аналізуйте CPU sampled stacks і DPC/ISR за модулем. Зробіть інвентар фільтр-драйверів (AV, резервне копіювання, DLP), NIC/HBA драйверів і відкотіть зміни обережно.

3) «svchost.exe — винуватець»

Корінна причина: svchost хостить кілька служб; ви звинувачуєте будинок квартир.

Виправлення: Використайте tasklist /svc, щоб зіставити PID зі службами, а потім досліджуйте конкретну службу (Update, BITS, DNS cache тощо).

4) «CPU високий після патчів, отже відкатуємо оновлення ОС»

Корінна причина: Післяпатчеве обслуговування, сканування Defender, обслуговування component store або оновлення драйверів у складі патчу.

Виправлення: Перевірте журнали подій на предмет обслуговування, підтвердьте розклад завдань Defender і керуйте оновленнями драйверів явно. Відкат оновлень ОС — останній засіб, а не рефлекс.

5) «Додали більше vCPU і стало гірше»

Корінна причина: Збільшений паралелізм посилив contention на блокуваннях, переключення контексту або thrash кешу; або хост був overcommitted.

Виправлення: Виміряйте context switches, processor queue length і (у віртуалізаційному інструментарії) CPU ready/steal. Розгляньте менше, але швидші vCPU замість багатьох повільних. Профілюйте перед масштабуванням.

6) «Високе CPU означає потребу в більшому сервері»

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

Виправлення: Визначте, чи прив’язка до одного ядра, ядро-залежна або багатоядерна. Використовуйте трасування і аналіз по-потоках перед зміною розміру.

7) «Затримка диска висока, отже тільки сховище винне»

Корінна причина: Голодування CPU може відкладати обробку завершень I/O; AV/фільтр може уповільнювати файлові операції; мережеві проблеми можуть мати вигляд збоїв зберігання (SMB retries).

Виправлення: Корелюйте привілейований час CPU, DPC/ISR та чергу/латентність диска. Виправляйте первинне вузьке місце, а не найбільш гучну метрику.

8) «Ми відключили антивірус і CPU впав, отже все готово»

Корінна причина: Ви прибрали критично важливий контроль і не усунули характеристики навантаження, які його викликали.

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

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

Контрольний список A: 10-хвилинний триаж для on-call (без геройств)

Підтвердьте стійке завантаження ЦП швидким зняттям лічильника (Завдання 2). Якщо воно не стійке — не трактуйте як інцидент.
Визначте топ-процес (Завдання 1). Якщо це явний процес додатку — йдіть туди першочергово.
Розділіть user vs privileged (Завдання 3). Привілейований переважає — це ядро/драйвер/фільтр.
Перевірте переривання і DPC (Завдання 4). Подвійні цифри — «перестаньте гадати, трасуйте».
Перевірте затримку/чергу диска (Завдання 12). Якщо сховище забито — CPU може бути вторинним.
Перевірте живлення/тротлінг (Завдання 6 + Завдання 7). Низький показник performance — явна підказка.
Перевірте запущені заплановані завдання (Завдання 8). Зіставте часові відмітки.
Сопоставте служби всередині svchost якщо релевантно (Завдання 15).
Вирішіть: пом’якшити чи захопити: якщо сервіс деградує — пом’якшіть мінімально. Якщо все стабільно — захопіть WPR (Завдання 10).
Запишіть, що побачили: лічильники, часові відмітки, що змінилося. Ваше майбутнє «я» — інша людина.

Контрольний список B: Якщо це процес додатку (шлях насичення обчислень)

Підтвердьте, чи це одне ядро чи багато (перегляд у Task Manager по логічних процесорах; також перевірте, чи один потік домінує в телеметрії додатку).
Зберіть WPR CPU sample trace (Завдання 10) під час гарячої точки.
Шукайте тиск GC (керовані рантайми), щільні цикли, надмірне логування, крипто/стиснення або патологічні regex/серіалізацію.
Перевірте залежності вниз по ланцюгу: таймаути можуть створювати шторм повторів, що виглядає як «обчислення».
Пом’якшення: обмежте роботу, зменшіть паралелізм, відкотіть, масштабування назовні лише якщо дає час і ви розумієте причину.

Контрольний список C: Якщо це ядро/драйвер (шлях привілейованих/DPC)

Захопіть WPR з CPU + General profile (Завдання 10). Якщо безпечно, захопіть довше (60–120 секунд) під час піку.
Зробіть інвентар NIC та драйверів (Завдання 11) і перевірте нещодавні зміни.
Перевірте залучені фільтр-драйвери: AV, резервне копіювання, шифрування, DLP. Підтвердьте область дії та виключення.
Переконайтесь у здоров’ї шляху зберігання: стабільність multipath, узгодженість драйверів/прошивки HBA і поведінка черги зберігання.
Пом’якшення: відкат драйверів, переключення на резервні шляхи, зменшення складності NIC offload лише з тестуванням і вимірюванням.

Контрольний список D: Якщо це VM (шлях contention)

Підтвердьте, що машина віртуальна (Завдання 14).
Зберіть докази всередині guest: лічильники CPU, довжина черги, контекстні переключення, показники тротлінгу.
Ескалюйте з конкретикою: часові відмітки, тривалість, і який тип CPU (user/privileged/DPC).
На хості (через команду віртуалізації): перевірте contention/ready time і шум сусідів.
Пом’якшення: live migrate, зменшити overcommit, резервувати ресурси для критичних VM або ізолювати галасливі навантаження.

Поширені запитання

Q1: Чому Task Manager показує «100% CPU», але система здається простою?

Тому що CPU може споживатися в роботі ядра (переривання/DPC) або короткими сплесками, що в середньому дають великі значення, при цьому пропускна здатність залишається низькою (тротлінг, contention). Перевірте % Privileged Time, % DPC Time і лічильники продуктивності CPU.

Q2: Чи завжди високе CPU — це погано?

Ні. Якщо система відповідає вимогам латентності і пропускної здатності, високе CPU просто означає, що ви використовуєте сервер, за який платили. Погано — це високе CPU плюс черги плюс пропущені SLO.

Q3: Який найшвидший спосіб знайти винуватця процесу?

Використайте Task Manager/Resource Monitor для первинного огляду, потім PowerShell для списку процесів і захопіть WPR трасування. Якщо винуватець міняється швидко, трасування краще за візуальний огляд.

Q4: Що робити, якщо «System» — топ-споживач CPU?

Трактуйте це як розслідування ядра/драйвера. Перевірте привілейований час і DPC/interrupt time. Потім захопіть WPR і аналізуйте в WPA, щоб побачити, який драйвер/модуль спалює цикли.

Q5: Як зрозуміти, чи це вузьке місце одного потоку?

Якщо загальний CPU не повністю насичений, але продуктивність погана, або один логічний процесор завантажений, а інші ні — скоріш за все один гарячий потік. Підтвердять вибіркові стеки WPA і по-потоковий CPU.

Q6: Чи може антивірус справді викликати «високе ЦП» на серверах?

Абсолютно. Сканування в реальному часі і перевірки репутації додають навантаження CPU для кожної файлової операції і можуть виявлятися як привілейований час. Виправлення зазвичай — правильні виключення і планування, а не відключення безпеки.

Q7: Які лічильники варто логувати постійно для середовищ з «невідомим високим CPU»?

Щонайменше: \Processor(_Total)\% Processor Time, % User Time, % Privileged Time, % DPC Time, % Interrupt Time, \System\Processor Queue Length, \System\Context Switches/sec та базові лічильники латентності/черги диска.

Q8: Як довго запускати WPR?

Достатньо, щоб захопити гарячку точку (зазвичай 30–120 секунд). Короткі трасування легше аналізувати і менш ризиковані. Якщо сплеск періодичний — захоплюйте під час піку, а не після.

Q9: Чи слід переключити план живлення Windows на High performance на серверах?

Лише якщо ви спостерігали тротлінг або чутливість до затримок і можете виміряти покращення. Це інструмент, а не забобон. Перевіряйте з % Processor Performance і метриками навантаження.

Q10: Яка найпоширеніша причина «високого ЦП» без підказок у корпоративних Windows?

Фільтр-драйвери і завдання обслуговування: сканування антивірусу, сервісне обслуговування оновлень, індексація, агенти резервного копіювання і регресії драйверів після патчів. Спільна тема: CPU виконує роботу, яку ви не заклали в бюджет.

Висновок: що робити наступного разу до того, як це стане «критичним»

Коли хтось каже «CPU високий», ваше завдання — відмовитись від розмитої формулювання і замінити її на класифікацію: обчислювальне насичення процесу, ядро/драйвер, contention або плутанина вимірювань. Потім берете найкоротший шлях до доказів.

Практичні кроки, які ви можете зробити цього тижня:

Стандартизувати маленький базовий набір PerfMon на критичних Windows-хостах. Зберігайте достатню історію, щоб відповісти «це нове?»
Освоїти захоплення WPR. 60-секундне трасування під час болю варте десяти годин думок після.
Закріпити та керувати версіями драйверів для NIC/зберігання на серверах. Ставте їх як залежності, а не фон.
Задокументувати виключення AV і графіки техобслуговування спільно з власниками додатків. Якщо це не задокументовано — воно обов’язково запуститься в найгірший момент.
Визначити пакет для ескалації: лічильники, часові відмітки, топ-процеси, привілейований/DPC/interrupt час, латентність диска і чи це VM. Це перетворює «допомогу» на «дію».

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