Processo di sistema (PID 4) che accede costantemente al disco rigido

Di recente ho notato che alcune delle nostre macchine stanno diventando lente, soprattutto dopo l'avvio. Utilizzando il Resource MonitorRID ho rilevato un accesso eccessivo al disco dal processo di sistema. Seguendo alcuni suggerimenti, ho disabilitato l'antivirus nella cartella Informazioni sul volume del sistema, sperando che possa essere d'aiuto (non desidero disabilitare il ripristino del sistema).

Tuttavia, sembra che PID 4 stia accedendo a tutto . Quando eseguo una semplice estrazione di un file ZIP, posso vedere WinRAR leggere alcune centinaia di KB al secondo dal file, ma PID 4 legge dozzine di MB al secondo dallo stesso file. Dopo aver annullato l'operazione, PID 4 continua ad accedere al file per circa 30 secondi, leggendo molti MB al secondo. Questo non è un bug di Resource Monitor, poiché il disco è chiaramente attivo e si interrompe quando i monitor di risorse indicano che il PID 4 è finalmente in pausa.

Perché questo processo miracoloso accede a tutto ciò a cui ogni altro processo accede?

Sto usando l'antivirus AVG. Disabilitarlo non ha cambiato questo comportamento /

Cosa sta succedendo qui?

Questa è una domanda più vecchia, ma ho avuto questo problema, e per me era SuperFetch. Ho provato tutto ciò che ho potuto trovare sull'utilizzo eccessivo del disco rigido PID 4 e alcuni di questi mi hanno aiutato. Un aggiornamento della RAM da 4 GB a 8 GB ha solo reso il problema più ovvio: l'utilizzo della RAM era basso, nessun paging, ma il disco rigido è stato acceso per ~ 10 minuti dopo l'avvio del mio laptop.

Per farla breve, c'è un'impostazione del registro che controlla quale livello di SuperFetch è appropriato. Di seguito puoi vedere il valore EnableSuperfetch è ora impostato su 1, che sembra essere "prefetch tutti gli eseguibili e le librerie". Il valore predefinito è 3, che sembra significare "precaricare tutti gli eseguibili, le librerie e i documenti". Ho molti documenti, quindi penso che ci sia voluto troppo tempo. Ogni documento aperto è un altro che SuperFetch deve "analizzare" per vedere come lo stai usando.

La chiave / valore di registro in questione è: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PrefetchParameters\EnableSuperfetch

Finora l'unico aspetto negativo è che le mie cartelle di Outlook richiedono alcuni secondi in più per aprirsi e alcuni documenti di uso comune come i file MS Project richiedono più tempo. Ma quei ritardi impallidiscono rispetto al thrash su disco che stavo ottenendo prima!

Molti servizi di sistema (non intendo i servizi di Windows) funzionano con PID 4, il processo "Sistema". Ogni volta che apri un file, attivi una serie di meccanismi in background come il gestore della memoria virtuale che memorizza nella cache il file in memoria, sposta altre cose in memoria, gestisce gli errori della pagina, ecc. Tale attività è separata dall'attività del disco addebitata sul processo che originariamente accedeva al file, ad esempio WinRAR.

Detto questo, quello che stai descrivendo non mi sembra un comportamento normale. Dovresti vedere un rapido aumento dell'attività del disco dal processo di Sistema quando si accede al file, quindi dovrebbe tornare a 0 piuttosto rapidamente - entro un paio di secondi.

Ho fatto un piccolo test sul mio computer utilizzando Windows Resource Monitor e ho riscontrato comportamenti simili. Quello a cui penso di assistere è che Resource Monitor ci mostra una sorta di media mobile che è lenta a scendere.

Prova a guardare l'attività del disco PID 4 usando un altro strumento come Process Explorer di Sysintenals . Ho avuto un'impressione molto diversa da essa, dal momento che il processo di lettura Delta e Read Byte Delta del processo di sistema sembra tornare a 0 molto più velocemente rispetto a quando visualizzato tramite ResMon.

Modifica: in caso contrario, penso che sarà necessaria un'analisi più approfondita per rispondere alla domanda. Ad esempio, puoi elencare i driver di filtro del file system attualmente caricati con fltmc.exe e kernrate.exe può aiutarti a isolare quei moduli che causano I / O del disco eccessivamente alti.

Il processo di sistema viene utilizzato da Windows Update. Se hai scelto di installare gli aggiornamenti automaticamente, è probabile che il tuo sistema stia installando il software Windows. Se si esegue Windows Update e si tenta di installare gli aggiornamenti, verrà visualizzato un messaggio in cui si dice che non è possibile installare poiché Windows sta attualmente aggiornando il sistema.

Modificare Windows Update in modo che non venga scaricato e installato senza azione manuale e attendere il completamento dell'installazione corrente.

Ho avuto gli stessi identici sintomi. Nel mio caso erano collegati a Norton360 e al servizio VSS MS-SQL. Una volta disabilitato VSS, la mia attività è diminuita in modo significativo. Il sistema si blocca ancora quando Norton fa le sue cose, ma è semi sopportabile poiché sembra accadere solo ogni ora.

Pubblicando questa risposta qui mentre mi sono imbattuto in questo thread quando cercavo risposte sul perché il processo di sistema 4 consumava così tanto traffico in lettura / scrittura.

Gli utenti che hanno mappato le unità o escono in un percorso UNC per una condivisione, in particolare qualcosa con una struttura di directory di buone dimensioni, all'improvviso avrebbero una tonnellata di traffico continuo ricevuto dal server host. Normalmente vedrei 100-300k, non appena si espande nel riquadro di navigazione, si spara nella gamma di oltre 20.000k.

Alla fine si disabilita l'opzione di espansione automatica nella cartella corrente in Explorer e il traffico scompare.

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

Ho avuto un problema simile, tuttavia nel mio caso sembra che in qualche modo i file offline siano stati abilitati. Esaminerò le cose sul lato server (ad esempio, pensavo che fosse disabilitato a livello globale tramite Criteri di gruppo e sulle condivisioni .....) ma avevo due macchine Windows 7 in un ufficio remoto che cercavano allegramente di sincronizzare diverse centinaia GB tramite una connessione VPN.

(Modifica prima della pubblicazione: i file offline non sono stati disabilitati correttamente sulle condivisioni, probabilmente a seguito di una migrazione del server.