Системний процес (PID 4), що постійно отримує доступ до жорсткого диска

Нещодавно я помітив, що деякі наші машини стають млявими, головним чином після завантаження. Використовуючи Resource Monitorя виявив надмірний доступ до диска з системного процесу за допомогою PID 4. Дотримуючись деяких порад, я відключив антивірус у папці Інформація про обсяг системи, сподіваючись, що це допоможе (я не хочу відключати відновлення системи).

Однак, схоже, 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

Поки єдиним недоліком є ​​те, що для моїх папок із зовнішнім виглядом потрібно кілька додаткових секунд, а деякі часто використовувані документи, такі як файли MS Project, займають більше часу. Але ці затримки бліді порівняно з дисковим трешем, який я отримував раніше!

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

Однак, те, що ви описуєте, досі не схоже на нормальну поведінку. Ви маєте побачити швидке підкреслення дискової діяльності з системного процесу, коли доступ до файлу, а потім він повинен повернутися до 0 досить швидко - протягом декількох секунд.

Я трохи провів тестування на власній машині за допомогою монітора ресурсів Windows, і я побачив дещо схожу поведінку. Я думаю, що ми є свідками, що це Монітор ресурсів, який показує нам якусь середню середню, яка повільно знижується.

Спробуйте переглянути активність диска PID 4, використовуючи інший інструмент, такий як Провідник процесів Sysintenals . У мене склалося набагато інше враження, оскільки, здається, дельта "Читання" та "Читання байтів" за допомогою системного процесу, схоже, повертаються до 0 набагато швидше, ніж при перегляді через ResMon.

Редагувати: Якщо це не все, я думаю, що для того, щоб відповісти на питання, знадобиться більш глибокий аналіз. Наприклад, ви можете перерахувати завантажені в даний час драйвери фільтрів файлової системи за допомогою fltmc.exe, а kernrate.exe може допомогти вам виділити ті модулі, які викликають невпинно високий диск вводу / виводу.

Системний процес використовується Windows Update. Якщо ви вибрали автоматичну установку оновлень, можливо, ваші системи зараз встановлюють програмне забезпечення Windows. Якщо ви запустите оновлення Windows і спробуєте встановити оновлення, ви отримаєте повідомлення про те, що не можете встановити, оскільки Windows наразі оновлює систему.

Змініть оновлення Windows таким чином, щоб не завантажувати та встановлювати без ручних дій, і зачекайте завершення поточної установки.

У мене були точно такі ж симптоми. У моєму випадку вони були пов'язані з Norton360 та MS-SQL VSS-службою. Після того як я відключив VSS, моя активність значно знизилася. Система все ще замикається, коли це робить Нортон, але це напівносно, оскільки, здається, це відбувається щогодини.

Опублікувавши цю відповідь тут, коли я наткнувся на цю тему, шукаючи відповіді на те, чому системний процес 4 витрачав стільки трафіку читання / запису.

Користувачі, маючи відображені накопичувачі або виїжджаючи на UNC шлях до частки, особливо щось із хорошою структурою каталогів, раптом отримали б безперервно отримувати трафік від хост-сервера. Як правило, я бачив би 100-300k, як тільки ви розширюєтеся на панелі nav, він би вистрілювався в діапазоні 20000k плюс.

Закінчилося відключення автоматичного розширення до поточної опції папки в Провіднику, і цей трафік знижується.

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

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

(Редагувати перед публікацією: офлайн-файли не були належним чином відключені в спільному доступу, можливо, після міграції сервера