Processo do sistema (PID 4) acessando constantemente o disco rígido

Recentemente, notei que algumas de nossas máquinas estão ficando lentas, principalmente após a inicialização. Usando o Resource MonitorDetecto acesso excessivo ao disco do processo do sistema com o PID 4. Após algumas dicas, desabilitei o antivírus na pasta Informações do volume do sistema, esperando que ajude (não quero desabilitar a restauração do sistema).

No entanto, parece que o PID 4 está acessando tudo . Ao executar uma extração simples de um arquivo ZIP, posso ver o WinRAR lendo algumas centenas de KBs por segundo no arquivo, mas o PID 4 lê dezenas de MBs por segundo no mesmo arquivo. Após o cancelamento da operação, o PID 4 continua acessando o arquivo por cerca de 30 segundos, lendo muitos MBs por segundo. Este não é um bug do Monitor de Recursos, pois o disco está claramente ativo e para quando os monitores de recursos dizem que o PID 4 está finalmente em repouso.

Por que esse processo milagroso está acessando tudo o que todos os outros processos acessam?

Estou usando o antivírus AVG. Desativá-lo não mudou esse comportamento /

O que está acontecendo aqui?

Essa é uma pergunta mais antiga, mas eu tinha esse problema e, para mim, era o SuperFetch. Eu tentei tudo o que pude encontrar no uso excessivo do disco rígido do PID 4 e algumas delas ajudaram. Uma atualização de RAM de 4 GB para 8 GB apenas tornou o problema mais óbvio - o uso da RAM era baixo, sem paginação, mas o disco rígido ficou aceso por aproximadamente 10 minutos após a inicialização do meu laptop.

Para encurtar a história, há uma configuração de registro que controla qual nível de SuperFetch é apropriado. Você pode ver abaixo o valor EnableSuperfetch agora está definido como 1, o que parece ser "pré-buscar todos os executáveis ​​e bibliotecas". O padrão é 3, o que parece significar "pré-buscar todos os executáveis, bibliotecas e documentos". Eu tenho muitos documentos, então acho que isso estava demorando muito. Todo documento aberto é outro que o SuperFetch precisa "analisar" para ver como você o está usando.

A chave / valor do registro em questão é: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PrefetchParameters\EnableSuperfetch

Até agora, a única desvantagem é que minhas pastas do Outlook demoram alguns segundos extras para abrir e alguns documentos comumente usados, como arquivos do MS Project, levam mais tempo. Mas esses atrasos empalidecem em comparação com o thrash de disco que eu estava recebendo antes!

Muitos serviços do sistema (não me refiro aos Serviços do Windows) são executados no PID 4, o processo "Sistema". Sempre que você abre um arquivo, você aciona uma série de mecanismos de segundo plano, como o gerenciador de memória virtual, que armazena em cache o arquivo na memória, move outras coisas na memória, repara falhas da página etc. Essa atividade é separada da atividade do disco cobrada no processo que acessou originalmente o arquivo, por exemplo, WinRAR.

Dito isto, o que você está descrevendo ainda não parece um comportamento normal para mim. Você verá um rápido aumento na atividade do disco no processo do sistema quando o arquivo for acessado e, em seguida, voltará a 0 rapidamente - em alguns segundos.

Fiz um pequeno teste em minha própria máquina usando o Windows Resource Monitor e vi um comportamento semelhante. O que acho que estamos testemunhando é o Monitor de Recursos, mostrando-nos algum tipo de média móvel que demora a cair.

Tente examinar a atividade do disco do PID 4 usando outra ferramenta como o Process Explorer da Sysintenals . Tive uma impressão muito diferente, pois o processo Read Delta e Read Bytes Delta pelo sistema parecem retornar a 0 muito mais rapidamente do que quando vistos pelo ResMon.

Edit: Se não for isso, acho que será necessária uma análise mais aprofundada para responder à pergunta. Por exemplo, você pode listar os drivers de filtro do sistema de arquivos carregados no momento com fltmc.exe e o kernrate.exe pode ajudar a isolar os módulos que estão causando E / S de disco excessivamente alta.

O processo do sistema é usado pelo Windows Update. Se você optou por instalar as atualizações automaticamente, provavelmente seus sistemas estão instalando o software Windows. Se você executar o Windows Update e tentar instalar as atualizações, receberá uma mensagem informando que não pode instalar, pois o Windows está atualizando o sistema.

Altere o Windows Update para não baixar e instalar sem ação manual e aguarde a conclusão da instalação atual.

Eu tive exatamente os mesmos sintomas. No meu caso, eles estavam relacionados ao Norton360 e ao serviço MS-SQL VSS. Depois que desabilitei o VSS, minha atividade caiu significativamente. O sistema ainda trava quando o Norton faz isso, mas é semi suportável, pois parece que acontece a cada hora.

Ao postar esta resposta aqui, eu me deparei com esse tópico ao procurar respostas sobre por que o processo 4 do sistema consumia tanto tráfego de leitura / gravação.

Os usuários que, ao mapearem unidades ou seguirem para um caminho UNC para um compartilhamento, especialmente algo com uma estrutura de diretórios de bom tamanho, repentinamente teriam uma tonelada de tráfego de recepção continuamente do servidor host. Normalmente eu veria 100-300k, assim que você se expandisse no painel de navegação, ele dispararia na faixa de 20.000k plus.

Acabou desativando a opção expandir automaticamente para a pasta atual no Explorer e esse tráfego desaparece.

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

Eu tive um problema semelhante, no entanto, no meu caso, parece que de alguma forma os Arquivos Off-line foram ativados. Eu vou investigar as coisas no lado do servidor (por exemplo, eu pensei que estava desativado globalmente via Diretiva de Grupo e nos compartilhamentos ...), mas eu tinha duas máquinas com Windows 7 em um escritório remoto tentando alegremente sincronizar várias centenas GB através de uma conexão VPN.

(Editar antes da postagem: os arquivos offline não foram desativados corretamente nos compartilhamentos, possivelmente após uma migração do servidor.