Что будем искать
Когда пользователь говорит «Windows тормозит», причин может быть огромное количество. Но на первом этапе нам не нужно перебирать их все. Сначала необходимо ответить на более простой вопрос: какой ресурс компьютера испытывал нагрузку в момент возникновения проблемы и есть ли признаки реального ограничения производительности?
Диагностику построим вокруг трёх основных компонентов:
- процессор — посмотрим не только его загрузку, но и очередь потоков, ожидающих процессорное время;
- оперативная память — проверим доступную RAM и активность страничного обмена;
- диск — посмотрим его занятость, очередь запросов и время выполнения операций.
Здесь есть важный момент: один показатель практически никогда не стоит рассматривать отдельно. Например, загрузка CPU всего 5% совершенно не означает, что с производительностью компьютера всё хорошо. В этот момент система может ждать диск или активно работать с файлом подкачки.
Поэтому наша диагностика будет строиться по простой цепочке:
Поймать момент тормозов → определить проблемный ресурс → найти процесс, создающий нагрузку → выяснить причину его поведения.
Сначала воспользуемся Диспетчером задач и Монитором ресурсов. Затем настроим Performance Monitor так, чтобы он записывал показатели в фоне. Если компьютер снова зависнет, например в 14:37, мы сможем вернуться к этому времени в журнале и увидеть, что именно происходило с CPU, памятью и диском.
А чтобы не создавать такой сборщик вручную на каждом проблемном компьютере, в конце автоматизируем всю процедуру с помощью PowerShell.
Начинаем с Диспетчера задач
Первое, что обычно открывают при жалобах на медленную работу Windows, — Диспетчер задач. Запускаем его сочетанием клавиш Ctrl + Shift + Esc и переходим на вкладку Производительность.
Здесь сразу видны загрузка процессора, использование оперативной памяти и активность дисков. Если проблема происходит прямо сейчас, иногда уже этого достаточно, чтобы понять направление дальнейшего поиска.
Но на нашем тестовом компьютере всё выглядит нормально: процессор почти свободен, памяти достаточно, диски практически не используются.
И вот здесь легко сделать неправильный вывод: «С компьютером всё нормально». На самом деле мы можем сказать только одно — с компьютером всё нормально в данный момент.
Смотрим глубже через Монитор ресурсов
Если тормоза происходят прямо сейчас, следующим шагом открываем Монитор ресурсов:
resmonНа вкладке Обзор одновременно отображается активность процессора, дисков, сети и оперативной памяти.
Главное преимущество перед вкладкой «Производительность» Диспетчера задач — здесь уже можно увидеть конкретные процессы, работающие с ресурсами системы.
Проверяем дисковую нагрузку на практике
Для примера я специально создал на тестовом компьютере интенсивную дисковую нагрузку. В результате Монитор ресурсов сразу показывает 100% активного времени диска.
Но гораздо полезнее самого значения 100% то, что здесь можно увидеть процессы и файлы, создающие ввод-вывод. Именно так мы постепенно переходим от симптома «диск загружен» к поиску источника нагрузки.
Если проблема происходит прямо сейчас, Монитор ресурсов очень удобен. Но если пользователь позвонил уже после зависания, мы снова опоздали: история нагрузки здесь не сохраняется.
Поэтому для периодических проблем нам нужен другой подход — записывать показатели заранее.
Записываем производительность через Performance Monitor
Для этого в Windows есть встроенный Системный монитор (Performance Monitor). Запускаем его командой:
perfmonОткрываем Средства наблюдения → Системный монитор.
По умолчанию здесь отображается загрузка процессора. Но нам недостаточно знать только процент использования CPU. Нужно одновременно видеть несколько связанных показателей процессора, памяти и дисковой подсистемы.
Какие счётчики будем собирать
В Performance Monitor доступны сотни счётчиков. Добавлять всё подряд не нужно. Для первоначальной диагностики достаточно небольшого набора, который поможет ответить на главный вопрос: CPU, память или диск?
| Счётчик | Что показывает |
|---|---|
| Память → Доступно МБ | Количество доступной физической памяти |
| Память → Обмен страниц/с | Активность страничного обмена |
| Память → Байт выделенной виртуальной памяти | Объём выделенной виртуальной памяти |
| Процессор → % загруженности процессора → _Total | Общая загрузка процессора |
| Система → Длина очереди процессора | Потоки, ожидающие процессорное время |
| Физический диск → % активности диска → _Total | Занятость дисковой подсистемы |
| Физический диск → Средняя длина очереди диска → _Total | Количество ожидающих дисковых операций |
| Физический диск → Среднее время обращения к диску (с) → _Total | Время выполнения дисковых операций |
Добавляем процессор и память
В Системном мониторе нажимаем зелёный значок + и добавляем показатели памяти, процессора и системы.
Добавляем показатели диска
Затем выбираем объект Физический диск и добавляем три дисковых показателя. Для первоначальной диагностики используем экземпляр _Total, чтобы видеть состояние дисковой подсистемы в целом.
Учимся читать показатели
После добавления счётчиков Performance Monitor начинает показывать их в реальном времени.
Здесь важно не искать одно универсальное «плохое значение». Нас интересуют сочетания показателей.
Процессор
Если загрузка CPU на несколько секунд поднимается до 100%, это совершенно нормально. Программа могла выполнить сложную операцию и закончить её.
Гораздо интереснее длительная высокая загрузка процессора вместе с ростом длины очереди процессора. Такая картина уже может указывать на нехватку процессорных ресурсов.
Оперативная память
Большое количество занятой RAM также не означает проблему само по себе. Windows старается эффективно использовать доступную память.
Поэтому смотрим одновременно на доступную память и активность страничного обмена. Если свободной памяти остаётся мало и система постоянно обращается к виртуальной памяти, стоит искать процессы, потребляющие RAM.
Диск
С диском ситуация похожая. Даже 100% активности не означает автоматически, что накопитель неисправен или слишком медленный.
Намного полезнее сопоставить активность диска, очередь запросов и время выполнения операций. Если все эти показатели ухудшаются одновременно и именно в этот момент пользователь замечает зависание, у нас появляется серьёзное основание продолжить диагностику дисковой подсистемы.
Создаём группу сборщиков данных
Теперь переходим к главной части нашей диагностики. Вместо того чтобы постоянно смотреть на график, заставим Windows записывать показатели самостоятельно.
В Performance Monitor открываем Группы сборщиков данных → Особые. Нажимаем правой кнопкой мыши и выбираем Создать → Группа сборщиков данных.
Назовём её:
Windows DiagnosticsВыбираем Создать вручную (для опытных).
На следующем шаге выбираем Создать журналы данных и отмечаем Счётчик производительности.
Нажимаем Добавить и выбираем те же показатели CPU, памяти и диска.
Устанавливаем интервал выборки 5 секунд.
Такого интервала достаточно, чтобы увидеть относительно короткие всплески нагрузки, и при этом журнал остаётся удобным для длительного сбора.
Указываем каталог:
%systemdrive%\PerfLogs\Admin\Windows Diagnostics
Запускаем созданную группу и возвращаем компьютер пользователю.
Теперь нам не нужно сидеть перед ним и ждать зависания.
Ловим момент тормозов
Представим, что через несколько часов пользователь сообщает:
«Примерно в 14:37 компьютер опять сильно тормозил».
Это как раз та информация, которая нам нужна.
Останавливаем сбор данных, открываем полученный журнал и переходим к промежутку примерно 14:35–14:40.
Теперь вместо догадок можно последовательно проверить три наших направления.
Например:
- CPU в момент зависания не был сильно загружен;
- доступной оперативной памяти было достаточно;
- активность диска резко выросла одновременно с очередью и временем выполнения операций.
Это уже совершенно другой уровень диагностики. Мы не утверждаем «Windows тормозит из-за диска» потому, что однажды увидели 100% в Диспетчере задач. Мы видим, что в момент возникновения проблемы появились признаки повышенной дисковой нагрузки, которые нужно проверить по задержке и очереди.
От ресурса переходим к процессу
PerfMon помог ответить на первый вопрос — какой ресурс показал признаки ограничения производительности. Теперь нужно выяснить, кто создал эту нагрузку.
Если проблема воспроизводится снова, открываем Монитор ресурсов → Диск и сортируем процессы по активности чтения и записи.
Здесь могут обнаружиться совершенно разные виновники: антивирусная проверка, индексатор Windows, синхронизация файлов, резервное копирование, браузер, база данных или рабочее приложение пользователя.
Именно поэтому высокий Disk или CPU — ещё не диагноз. Нам нужно пройти цепочку до конца:
Ресурс → процесс → причина активности процесса.
Например, если большую дисковую активность создаёт антивирус, это ещё не означает, что его нужно отключить. Возможно, в этот момент выполняется плановая проверка или приложение генерирует большое количество файлов, которые антивирус вынужден проверять.
Автоматизируем диагностику с помощью Windows Diagnostics
Ручная настройка PerfMon помогает понять принцип измерений. Но когда проблема возникает раз в несколько часов, гораздо удобнее один раз запустить сбор, а затем получить готовый отчёт. Для этого я подготовил Windows Diagnostics — PowerShell-скрипт для Windows PowerShell 5.1, который мы проверяли на Windows 10 и Windows 11.
Он записывает системные счётчики в BLG, собирает сведения о процессах в CSV, а после завершения формирует HTML-отчёт с временными эпизодами нагрузки, графиками и списками процессов. При необходимости можно включить короткие трассировки дисковых операций через ETW (Event Tracing for Windows).
Скачать Windows Diagnostics (PowerShell)
Подготовка и запуск
Сохраняем файл под именем Windows-Diagnostics.ps1 в папку C:\Script. Открываем Windows PowerShell от имени администратора и разрешаем выполнение скрипта только в текущем окне:
Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass -ForceЗапускаем диагностику на 10 минут с интервалом измерений 5 секунд и включённой кратковременной ETW-трассировкой:
& "C:\Script\Windows-Diagnostics.ps1" -Action Start -MaxMinutes 10 -EnableKernelETW -TraceTriggerLatencyMs 1 -TraceBurstSeconds 15Параметр -MaxMinutes 10 задаёт предел продолжительности наблюдения, -TraceTriggerLatencyMs 1 — чувствительный порог для запуска короткого ETW-захвата, а -TraceBurstSeconds 15 — длительность захвата. Порог в 1 мс удобен для демонстрации, но на обычном рабочем компьютере может давать лишние трассировки; для длительной диагностики его нужно подбирать под задачу.
Если физическая трассировка диска не требуется, запускаем упрощённый вариант:
& "C:\Script\Windows-Diagnostics.ps1" -Action Start -MaxMinutes 10Проверяем состояние и останавливаем сбор
& "C:\Script\Windows-Diagnostics.ps1" -Action StatusКогда проблема повторилась, записываем время и завершаем сбор:
& "C:\Script\Windows-Diagnostics.ps1" -Action StopОтдельно пересоздать отчёт по последней сессии можно командой:
& "C:\Script\Windows-Diagnostics.ps1" -Action ReportПо умолчанию файлы сохраняются в C:\PerfLogs\SysAdminHub. Там находятся журнал BLG, процессный CSV, сводный CSV и HTML-отчёт. HTML можно открыть обычным браузером без подключения к интернету.
Как устроен HTML-отчёт
Главное отличие скрипта — он не оставляет администратора один на один с длинным BLG-журналом. В верхней части отчёта показаны три независимые карточки: процессор, оперативная память и диск. Ниже — системные показатели, совпадения по времени, графики, процессы и ETW-события.
Процессор: не только максимальные 100%
В карточке CPU отображаются пиковая загрузка, время события и процессы-кандидаты рядом с этим пиком. Скрипт также объединяет близкие превышения порога в отдельные эпизоды: это помогает отличить короткий всплеск от продолжительной нагрузки.
В нашем контролируемом тесте Windows 10 загрузка процессора достигала 100%, а рядом с эпизодом выделялась группа процессов powershell. Мы специально запускали вычислительную нагрузку на 20 логических процессоров, поэтому такой результат ожидаем. Но на реальном компьютере название процесса в отчёте — повод изучить его задачу, а не готовый диагноз.
Оперативная память: снижение ещё не означает нехватку
Отчёт показывает, насколько сократился объём доступной RAM, какой минимум был зафиксирован и какой процесс имел наибольший Working Set — набор физических страниц памяти, находившихся в RAM для этого процесса в момент измерения.
Во время нашего теста мы выделили около 12 ГиБ памяти в PowerShell. В отчёте появился процесс powershell с Working Set около 12 420 МиБ, а доступная RAM опускалась до 8 879 МиБ. Скрипт обнаружил заметное изменение, но не объявил критическую нехватку памяти: минимальный запас оставался значительным.
Private — частная память процесса, а Working Set — резидентные физические страницы. Сумма Working Set разных процессов не равна уникально занятой физической памяти: общие страницы могут учитываться несколько раз.
Диск: высокая активность не всегда означает проблему
В дисковой карточке приводятся пиковое суммарное дисковое время, задержка P95 и обнаруженные в ETW файлы. При использовании экземпляра счётчиков _Total значение дискового времени может быть выше 100%, поскольку суммируются показатели нескольких физических дисков. Это не значит, что один накопитель загружен на 155% или 175%.
На Windows 11 при копировании ZIP-файлов отчёт зафиксировал 155,2% суммарного дискового времени, но задержка P95 составляла всего 1,87 мс. Следовательно, по одному большому проценту нельзя утверждать, что накопитель тормозит систему. Для точного вывода нужно проверить отдельные диски, задержки, очередь и жалобу пользователя в тот же промежуток.
Разбираем графики и таблицы процессов
В блоке «Корреляция всплесков и процессов» скрипт ищет процессы, активность которых совпала по времени с повышенной нагрузкой. Для каждого эпизода отображаются интервал, экстремальное значение и ближайшие процессы-кандидаты. Совпадение по времени не доказывает причинность: процесс может лишь реагировать на работу другого приложения.
Ниже находятся графики CPU, чтения и записи процессного I/O. I/O (Input/Output) — ввод-вывод, то есть операции чтения и записи данных. Процессный I/O включает не только физический диск, поэтому скорость в этих таблицах нельзя напрямую считать скоростью SSD или HDD.
Таблица «ТОП-15 по Working Set» помогает найти процессы, у которых в отдельные моменты было больше всего физических страниц памяти. Таблицы «ТОП-15 по чтению I/O» и «ТОП-15 по записи I/O» показывают максимальные измеренные скорости ввода-вывода процессов, а не обязательно фактический объём чтения или записи на накопитель.
Физический диск и ETW: какие файлы реально участвовали в операциях
ETW (Event Tracing for Windows) — механизм трассировки событий Windows. В нашем сценарии он используется для записи коротких фрагментов операций дисковой подсистемы и сопоставления их с файловыми событиями, когда такая связь доступна.
В разделе «Физический диск (ETW)»:
- Чтение — суммарный объём зафиксированных физических операций чтения в захваченных фрагментах, а не за всё время работы компьютера.
- Запись — суммарный объём зафиксированных операций записи.
- Flush — число зафиксированных команд сброса буферов на устройство; это количество операций, не объём данных.
- Без установленного файла — операции, для которых нельзя надёжно определить имя файла; их нельзя автоматически приписывать показанным в отчёте файлам.
Например, в одном из наших тестов ETW показал операции с ISO-файлом PawelWindows.iso. Часть событий была связана с System (PID 4). Это не означает, что именно процесс System по собственной инициативе копировал ISO: он может выполнять операции от имени других компонентов Windows и обслуживать файловый кеш.
ETW включается отдельно, может покрывать лишь часть сеанса и не всегда устанавливает инициатора операции. Поэтому отчёт аккуратно разделяет наблюдаемые операции и предполагаемую связь с процессом.
Что показали испытания на Windows 10 и Windows 11
Мы проверили диагностику на нескольких сценариях, а не только на спокойной системе. На Windows 10 отдельно нагружали процессор, выделяли большой объём RAM и копировали ISO-файл. Отчёт различил три типа событий: продолжительную CPU-нагрузку, резкое сокращение доступной памяти и повышенную активность диска.
На другом компьютере тестировали нагрузку от приложения FarCryNewDawn и чтение видеофайла. Отчёт зафиксировал кратковременный CPU-пик около 99,9% и сокращение доступной RAM, но не стал утверждать, что нехватка памяти доказана.
На Windows 11 проверили копирование ZIP-файлов. HTML-отчёт сформировался, названия файлов отображались по-русски, а дисковая активность корректно объяснялась как суммарное время нескольких накопителей. Это подтверждает работу проверенного сценария на данном компьютере с Windows 11, но не гарантирует совместимость со всеми конфигурациями и сборками Windows.
Как применять диагностику на проблемном компьютере
- Уточните, в какое время возникают тормоза и как именно они проявляются.
- Если проблема происходит сейчас, проверьте Диспетчер задач и Монитор ресурсов.
- Если проблема периодическая, запустите Windows Diagnostics на ограниченный период с подходящими параметрами.
- После повторения проблемы остановите сбор и откройте HTML-отчёт.
- Сопоставьте CPU, доступную RAM и дисковую задержку с моментом жалобы.
- Посмотрите эпизоды и процессы-кандидаты; при необходимости изучите BLG, CSV и ETW.
- Проверьте предполагаемую причину отдельно и повторите замер после изменения одного фактора.
Если CPU, память и диск в нужный момент не показывают признаков ограничения, это тоже результат: дальше имеет смысл проверять сеть, драйверы, само приложение и его зависимости.
FAQ
Будет ли скрипт работать в Windows 11?
Мы успешно получили отчёт на тестовом компьютере с Windows 11. Для другого устройства желательно сначала выполнить короткий тест: доступность системных счётчиков и поведение ETW могут отличаться.
Нужно ли обязательно включать ETW?
Нет. BLG, процессный CSV и HTML-отчёт можно получать без ETW. Трассировка полезна, когда нужно подробнее исследовать физические дисковые операции, но требует дополнительных ресурсов и административных прав.
Почему в отчёте написано System (PID 4)?
Часть дисковых операций Windows выполняет в системном контексте. PID 4 не всегда указывает на приложение, инициировавшее запись или чтение.
Почему дисковое время превышает 100%?
Суммарный счётчик _Total может объединять несколько накопителей. Анализируйте отдельные диски, очередь и задержку, а не один общий процент.
Почему большой Working Set не означает нехватку RAM?
Working Set характеризует память процесса. Для оценки дефицита важно смотреть на доступный системе объём памяти и признаки давления на память, а не только на размер одного процесса.
Можно ли по HTML-отчёту сразу назвать виновника тормозов?
Не всегда. Отчёт показывает измерения, эпизоды и кандидатов по времени. Окончательный вывод требует проверки операций процесса и, по возможности, повторного замера.
Итог
Мы начали с обычной жалобы «Windows иногда тормозит» и построили воспроизводимую диагностику: от Диспетчера задач и PerfMon до автоматического сбора показателей и HTML-отчёта. Windows Diagnostics помогает увидеть когда возникла нагрузка, какой ресурс изменился и какие процессы находились рядом с событием.
Самое важное — не путать высокую активность с доказанной причиной замедления. На наших тестах скрипт обнаружил намеренно созданную нагрузку на CPU, RAM и диск, а на Windows 11 показал, почему даже суммарные 155,2% дискового времени при низкой задержке не означают автоматически неисправность накопителя.
По результатам такой диагностики можно переходить от догадок к проверяемым гипотезам — и подтверждать их повторными измерениями.