Операционная система Windows имеет устойчивую репутацию: свежая установка работает быстро, а через год или два эксплуатации та же машина на том же железе загружается дольше, медленнее открывает проводник и реже справляется с теми же задачами. Пользователь при этом может честно утверждать, что ничего не скачивал и новых программ не ставил. Механика здесь реальна и хорошо измерима, но она никак не связана со сказками о вирусе замедления или о намеренном ухудшении производительности со стороны разработчика. Система замедляется потому, что её внутренние хранилища данных непрерывно растут и редко сокращаются обратно. Реестр, хранилище компонентов, страничный файл, индексы поиска, журналы событий, кэши и планировщик заданий работают в одностороннем режиме накопления: данные добавляются в результате нормальной эксплуатации, а удаляются лишь частично. Эта статья разбирает конкретные механизмы накопления энтропии и показывает, какие встроенные средства позволяют удерживать систему в состоянии, близком к свежей установке.
Реестр как первое хранилище остатков
Реестр Windows представляет собой набор кустов, физически размещённых в файлах каталога C:\Windows\System32\config. При запуске системы значительная часть этих файлов считывается и удерживается в памяти, а любые обращения к ним выполняются как операции поиска по структурам. Каждая установка программы создаёт ветки в разделах HKLM и HKCU, прописывает расширения файлов, ссылки на библиотеки COM, пункты деинсталляции и параметры служб. Деинсталляция в идеальном случае удаляет эти записи, но на практике большинство деинсталляторов очищают только то, что они сами зафиксировали при установке. Записи, созданные программой уже в процессе работы, общие классы COM, зарегистрированные другими приложениями, и персональные настройки пользователя остаются.
За годы эксплуатации машина переживает десятки и сотни циклов установки и удаления. Каждый цикл оставляет реестр немного больше, чем он был. Дополнительный объём сам по себе не страшен: современный процессор ищет по отсортированным структурам быстро. Проблема в другом. Во-первых, увеличивается время выборки при загрузке, когда система читает кусты целиком. Во-вторых, ключи с невалидными ссылками заставляют подсистемы выполнять запросы к несуществующим путям, и таймауты таких операций складываются в заметные паузы при старте приложений. В-третьих, расширения и обработчики, оставшиеся от удалённых программ, попадают в контекстное меню проводника, и каждое открытие меню заставляет систему пытаться подгрузить отсутствующие компоненты. Плюс к этому удалённые ключи физически не освобождают место в файле куста: файлы кустов приобретают внутреннюю фрагментацию, что замедляет обход.
Хранилище компонентов WinSxS и обновления
Каталог C:\Windows\WinSxS является хранилищем сторе компонентов и содержит все версии системных файлов, из которых собирается система. Каждое накопительное обновление добавляет в него новые версии библиотек и драйверов, сохраняя старые, чтобы обеспечить откат. Системный каталог System32 большей частью состоит из жёстких ссылок на файлы в этом хранилище, поэтому реальный размер WinSxS и то, что показывает проводник, отличаются, но тенденция к росту объективна.
На машине без регулярного обслуживания хранилище может вырасти на десятки гигабайт. Сам по себе объём мало влияет на скорость, но влияют связанные эффекты: сканирование хранилища задачами обработки обновлений, работа Модуля установщика Windows при каждом патче, сбои при обновлении из-за избытка заменённых пакетов. Инструментальная команда DISM /Online /Cleanup-Image /StartComponentCleanup удаляет заменённые версии компонентов, а флаг /ResetBase дополнительно исключает возможность отката установленных обновлений, сокращая хранилище максимально.
Точки восстановления, журналы, логи и временные каталоги
Система защиты Windows создаёт точки восстановления при установке драйверов и обновлений. Каждая точка занимает место в скрытом каталоге System Volume Information; при дефиците пространства старые точки удаляются, но пользователь, выделивший восстановлению десятки гигабайт, получает их всё снова. Журналы событий Application, System и Security растут непрерывно; хотя они имеют кольцевую природу, заданный размер в сотни мегабайт и обилие информационных событий приводят к большим файлам. Добавляются диагностические логи в PerfLogs, отчёты WER в ProgramData\Microsoft\Windows\WER, логи доставки обновлений и трассировки планировщика.
Временные каталоги %TEMP%, C:\Windows\Temp и Prefetch тоже накапливают файлы. Prefetch сознательно копит трассировки запуска, чтобы ускорять старт программ, и обычно полезен, но Temp засоряется orphaned-файлами инсталляторов и артефактами сбоев. Кэш миниатюр в Local\Microsoft\Windows\Explorer растёт пропорционально числу просмотренных изображений. Индексатор поиска хранит базу Windows.edb, которая на активном профиле достигает нескольких гигабайт и периодически перестраивается. На замедление влияет больше не суммарный объём, а число объектов: сотни тысяч мелких файлов тормозят обход каталогов, операции антивируса и резервное копирование. Очистку выполняет классический cleanmgr, автоматизация есть в Storage Sense, а точки восстановления удаляются через свойства защиты системы или через vssadmin.
Автозагрузка, службы и планировщик заданий
Каждая поставленная программа стремится стартовать вместе с системой, а после удаления не все такие записи исчезают. Места регистрации автозапуска: Run и RunOnce в реестре, папка автозагрузки пользователя и общая автозагрузка, задачи планировщика с триггером при входе, службы с типом запуска Auto. Чем больше элементов добавлено, тем дольше готовка рабочего стола после входа и тем выше фоновая нагрузка. Программы ставят агенты обновления, помощники печати, ускорители запуска, которые в реальности только держат процесс в памяти.
Отдельная статья накопления - планировщик заданий. На взрослой системе в Microsoft\Windows существуют десятки задач телеметрии, оценки совместимости, диагностики и обслуживания. Производители устройств и приложений добавляют задачи проверки обновлений, которые деинсталлятор не удаляет. Каждая задача при пробуждении порождает процесс, читающий диск и потребляющий память. Фактическую нагрузку удобно оценивать через ветку Task Scheduler Library и вкладку Startup диспетчера задач, где столбец Startup impact показывает время старта каждого элемента.
Тип запуска служб Auto означает, что служба стартует в общей очереди инициализации. Десятки таких служб читают конфигурацию из реестра последовательно, и очередь вытягивается. Перевод второстепенных служб в режим Delayed Start уменьшает стартовую очередь, но не избавляет от накопления самих служб. Архивные драйверы устройств, службы принтеров, забытые виртуальные адаптеры и устаревшие агенты мониторинга продолжают загружаться.
Pagefile, hiberfil и файл подкачки
Ядро Windows по умолчанию размещает pagefile.sys на системном диске и автоматически управляет его размером. При активной работе с большими объёмами памяти система растит файл подкачки, и возврат к исходному размеру происходит не всегда. На машине с 16 гигабайтами ОЗУ и историей интенсивной работы pagefile.sys может весить десятки гигабайт. Hiberfil.sys по объёму сравним с частью ОЗУ и существует, даже если пользователь никогда не использует гибернацию. Кроме дискового пространства есть эффект размазывания данных: чем сильнее распределены перемещаемые страницы по диску, тем медленнее обращение к ним на HDD.
Уменьшить эти файлы можно штатными средствами: powercfg /hibernate off удаляет hiberfil.sys, размер файла подкачки задаётся в дополнительных параметрах быстродействия. Важно понимать границы: полное отключение подкачки на системе со скудной памятью приводит к сбоям приложений, так как часть системных резервирований требует наличия commit.
Фрагментация HDD и особенности SSD
Эффект медленной работы на жёстком диске объясняется не только накоплением данных, но и геометрией их размещения. Когда файл создаётся, удаляется и создаётся заново, свободное пространство превращается в мозаику мелких участков. Новые большие файлы пишутся фрагментами в разные физические области, и для последовательного чтения головка диска делает десятки перемещений. Системные файлы размещаются в начале диска при установке, поэтому свежая система грузится быстро; через годы добавления новых файлов части системных файлов оказываются распределёнными по диску, и загрузка замедляется на десятки секунд.
Оптимизация выполняется штатным dfrgui; планировщик запускает дефрагментацию еженедельно. Дефрагментация эффективна на HDD и бесполезна на файловом уровне для SSD, где время доступа к блоку одинаково. Однако на SSD вступает в игру иная энтропия: контроллер накапливает состояние полузаполненных блоков, и по мере исчерпания резервных страниц производительность записи падает. Команда TRIM сообщает накопителю о неиспользуемых блоках, и если давно не выполнялась оптимизация тома, эффективность сборки мусора снижается. Штатный оптимизатор дисков сам различает тип накопителя: для HDD он дефрагментирует, для SSD - посылает TRIM на том.
Базы драйверов и периферийные остатки
Каждое устройство, подключённое к машине, оставляет пакет драйвера в DriverStore. Смена видеокарты, сетевых адаптеров, принтеров и телефонов добавляет комплекты пакетов, которые не удаляются при отключении устройства. Видеодрайверы - крупнейшие потребители места: каждая новая версия добавляет пакет в сотни мегабайт, и деинсталлятор удаляет предыдущие версии далеко не всегда. При каждой загрузке система перечисляет устройства, включая отсутствующие, и время энумерации растёт. Скрытые устройства видны в диспетчере устройств через View - Show hidden devices, а устаревшие пакеты вычищаются через pnputil /enum-drivers и pnputil /delete-driver oemNN.inf с осторожностью.
Дополнительно копятся шрифты в Fonts: каждый шрифт перечисляется при старте графической подсистемы. Счётчики производительности при повреждении приходится восстанавливать через lodctr /R, иначе часть системных утилит теряет метрики. Лишние записи сетевых профилей брандмауэра и профили беспроводных сети накапливаются при смене окружения и тоже берут своё время при инициализации интерфейсов.
Эффект новой установки
Практика показывает устойчивый разрыв в показателях между свежей и годовалой системой на одинаковом железе. Время от нажатия кнопки до готовности рабочего стола на свежей системе на SSD составляет порядка пятнадцати-двадцати секунд, а на годовалой с разросшимся автозапуском и задачами может удвоиться. Проводник на свежей системе открывает This PC почти мгновенно; на старой системе та же операция с пробуждением сетевых ресурсов и иконками обработчиков растягивается до нескольких секунд. Старт офисных приложений отличается на полсекунды и больше. Эти величины не катастрофичны по отдельности, но пользователь сталкивается с ними десятки раз в день.
Переустановка возвращает систему в быстрое состояние, потому что сбрасывает накопленные объёмы: пустой реестр из образа, WinSxS установочного среза, пустые журналы, отсутствие драйверов отсутствующих устройств. Однако переустановка - не единственный путь. Систематическое обслуживание штатными средствами достигает близкого эффекта без потери настроек:
- Ежемесячный запуск Storage Sense с чисткой временных файлов, корзины и папки загрузок.
- Очистка точек восстановления через свойства защиты системы с сохранением одной актуальной точки.
- Выполнение DISM /Online /Cleanup-Image /StartComponentCleanup после каждого крупного накопительного обновления.
- Проверка и отключение лишних элементов автозагрузки через диспетчер задач и Autoruns.
- Запуск оптимизации дисков для дефрагментации HDD и обновления TRIM на SSD.
После такого цикла большинство разрывов с свежей системой уменьшаются до нескольких процентов, что подтверждается прямым замером времени загрузки и отклика оболочки через Windows Performance Recorder.
Миф о вирусе замедления против реальной механики
Широко распространено представление, что система тормозит из-за скрытого вредоносного процесса или потому, что после какого-то срока встроенный счётчик сознательно снижает производительность. Ни тот ни другой механизм не подтверждается практикой. Вредоносные процессы действительно потребляют ресурсы, но современные майнеры и ботнет-агенты скрываются и снижают активность при работе пользователя, так что их влияние отличается от повсеместного замедления. Ограничений производительности по таймеру в коде Windows не существует: подобный код легко обнаруживался бы при анализе образа.
Реальная механика куда скучнее: система опирается на хранилища, которые растут в одну сторону. Каждое действие пользователя и каждое обновление добавляют данные, а удаление происходит через неполные деинсталляторы, кольцевые журналы и неторопливое обслуживание. Разница между быстрой и медленной машиной после года работы определяется не железом и не злонамеренностью, а суммой накопленных объектов и тем, проводилось ли обслуживание.
Отсюда следует простая стратегия: автоматические задачи Storage Sense, контроль хранилища компонентов после обновлений, ревизия автозапуска раз в квартал, аккуратное обращение с точками восстановления и дисциплина установки программ. Выполнение этих пунктов удерживает Windows около показателей свежей установки годами и устраняет соблазн приписывать замедление мифическим механизмам.