Windows 10 durchschnittlich über 50 GB Schreibvorgänge pro Tag auf SSD über 9 Monate

1487
Derek Ziemba

Update: Durch das Verschieben der folgenden Ordner vom Laufwerk und deren Symlinking wurde das ständige Schreiben in C: beseitigt.

  • %LocalAppData%\Google\Chrome - Der größte Verbraucher.
  • %LocalAppData%\Microsoft\Windows\FileHistory

Ich brachte sie zu einem frisch formatierten Laufwerk. Nach 3 Stunden gab es bereits 10,5 GB Lesevorgänge und 10,3 GB Schreibvorgänge. In der gleichen Zeit hat Laufwerk C: \ nur 3,5 GB Lesevorgänge und 1,3 GB Schreibvorgänge gesehen.


Das hat mich schon eine Weile gestört. Windows 10 Education scheint ständig Daten ohne ersichtlichen Grund auf das Laufwerk C: \ zu schreiben, auch wenn der PC tagelang nicht verwendet wird. Ich kann die Quelle der Schreibvorgänge oder die Daten, die geschrieben werden, nicht finden.

In nur 9 Monaten wurden 10% der 500-GB-Laufzeiten des Samsung 850Evo verbraucht. Liegt das daran, dass Windows im Hintergrund viel protokolliert und verfolgt? Wenn dies der Grund ist, würde ich gerne wissen, wie ich es deaktivieren kann. Ich habe das Gefühl, es gibt nichts mehr, was ich vom C:\Laufwerk wegfahren könnte (mehr dazu in der Panne)

HWInfo64 hat die letzten 12,75 Tage (w / 14 Tage Betriebszeit) ausgeführt, um die Fahrstatistiken zu verfolgen. Während dieser Zeit wurde der PC vom 1. Juli bis 5. Juli oder 8. Juli nicht berührt. Ich schätze, die maximal mögliche Nutzungsdauer beträgt etwa 5 Tage, da sie an Wochentagen mindestens 18 Stunden unberührt bleibt.

Hier ist eine Aufschlüsselung der meisten Laufwerke:

  • 500 GB Samsung 850Evo ( Age: 0.7yr | HostWrites: 13.3TB(~50GB/day))

    • C:\In den letzten 2 Wochen: Es wurde nichts Neues installiert, aber 900 GB (64 GB / Tag) wurden geschrieben. Das sind 180 GB / Tag für 5 Tage. ShadowCopy (System Restore) ist auf 10% gesetzt und es gibt kein FileHistory für dieses Laufwerk.
  • 500 GB Samsung 850Evo ( Age: 1.7yr | HostWrites: 8.6TB)

    • A:\Wichtige Daten und UserProfile-Ordner werden hier zugeordnet. Dies ist das einzige Laufwerk, auf dem FileHistory aktiviert ist. ShadowCopy (Systemwiederherstellung) ist auf 15% eingestellt.
      Dies war einmal ein Windows 7 C: -Laufwerk für ungefähr ein Jahr.
  • 250 GB Samsung 840Evo ( Age: 3.7yr | HostWrites: 10.5TB) & 256 GB Crucial m4 ( Age: 4.8yr | HostWrites: 25TB)

    • D:\Laufwerke werden gepoolt, um einen Stripped StorageSpace (raid0) zu erstellen. Die PageFile, TEMP-Ordner, SoftwareDistribution, NodeJS / npm, Origin, Steam und TV-Aufzeichnungen werden hier gespeichert. Für dieses Laufwerk gibt es keine ShadowCopy (System Restore) oder FileHistory.
    • Unter Windows 7 war jedes Laufwerk gleichzeitig ein Systemlaufwerk, das 840Evo für ein Jahr und das M4 für 3 Jahre. Die m4 hat gerade in den letzten 30 Tagen zu versagen begonnen und fällt bei heftigen Schreibvorgängen oft offline. Die HWInfo-Statistiken zeigen sogar, dass sie das Gewicht nicht ziehen. StorageSpaces verwaltet das Laufwerk so gut, dass ich es noch nicht geschafft habe, das Laufwerk zu entfernen. Dies ist nach nur 25 TB HostWrites in 5 Jahren, der 850Evo ist bereits auf halbem Weg. Dies ist der motivierende Faktor hinter dieser Frage.
  • 4 TB HGST Deskstar ( Age: 2.6yr | HostWrites: 17TB) & 4 TB HGST Deskstar ( Age: 0.75yr | HostWrites: 7TB)

    • B:\& M:\Laufwerke werden gepoolt, um einen 2 TB entfernten und einen 3 TB gespiegelten Speicherbereich zu erstellen. Kein Volume verfügt über einen FileHistory- oder ShadowCopy-Schutz. Filme, Musik usw. werden auf B:\n gespeichert . M:\ist der Sicherungsspeicher für alle FileHistory-Dateien, bei denen alle 10 Minuten eine Versionskontrolle vorgenommen und eine Sicherungskopie erstellt wird.

Wie Sie sehen, schrieb Windows 7 keine Abnutzung in der Nähe von so vielen Daten. Hier ist ein Screenshot von HWInfo64.

HWInfo64-Screenshot

2

2 Antworten auf die Frage

2
bwDraco

Sie können den Task-Manager verwenden, um zu sehen, welche Prozesse die meisten Daten auf die Festplatte schreiben.

Öffnen Sie den Task-Manager, wählen Sie die Registerkarte Details, klicken Sie mit der rechten Maustaste auf den Tabellenkopf und klicken Sie auf Spalten auswählen . Überprüfen Sie dann E / A-Lesebytes, E / A-Schreibbytes und E / A-weitere Bytes, und klicken Sie auf OK .

Das heißt, ich denke, File History ist hier schuld.

Nach meiner Erfahrung können die Dateiversionsdatenbanken ( Catalog1.edbund Catalog2.edb) im Laufe der Zeit sehr groß werden. Darüber hinaus werden sie bei jeder Aktualisierung des Verlaufs vollständig neu geschrieben (alle 10 Minuten, wie auf Ihrem System konfiguriert). Windows dekomprimiert sie, wenn Sie die NTFS-Komprimierung verwenden. Dies kann im Laufe der Zeit zu großen Schreibvorgängen auf die Festplatte führen.

Unabhängig davon, welche Laufwerke vom Dateiversionsverlauf abgedeckt werden, werden diese Datenbanken in Ihrem Benutzerprofil unter gespeichert C:\Users\<username>\AppData\Local\Microsoft\Windows\FileHistory\Configuration. Bei einem Paar von 100 MB-Datenbanken werden pro Tag fast 30 GB pro Minute auf das Systemdatenträger geschrieben. Es wird vorausgesetzt, dass beide Dateien jedes Mal geschrieben werden.

Meine Lösung bestand darin, einen Knotenpunkt zu verwenden. Beenden Sie den Dateiversionsdienst, verschieben Sie den Konfigurationsordner an einen anderen Speicherort, an dem die Schreibunterbrechung kein Problem darstellt, erstellen Sie einen Knotenpunkt, der auf den neuen Speicherort anstelle des ursprünglichen Speicherorts des Ordners verweist, und starten Sie den Dateiversionsdienst neu. Das sollte das Problem beheben.

Als Nachtrag liefert Resource Monitor weitaus detailliertere Informationen und es werden weniger Prozesse ausgelassen, die möglicherweise nicht im Task-Manager angezeigt werden. Sie können über "Task-Manager"> "Leistung"> "Ressourcenmonitor"> "Datenträger" darauf zugreifen. Da der Ressourcenmonitor genau dazu gedacht ist, solche Probleme aufzuspüren, verfügt er über Filterfunktionen und Details, die der Task-Manager nicht berücksichtigt. Cliff Armstrong vor 7 Jahren 0
Ich denke, du bist auf etwas dran und könnte recht haben. Jede `Catalog # .edb`-Datei auf` C: `ist 576 MB und 588 MB auf` M: `Die Sache mit ResourceMonitor ist, dass sie nur sofortige Schreibvorgänge zeigt, nicht vollständige Schreibvorgänge. Es scheint, dass die Schreibvorgänge (in der Reihenfolge) wie folgt lauten: "$ Logfile", "system32 \ winevt \ logs", "system32 \ LogFiles", "$ Mft", "$ BitMap", "ntuser.dat" und "SystemVolumeInformation" ` Derek Ziemba vor 7 Jahren 0
Gibt es eine Möglichkeit, bestimmte FileHistory-Ordner problemlos zu bereinigen? Es geht auf den letzten Dezember zurück und enthält unnötige Dinge wie "Downloads" und den gesamten Ordner "AppData \ Roaming". In diesem Ordner werden anscheinend alle Dateien mit einer 1-KB-Datei gleichzeitig gespeichert. Ich denke, wenn es weniger Dateien gibt, um den Überblick zu behalten, würde dies die Anzahl der `Catalog # .edb'-Dateien verringern. Es gibt einige Dinge, zu denen ich immer gerne zurückgekehrt bin, wie zum Beispiel "My Document" und "Dropbox". Ich denke, es gibt einen besseren Weg, um sie zu entfernen, als einfach die entsprechenden Dateiverlaufsordner zu löschen, oder? Und das ist ein Flintenansatz. Derek Ziemba vor 7 Jahren 0
0
Eligijus Pupeikis

Stellen Sie sicher, dass das Update-Freigabesystem von Windows deaktiviert ist.

Einstellungen> Update & Sicherheit> Windows Update> Erweiterte Optionen> Wählen Sie, wie Updates abgeleitet werden.

Freigabe aktualisieren

Stellen Sie außerdem sicher, dass das Windows-Sicherungssystem nicht aktiviert ist.

Einstellungen> Update & Sicherheit> Backup.

Sie sind beide aktiviert, aber ich denke nicht, dass sie die Schreibvorgänge von Host zu C: \ beeinflussen würden. Trotzdem habe ich die Software Distribution-Funktion deaktiviert. Ich habe auch meinen Hauptbeitrag zur besseren Übersicht aktualisiert. Derek Ziemba vor 7 Jahren 0
Die Verteilung wirkt sich nur auf Lese- und Schreibvorgänge aus, und das ist immer noch vergleichbar (wahrscheinlich weniger) mit einer geöffneten Torrent-Anwendung Blaine vor 7 Jahren 0