Системный процесс (PID 4) постоянно обращается к жесткому диску

Недавно я заметил, что некоторые из наших машин становятся вялыми, в основном после загрузки. Используя Resource MonitorI, я обнаружил чрезмерный доступ к диску из системного процесса с помощью PID 4. Следуя некоторым советам, я отключил антивирус в папке System Volume Information, надеясь, что это поможет (я не хочу отключать восстановление системы).

Тем не менее, кажется, что PID 4 получает доступ ко всему . При выполнении простого извлечения ZIP-файла я вижу, как WinRAR читает несколько сотен килобайт в секунду из файла, но PID 4 считывает десятки мегабайт в секунду из одного и того же файла. После отмены операции PID 4 продолжает получать доступ к файлу около 30 секунд, считывая много мегабайт в секунду. Это не ошибка монитора ресурсов, поскольку диск явно активен и останавливается, когда мониторы ресурсов сообщают, что PID 4 наконец-то отдыхает.

Почему этот чудесный процесс получает доступ ко всему, что есть у каждого другого процесса?

Я использую антивирус AVG. Отключение этого не изменило это поведение /

Что здесь происходит?

Это более старый вопрос, но у меня была эта проблема, и для меня это был SuperFetch. Я перепробовал все, что смог найти на PID 4, чрезмерное использование жесткого диска, и некоторые из них помогли. Обновление ОЗУ с 4 ГБ до 8 ГБ только сделало проблему более очевидной - использование ОЗУ было низким, подкачки не было, но жесткий диск загорелся в течение ~ 10 минут после загрузки моего ноутбука.

Короче говоря, есть параметр реестра, который контролирует, какой уровень SuperFetch подходит. Вы можете видеть ниже, что значение EnableSuperfetch теперь установлено в 1, что, по-видимому, является «предварительной загрузкой всех исполняемых файлов и библиотек». По умолчанию используется значение 3, что означает «предварительная выборка всех исполняемых файлов, библиотек и документов». У меня много документов, поэтому я думаю, что это заняло слишком много времени. Каждый открытый документ - это еще один, который SuperFetch должен «проанализировать», чтобы увидеть, как вы его используете.

Данный ключ / значение реестра: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PrefetchParameters\EnableSuperfetch

Пока единственным недостатком является то, что моим папкам Outlook требуется несколько дополнительных секунд, чтобы открыть, а некоторым часто используемым документам, таким как файлы MS Project, требуется больше времени. Но эти задержки меркнут по сравнению с трэшем, который я получал раньше!

Многие системные службы (я не имею в виду Windows Services) работают под PID 4, процесс «Система». Каждый раз, когда вы открываете файл, вы запускаете множество фоновых механизмов, таких как менеджер виртуальной памяти, кеширующий файл в памяти, перемещающий другие объекты в памяти, обслуживающий сбои страниц и т. Д. Эта активность отделена от активности диска, взимаемой с процесс, который первоначально получил доступ к файлу, например WinRAR.

Тем не менее, то, что вы описываете, все еще не звучит как нормальное поведение для меня. При обращении к файлу вы должны увидеть быстрое увеличение активности диска в процессе System, а затем довольно быстро вернуться к 0 - в течение пары секунд.

Я провел небольшое тестирование на своем компьютере с помощью Windows Resource Monitor и увидел несколько похожее поведение. Я думаю, что мы наблюдаем, как Resource Monitor показывает нам какое-то скользящее среднее, которое медленно падает.

Попробуйте посмотреть на активность диска PID 4 с помощью другого инструмента, такого как Process Explorer от Sysintenals . У меня сложилось совершенно другое впечатление, так как процесс Read Delta и Read Bytes Delta с помощью System, похоже, возвращаются к 0 намного быстрее, чем при просмотре через ResMon.

Изменить: Если это не так, то я думаю, что для ответа на вопрос потребуется более глубокий анализ. Например, вы можете перечислить загруженные в настоящий момент драйверы фильтров файловой системы с помощью fltmc.exe, а kernrate.exe может помочь вам изолировать те модули, которые вызывают чрезмерно высокий дисковый ввод-вывод.

Системный процесс используется Центром обновления Windows. Если вы выбрали автоматическую установку обновлений, вероятно, ваша система в настоящее время устанавливает программное обеспечение Windows. Если вы запустите Центр обновления Windows и попытаетесь установить обновления, вы получите сообщение о том, что вы не можете установить, поскольку Windows в настоящее время обновляет систему.

Измените Центр обновления Windows, чтобы он не загружался и не устанавливался без ручных действий, и дождитесь завершения текущей установки.

У меня были точно такие же симптомы. В моем случае они были связаны с Norton360 и службой MS-SQL VSS. Как только я отключил VSS, моя активность значительно упала. Система по-прежнему блокируется, когда Norton делает свое дело, но она почти терпима, поскольку кажется, что это происходит каждый час.

Публикация этого ответа здесь, когда я наткнулся на эту тему, когда искал ответы о том, почему системный процесс 4 потребляет так много трафика чтения / записи.

Пользователи, когда подключенные диски или выход на UNC-путь к общему ресурсу, особенно что-то со структурой каталогов хорошего размера, вдруг получат тонну непрерывного трафика от хост-сервера. Обычно я вижу 100-300к, как только вы развернетесь в навигационной панели, он начнет стрелять в диапазоне более 20,000к.

Закончилось отключение опции автоматического расширения в текущую папку в Проводнике, и этот трафик ушел.

http://www.sevenforums.com/tutorials/1014-navigation-pane-automatically-expand-current-folder.html

У меня была похожая проблема, однако в моем случае оказалось, что каким-то образом автономные файлы были включены. Я собираюсь исследовать вещи на стороне сервера (например, я думал, что это было отключено глобально через групповую политику и на общих ресурсах .....), но у меня было два компьютера с Windows 7 в удаленном офисе, весело пытающихся синхронизировать несколько сотен ГБ через VPN-соединение.

(Изменить перед публикацией: автономные файлы не были правильно отключены на общих ресурсах, возможно, после миграции сервера.