Назад | Перейти на главную страницу

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

Недавно я заметил, что некоторые из наших машин перестают работать, в основном после загрузки. Используя Resource Monitor Я обнаружил чрезмерный доступ к диску из системного процесса с помощью 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) работают под PID 4, процесс «Система». Каждый раз, когда вы открываете файл, вы запускаете множество фоновых механизмов, таких как диспетчер виртуальной памяти, кэширующий файл в памяти, перемещение других вещей в памяти, обслуживание ошибок страниц и т. Д. Эта деятельность отделена от дисковой активности, взимаемой с процесс, который первоначально обратился к файлу, например WinRAR.

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

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

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


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

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

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

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

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

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

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

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

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

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