«Сервер тормозит, но CPU не загружен» – диагностика лагов Windows VPS по счётчикам, дисковым очередям и сетевым метрикам

Почему «CPU свободен» не означает «всё хорошо»​

Типичный кейс: RDP периодически «застывает», приложения открываются с задержкой, сайт на IIS отвечает рывками, а в Диспетчере задач всего 10-15% загрузки процессора. На практике это означает одно – узкое место находится не в вычислениях. В Windows VPS чаще всего «болит» ввод-вывод (диск), память, сеть или планирование потоков, и именно там надо искать первопричину.

Виртуальный сервер легко поднять как отдельный диагностический контур – удобно, когда нужно быстро воспроизвести проблему, собрать логи и не трогать рабочую среду. В качестве примера площадки с быстрым развёртыванием Windows-сервера и понятной панелью управления подойдёт VPS.house.

Дальше – методика, которой пользуются в эксплуатации и в SOC: фиксируем симптом, переводим его в метрики, снимаем «слепок» системы в момент лагов, а затем подтверждаем гипотезу измерениями. Так диагностика перестаёт быть гаданием и превращается в инженерный процесс.

Карта причин: что именно может тормозить при низком CPU​

Когда процессор «не занят», система всё равно может ждать:

1. Диск (storage latency)
   Процесс «стоит» в ожидании чтения/записи. CPU простаивает, потому что поток заблокирован на I/O
2. Память (memory pressure)
   Оперативной памяти формально хватает «по графикам», но рабочие наборы постоянно выталкиваются, растут hard faults и чтения из pagefile. CPU не загружен, потому что идут ожидания страниц
3. Сеть (loss, retransmits, RTT, буферизация)
   Сервер «живой», но ответы уходят с задержкой из-за потерь, ретрансляций TCP или нестабильного маршрута. Особенно заметно на RDP и веб-приложениях
4. Планирование в виртуализации (scheduler)
   Даже при низком CPU внутри гостя VM может не получать время на физическом хосте ровно тогда, когда нужно. Внутри Windows это выглядит как «ничего не происходит», но снаружи – конкуренция за ресурсы
5. Блокировки и очереди внутри приложений
   Например, один поток держит lock, остальные ждут. CPU низкий, но пользователь видит лаг. Для SQL это waits, для .NET – contention, для файловых сервисов – блокировки файлов

Ниже – практический чек-лист по шагам, с конкретными счётчиками и тем, как их читать.

Принцип диагностики: от симптома к измеряемой гипотезе​

Удобная последовательность:

1. Зафиксировать «как проявляется»
   Время отклика сайта, задержка клика в RDP, «подвисание» конкретной операции, периодичность
2. Привязать к времени
   В идеале – точность до минут и секунд. Большинство лагов короткие, и без таймкода вы будете смотреть «среднюю температуру по больнице»
3. Снять метрики в момент события
   Либо потоково (логирование PerfMon), либо быстро вручную (resmon, perfmon live)
4. Исключать классы причин
   Сначала диск/память/сеть, затем планирование/приложение
5. Собирать доказательства, которые можно показать провайдеру
   PerfMon-лог, ETW-трасса, события Windows, результаты ping/pathping/tracert – всё с таймкодом

Это звучит «академично», но экономит часы. В очередях и задержках всегда действует простая логика теории очередей: как только скорость обслуживания приближается к входящему потоку запросов, задержка растёт нелинейно – даже если средняя загрузка выглядит невысокой. Поэтому «маленькая очередь» имеет значение.

Инструменты, которые есть в Windows Server «из коробки»​

Для Windows VPS удобно опираться на штатные средства:

• Диспетчер задач (Task Manager) – быстрый срез по CPU/RAM/Disk/Network, но без глубины
• Resource Monitor (resmon.exe) – показывает процессы, I/O по файлам, сетевые подключения, «Disk Response Time»
• Performance Monitor (perfmon.msc) – главный инструмент по счётчикам и логированию
• Event Viewer (eventvwr.msc) – системные события, ошибки диска/сети/служб
• typeperf / logman – сбор счётчиков в лог без GUI (работает на старых версиях Windows Server тоже)
• PowerShell Get-Counter – удобно для скриптов и быстрых выборок
• Windows Performance Recorder (WPR) / Windows Performance Analyzer (WPA) – когда нужно «вскрыть» короткие подвисания на уровне ядра, драйверов и I/O

Дальше я буду показывать варианты и через GUI, и через консоль, чтобы методика работала и на «старых» Windows Server, и на новых.

Быстрый триаж за 5 минут: понять, куда копать​

Шаг 1. Диск: есть ли задержки I/O прямо сейчас

Откройте Resource Monitor – вкладка Disk.

Смотрите:

• Disk Activity – какие процессы читают/пишут
• Response Time – если в моменты лагов растёт, это уже сигнал
• Queue Length (внизу) – растущая очередь почти всегда коррелирует с задержками

Параллельно в PerfMon добавьте:

• PhysicalDisk(*)\Avg. Disk sec/Read
• PhysicalDisk(*)\Avg. Disk sec/Write
• PhysicalDisk(*)\Current Disk Queue Length
• PhysicalDisk(*)\Disk Transfers/sec

Важно: в виртуальной машине «PhysicalDisk» часто отражает виртуальный диск. Это нормально – нас интересует задержка, которую видит гостевая ОС.

Шаг 2. Память: нет ли скрытого давления

В Task Manager – Performance – Memory: смотрите Available и Committed.

В PerfMon добавьте:

• Memory\Available MBytes
• Memory% Committed Bytes In Use
• Memory\Pages/sec
• Paging File(_Total)% Usage

Если в момент лагов растёт Pages/sec и одновременно падает Available MBytes, а диск показывает активные чтения – вероятен «пейджинг», то есть ожидание страниц с диска.

Шаг 3. Сеть: есть ли потери и ретрансляции

Быстрое тестирование:

• ping -n 50 ваш_сервер с рабочего места
• pathping ваш_сервер (дольше, но показывает потери по маршруту)

На сервере:

• netstat -s (ищем рост retransmits/segments retransmitted)
• Get-NetAdapterStatistics (на новых системах) – ошибки/дропы

В PerfMon добавьте:

• TCPv4\Segments Retransmitted/sec
• Network Interface(*)\Output Queue Length
• Network Interface(*)\Packets Outbound Errors
• Network Interface(*)\Packets Received Errors

Если ретрансляции растут – это «невидимый» тормоз, который не отражается в CPU.

«Золотой» набор счётчиков для кейса «тормозит, CPU низкий»​

Ниже – практический набор, который почти всегда даёт ответ, если собирать его 10-30 минут с интервалом 1-5 секунд.

CPU и планирование

• Processor(_Total)% Processor Time
• System\Processor Queue Length
• System\Context Switches/sec
• Processor(_Total)% Privileged Time
• Processor(_Total)% DPC Time
• Processor(_Total)\Interrupts/sec

Почему это важно: CPU может быть «низким», но при этом система тратит время на прерывания/DPC или контекстные переключения, что субъективно воспринимается как лаги.

Память

• Memory\Available MBytes
• Memory% Committed Bytes In Use
• Memory\Pages/sec
• Memory\Page Reads/sec
• Paging File(_Total)% Usage

Тонкость: Pages/sec сам по себе не «приговор». Важна связка – падение доступной памяти + рост page reads + параллельная дисковая активность.

Диск

• PhysicalDisk(*)\Avg. Disk sec/Read
• PhysicalDisk(*)\Avg. Disk sec/Write
• PhysicalDisk(*)\Current Disk Queue Length
• PhysicalDisk(*)\Disk Transfers/sec
• PhysicalDisk(*)\Disk Read Bytes/sec
• PhysicalDisk(*)\Disk Write Bytes/sec
• LogicalDisk(*)% Free Space

Очередь диска без задержки – ещё не беда. Задержка без очереди – бывает (например, storage «подвисает» короткими стоп-кадрами). Поэтому смотрим в паре.

Сеть

• TCPv4\Segments Retransmitted/sec
• TCPv4\Connections Established
• Network Interface(*)\Bytes Total/sec
• Network Interface(*)\Output Queue Length
• Network Interface(*)\Packets Outbound Errors / Received Errors

Для RDP дополнительно полезно фиксировать субъективное время отклика и сопоставлять с ростом retransmits и RTT.

Как собрать лог PerfMon так, чтобы потом не гадать​

Вариант 1. Data Collector Set через GUI

1. perfmon.msc
2. Data Collector Sets – User Defined – New – Data Collector Set
3. Create manually – Performance counter
4. Добавьте счётчики из «золотого набора»
5. Sample interval: 1-5 seconds
6. Сохраните в отдельную папку, включите, дождитесь проявления лагов, выключите

Плюс: удобно и наглядно. Минус: нужно помнить включить заранее.

Вариант 2. typeperf в консоли (универсально)

Пример: лог диска и памяти на 15 минут (900 секунд) с интервалом 5 секунд:

typeperf "\PhysicalDisk(_Total)\Avg. Disk sec/Read" "\PhysicalDisk(_Total)\Avg. Disk sec/Write" "\PhysicalDisk(_Total)\Current Disk Queue Length" "\Memory\Available MBytes" "\Memory\Pages/sec" -si 5 -sc 180 -f CSV -o C:\perf\diag.csv

Файл CSV потом легко открыть и увидеть, что именно «взлетало» во время тормозов.

Диск и очереди: где чаще всего прячется причина​

Почему «Disk Queue Length» пугает, но не всегда означает проблему

Очередь – это не «плохо» сама по себе. Очередь – это показатель того, что запросы стоят на обработку. Важно, сколько времени они там стоят. Поэтому связка «очередь + задержка» важнее каждого параметра отдельно.

Практический способ читать картину:

• Растёт Avg. Disk sec/Read или Avg. Disk sec/Write – значит, увеличилась задержка операций
• Вместе с этим растёт Current Disk Queue Length – значит, запросов больше, чем диск успевает обслужить сейчас
• Параллельно смотрим Disk Transfers/sec – чтобы понимать, «много мелких» или «мало крупных» операций

«Split IO/sec» и мелкие блоки

Если добавить счётчик:

• PhysicalDisk(*)\Split IO/sec

…и он растёт в моменты лагов, это косвенно намекает на фрагментацию запросов или особенности паттерна записи (например, много мелких синхронных операций). На VPS такое часто бывает у баз данных и логов, а также у приложений, которые пишут «по чуть-чуть» и постоянно делают flush.

Быстрая привязка дисковых лагов к процессу

Resource Monitor – вкладка Disk:

• сортируйте по Total (B/sec) и по Response Time
• смотрите «File» – какой именно файл «молотит» диск

Очень часто виновник прозаичен:

• антивирусный скан
• Windows Update
• индексатор
• логирование
• резервное копирование
• приложение пишет огромный лог в один файл

Дальше решение зависит от причины: перенос логов на другой том, ограничение ретенции, настройка исключений в Defender, изменение режима логирования.

Память: когда тормоза похожи на «диск», но причина – RAM​

Классическая ловушка: диск «занят», но вы лечите storage, хотя реальная причина – пейджинг.

Что происходит:

• рабочим наборам процессов не хватает RAM
• Windows начинает активно вытеснять страницы
• при обращении к данным идут page reads
• диск занят «служебными» чтениями
• CPU при этом может оставаться низким

Сигналы в метриках:

• падает Memory\Available MBytes
• растёт Memory% Committed Bytes In Use
• растёт Memory\Page Reads/sec и Pages/sec
• одновременно в диске растут чтения, но не обязательно большие объёмы – часто это много мелких операций

Практический приём: в Task Manager откройте вкладку Details, добавьте колонку Commit size и Working set – иногда «тихий» процесс держит огромный commit и провоцирует пейджинг.

Сеть: почему «всё быстро» по Speedtest, но RDP лагает​

Speedtest и «ширина канала» часто вообще не про вашу проблему. Для интерактивных протоколов важнее:

• RTT (задержка туда-обратно)
• jitter (разброс задержки)
• loss (потери)
• retransmits (повторные передачи TCP)

RDP чувствителен к микропотерям: пользователь видит «зависание», хотя общая скорость канала высокая.

Что делать:

• С рабочего места: ping -n 200 и pathping – ловим потери и стабильность
• На сервере: netstat -s – смотрим, растут ли retransmits
• В PerfMon: TCPv4\Segments Retransmitted/sec – сопоставляем по времени с лагами

Если retransmits растут «волнами» – проблема может быть вне сервера: маршрутизация, Wi-Fi, провайдер пользователя, перегруженный канал в офисе. Диагностика всё равно полезна – вы сможете доказать, что на стороне VPS нет перегруза CPU/RAM/Disk в моменты лагов.

Планирование в виртуализации: «CPU низкий», но потокам не дают работать​

Это сложная часть, потому что гостевая Windows не всегда видит «реальную» конкуренцию на хосте. Но косвенные признаки есть.

Смотрите:

• System\Processor Queue Length – если очередь процессора растёт, значит, потокам не хватает «времени выполнения» прямо сейчас
• System\Context Switches/sec – резкие всплески могут означать дрожание планирования
• Processor% Privileged Time, % DPC Time – если растут, часть времени уходит в ядро/обработку прерываний

Что можно сделать прикладно:

• проверить, не упираетесь ли в лимиты vCPU/RAM по вашему тарифу
• исключить фоновые задачи и «пилы» обновлений
• зафиксировать PerfMon-лог и отдать провайдеру – на стороне хоста могут проверить contention, storage latency на узле и сетевые показатели

RDP как индикатор здоровья: как отделить «сервер лагает» от «канал лагает»​

Когда жалоба звучит как «тормозит сервер», RDP часто является единственным «окном» наблюдения, и это опасно: RDP сам может деградировать из-за сети.

Минимальный подход:

• Одновременно фиксируйте PerfMon на сервере и ping/pathping со стороны клиента
• Если на сервере метрики стабильны, а у клиента растёт RTT/потери – первопричина вне VPS
• Если на сервере в те же минуты растут disk latency или paging – первопричина в ресурсах/нагрузке

На практике это один из самых быстрых способов перестать спорить «кто виноват» и перейти к фактам.

Типовые сценарии и «короткие» решения​

Сценарий 1. Диск «подвисает» короткими стоп-кадрами

Признаки:

• Avg. Disk sec/Read/Write вспыхивает пиками
• очередь на диске подпрыгивает
• пользователь видит «фризы» на 1-3 секунды

Что делать:

• привязать к процессу через resmon
• проверить события диска в Event Viewer
• временно отключить/перенести тяжёлое логирование и задачи обслуживания
• при необходимости – эскалировать провайдеру с PerfMon-логом и таймкодами

Сценарий 2. Пейджинг маскируется под «медленный диск»

Признаки:

• растут Pages/sec и Page Reads/sec
• падает Available MBytes
• диск занят мелкими чтениями

Что делать:

• добавить RAM или оптимизировать приложение
• убрать «прожорливые» процессы
• настроить лимиты/пулы
• проверить, нет ли утечки памяти

Сценарий 3. Сеть даёт потери, а CPU/RAM/Disk нормальные

Признаки:

• TCP retransmits растут
• ping/pathping показывает потери или нестабильный RTT
• серверные метрики спокойные

Что делать:

• локализовать участок сети (офисный Wi-Fi, VPN, провайдер, маршрут)
• тестировать с другого подключения
• фиксировать доказательства (pathping, tracert, временные окна)

Как подготовить «пакет диагностики», который действительно помогает​

Когда проблема повторяется, полезно иметь стандартный пакет:

1. PerfMon-лог с «золотым набором» (1-5 секунд интервал)
2. Экспорт событий Windows за нужный период (System, Application)
3. Пара тестов сети со стороны клиента: ping, pathping (с таймкодами)
4. Скриншот/выгрузка resmon с Disk Activity и Network
5. Краткое описание: «в 12:41:30 по Москве RDP завис на 4 секунды, одновременно вырос Avg. Disk sec/Read»

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

Вывод: лаги без CPU – это не мистика, а метрики​

Ситуация «сервер тормозит, но CPU не загружен» почти всегда объясняется ожиданиями – дисковыми, сетевыми или памятью – и хорошо ловится счётчиками Windows. Главное – не смотреть на один график, а сопоставлять сразу несколько слоёв: задержку диска и очередь, доступную память и page reads, ретрансляции TCP и ощущение «подвисаний» в RDP.

Выбор платформы тоже влияет на повторяемость таких проблем, но оценивать его стоит не по рекламным обещаниям, а по проверяемым признакам: современное хранилище, прозрачные лимиты ресурсов, предсказуемая сеть, возможность быстро менять конфигурацию под реальную нагрузку. Протестировать описанные выше рекомендации как на «диагностическом стенде» можно взяв на пару дней VPS-сервер под управлением Windows на VPS.house: быстро зафиксировать базовые метрики (очередь диска, латентность сети, пики по IOPS, поведение памяти), проверить гипотезы без риска для боевого контура и повторить тест после изменений – например, переноса логов на другой диск, настройки антивирусных исключений для рабочих каталогов или корректировки сетевых параметров. Такой подход экономит время: вместо «сервер вроде бы тормозит» вы получаете измеряемую причину и понятный план исправления.