14
Windows Server 2012 R2 frisst SSDs (cbs.log)
Hallo,
ich habe vor etwa 2 Monaten eine nur etwa 3 Monate alte SSD gegen eine neue getauscht (Samsung OEM Datacenter SSD SM883) in einem Windows Server 2012 R2. Die ist für das System (Laufwerk C
, die Daten sind alle auf einem RAID. Damals hatte ich ein 20 GB CBS.log und der bekannte, uralte Windowsbug "cbs.log größer als 2 GB" schlug zu. Dabei wird die Datei dann immer eine WER kopiert, sobald er fertig ist, fängt er neu an. SSD nach zwei Monaten Dauerschreiben durch, 300 Euro weg, Danke Microsoft. Hab die also gewechselt. Ich habe mehrere der entsprechenden Anleitungen (SoftwareDistribution neu machen, SFC/CSB neu machen usw) durchgearbeitet und bis vorhin dachte ich, damit wäre das Problem erledigt. So zwei Monate war ja auch alles OK - bis vorhin...
Ich hatte immer wieder mal geguckt und vorhin wunder mich plötzlich über viel Last auf C: und tatsächlich:
wieder hab ich eine riesige CBS.log (5 GB). Ich konnte im Taskmanager beobachten, wie ständig WER Reports erzeugt und gelöscht werden.
Laut HDD Sentinel Pro waren 15 TB gelesen und 30 TB geschrieben (nichts auf C: gemacht, alles nur Microsoft Overhead!). Gut, dass ich das diesmal schnell gemerkt hab! Jetzt hab ich Windows Module Installer Service beendet und die cbs.log gelöscht. Jetzt ist die Transferrate immerhin schon mal auf 20 MB/sec runter gegangen (laut Taskmanager wird die ganze Zeit an C:\$Mft und C:\$LOGFILE rumgeschrieben, warum auch immer). Wenn ich mich nicht verrechnet habe, wäre sonst bei 300-500 MB/sec Schreiblast die SSD wieder in zwei Monaten durch gewesen.
Das ist doch jetzt aber kein Zustand, dass ich zweimal täglich auf dem Server gucken muss, ob da so ne Datei ausrastet. Eigentlich erwarte ich, dass so ein Server einfach nur funktioniert, ohne ständig gestreichelt zu werden.
Was kann ich dagegen tun, dass das nochmal passiert?
(Das Microsoft den Bug löst, werden wir ja nicht mehr erleben - die pushen ja gerade "passwordless", was die Azure Jungs ein bisschen zu wörtlich genommen haben.)
ich habe vor etwa 2 Monaten eine nur etwa 3 Monate alte SSD gegen eine neue getauscht (Samsung OEM Datacenter SSD SM883) in einem Windows Server 2012 R2. Die ist für das System (Laufwerk C
, die Daten sind alle auf einem RAID. Damals hatte ich ein 20 GB CBS.log und der bekannte, uralte Windowsbug "cbs.log größer als 2 GB" schlug zu. Dabei wird die Datei dann immer eine WER kopiert, sobald er fertig ist, fängt er neu an. SSD nach zwei Monaten Dauerschreiben durch, 300 Euro weg, Danke Microsoft. Hab die also gewechselt. Ich habe mehrere der entsprechenden Anleitungen (SoftwareDistribution neu machen, SFC/CSB neu machen usw) durchgearbeitet und bis vorhin dachte ich, damit wäre das Problem erledigt. So zwei Monate war ja auch alles OK - bis vorhin...Ich hatte immer wieder mal geguckt und vorhin wunder mich plötzlich über viel Last auf C: und tatsächlich:
wieder hab ich eine riesige CBS.log (5 GB). Ich konnte im Taskmanager beobachten, wie ständig WER Reports erzeugt und gelöscht werden.
Laut HDD Sentinel Pro waren 15 TB gelesen und 30 TB geschrieben (nichts auf C: gemacht, alles nur Microsoft Overhead!). Gut, dass ich das diesmal schnell gemerkt hab! Jetzt hab ich Windows Module Installer Service beendet und die cbs.log gelöscht. Jetzt ist die Transferrate immerhin schon mal auf 20 MB/sec runter gegangen (laut Taskmanager wird die ganze Zeit an C:\$Mft und C:\$LOGFILE rumgeschrieben, warum auch immer). Wenn ich mich nicht verrechnet habe, wäre sonst bei 300-500 MB/sec Schreiblast die SSD wieder in zwei Monaten durch gewesen.
Das ist doch jetzt aber kein Zustand, dass ich zweimal täglich auf dem Server gucken muss, ob da so ne Datei ausrastet. Eigentlich erwarte ich, dass so ein Server einfach nur funktioniert, ohne ständig gestreichelt zu werden.
Was kann ich dagegen tun, dass das nochmal passiert?
(Das Microsoft den Bug löst, werden wir ja nicht mehr erleben - die pushen ja gerade "passwordless", was die Azure Jungs ein bisschen zu wörtlich genommen haben.)
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 1269513105
Url: https://administrator.de/contentid/1269513105
Printed on: April 18, 2024 at 04:04 o'clock
14 Comments
Latest comment
Moin...
oder gar auf Linux etc.... macOS Server!
Frank
Was kann ich dagegen tun, dass das nochmal passiert?
was hindert dich auf Server 2019 /2022 umzusteigen?oder gar auf Linux etc.... macOS Server!
(Das Microsoft den Bug löst, werden wir ja nicht mehr erleben - die pushen ja gerade "passwordless", was die Azure Jungs ein bisschen zu wörtlich genommen haben.)
nun, du kannst ihn ja lösen, einfach das OS wechseln... und gut Ist!Frank
Hallo,
mach dir doch ein Skript oder eine Batch Datei und lege im Aufgabenplaner alle X Tage/Monate einen Task an der dir
das Skript ausführt. Dann wird reglmäßig gelösche und deine SSD geschont.
Batchdatei siehe 3. Kommentar unter: https://www.borncity.com/blog/2018/10/26/windows-7-cbs-log-bug-mllt-fest ...
Gruß Xolger
mach dir doch ein Skript oder eine Batch Datei und lege im Aufgabenplaner alle X Tage/Monate einen Task an der dir
das Skript ausführt. Dann wird reglmäßig gelösche und deine SSD geschont.
Batchdatei siehe 3. Kommentar unter: https://www.borncity.com/blog/2018/10/26/windows-7-cbs-log-bug-mllt-fest ...
Gruß Xolger
Danke für deine schnelle Antwort.
Ist dann nicht zu befürchten, dass zb Updates schief gehen, weil zufällig gerade der installer Dienst neu gestartet wird? Das Windows Update ist ja so empfindlich...
Aber sonst klingt die Idee schon mal gar nicht schlecht, danke!
Ist dann nicht zu befürchten, dass zb Updates schief gehen, weil zufällig gerade der installer Dienst neu gestartet wird? Das Windows Update ist ja so empfindlich...
Aber sonst klingt die Idee schon mal gar nicht schlecht, danke!
Moin,
häng doch eine normale Platte rein und mounte die in das Verzeichnis hinein, so daß die Ligs auf HDD statt SSD geschrieben werden.
lks
häng doch eine normale Platte rein und mounte die in das Verzeichnis hinein, so daß die Ligs auf HDD statt SSD geschrieben werden.
lks
Moin,
ja das kenne ich leider auch ... Bei einem Kunden haben sich die SSDs im RAID totgeschrieben. Der Controller hatte davon nix mitbekommen. Teile der SSDs waren nicht mehr lesbar, dennoch lief die Kiste wochenlang weiter. Das Backup hatte davon auch nichts mitbekommen und fröhlich Datenmüsli gesichert. Ist dann erst aufgefallen als essentielle Dienste versagt haben. Backup war natürlich unbrauchbar ... Die Daten lagen auf HDDs, aber AD alles andere waren einfach tot. War eine stressige Woche...
Habe das dann bei anderen Kunden überprüft und ähnliches festgestellt. Server 2012 R2 frisst SSDs.
ja das kenne ich leider auch ... Bei einem Kunden haben sich die SSDs im RAID totgeschrieben. Der Controller hatte davon nix mitbekommen. Teile der SSDs waren nicht mehr lesbar, dennoch lief die Kiste wochenlang weiter. Das Backup hatte davon auch nichts mitbekommen und fröhlich Datenmüsli gesichert. Ist dann erst aufgefallen als essentielle Dienste versagt haben. Backup war natürlich unbrauchbar ... Die Daten lagen auf HDDs, aber AD alles andere waren einfach tot. War eine stressige Woche...
Habe das dann bei anderen Kunden überprüft und ähnliches festgestellt. Server 2012 R2 frisst SSDs.
Moin,
kann das hier nicht bestätigen.
Seit ~ 2015 läuft hier ebenfalls ein Server 2012R2 - aber als VM
Drunter ein SAN, mittlerweile voll mit SSDs, vorher ein 2-Tier-SAN mit SSD-Cache und HDDs
IBM hat nur einmal eine von 96 Disks tauschen dürfen, das war aber 'ne HDD und keine SSD
Auf dem Server hier ist die CBS-Log 15MB groß und beinhaltet ~ 85k Zeilen, gelistet seit dem 23.08...
Vielleicht macht es einen Unterschied, ob die Kiste als VM oder auf Blech läuft!?
Gruß
em-pie
kann das hier nicht bestätigen.
Seit ~ 2015 läuft hier ebenfalls ein Server 2012R2 - aber als VM
Drunter ein SAN, mittlerweile voll mit SSDs, vorher ein 2-Tier-SAN mit SSD-Cache und HDDs
IBM hat nur einmal eine von 96 Disks tauschen dürfen, das war aber 'ne HDD und keine SSD
Auf dem Server hier ist die CBS-Log 15MB groß und beinhaltet ~ 85k Zeilen, gelistet seit dem 23.08...
Vielleicht macht es einen Unterschied, ob die Kiste als VM oder auf Blech läuft!?
Gruß
em-pie
Server 2012R2 Hatte das gleiche Problem. SSD war Schrot nach 18 Monaten. Bin auf W19 und jetzt auf W22 umgestiegen.
Moin,
ich habe hier Fujitsu RX300S8 mit LSI SAS 6G (D3116C) und Samsung MZ7KM1T9HAJM-00005 - 1.92TB SM863 unter Server 2012 R2 seit 5 Jahren am laufen. Betriebssytem läuft auf extra SAS RAID. Da ich den Server aber auch nicht ständig neustarte reicht mir dafür auch das SAS RAID. Auf den Samsung Platten sind mehrere Server VM's.
ich habe hier Fujitsu RX300S8 mit LSI SAS 6G (D3116C) und Samsung MZ7KM1T9HAJM-00005 - 1.92TB SM863 unter Server 2012 R2 seit 5 Jahren am laufen. Betriebssytem läuft auf extra SAS RAID. Da ich den Server aber auch nicht ständig neustarte reicht mir dafür auch das SAS RAID. Auf den Samsung Platten sind mehrere Server VM's.
Zitat von @anteNope:
Moin,
ja das kenne ich leider auch ... Bei einem Kunden haben sich die SSDs im RAID totgeschrieben. Der Controller hatte davon nix mitbekommen. Teile der SSDs waren nicht mehr lesbar, dennoch lief die Kiste wochenlang weiter. Das Backup hatte davon auch nichts mitbekommen und fröhlich Datenmüsli gesichert. Ist dann erst aufgefallen als essentielle Dienste versagt haben. Backup war natürlich unbrauchbar ... Die Daten lagen auf HDDs, aber AD alles andere waren einfach tot. War eine stressige Woche...
Habe das dann bei anderen Kunden überprüft und ähnliches festgestellt. Server 2012 R2 frisst SSDs.
Moin,
ja das kenne ich leider auch ... Bei einem Kunden haben sich die SSDs im RAID totgeschrieben. Der Controller hatte davon nix mitbekommen. Teile der SSDs waren nicht mehr lesbar, dennoch lief die Kiste wochenlang weiter. Das Backup hatte davon auch nichts mitbekommen und fröhlich Datenmüsli gesichert. Ist dann erst aufgefallen als essentielle Dienste versagt haben. Backup war natürlich unbrauchbar ... Die Daten lagen auf HDDs, aber AD alles andere waren einfach tot. War eine stressige Woche...
Habe das dann bei anderen Kunden überprüft und ähnliches festgestellt. Server 2012 R2 frisst SSDs.
Ohh mein Gott, ich stelle fest, ich hab ja noch richtig Glück!
Das raid ist ein mit so nem PC Server Controller (LSI/broadcom)? Prüfen die smart Werte nicht richtig?
Oh man, Du hast rückwirkend mein Volkes Beileid!
Zitat von @em-pie:
Moin,
kann das hier nicht bestätigen.
Seit ~ 2015 läuft hier ebenfalls ein Server 2012R2 - aber als VM
Drunter ein SAN, mittlerweile voll mit SSDs, vorher ein 2-Tier-SAN mit SSD-Cache und HDDs
IBM hat nur einmal eine von 96 Disks tauschen dürfen, das war aber 'ne HDD und keine SSD
Auf dem Server hier ist die CBS-Log 15MB groß und beinhaltet ~ 85k Zeilen, gelistet seit dem 23.08...
Vielleicht macht es einen Unterschied, ob die Kiste als VM oder auf Blech läuft!?
Gruß
em-pie
Moin,
kann das hier nicht bestätigen.
Seit ~ 2015 läuft hier ebenfalls ein Server 2012R2 - aber als VM
Drunter ein SAN, mittlerweile voll mit SSDs, vorher ein 2-Tier-SAN mit SSD-Cache und HDDs
IBM hat nur einmal eine von 96 Disks tauschen dürfen, das war aber 'ne HDD und keine SSD
Auf dem Server hier ist die CBS-Log 15MB groß und beinhaltet ~ 85k Zeilen, gelistet seit dem 23.08...
Vielleicht macht es einen Unterschied, ob die Kiste als VM oder auf Blech läuft!?
Gruß
em-pie
Die anderen Server (und Workstations) haben ja kein Problem mit cbs.log. Hab auch welche mit 6 Jahre alter SSD, also "Erstausstattung", die super laufen und keine Probleme machen.
Das blöde ist ja nur, wenn man so Probleme kriegt, ist es manchmal schwer zu reparieren. Leider haben wir manchmal so (alte) Spezialsoftware drauf, die sich nicht so einfach neu installieren lässt.
Zitat von @Lochkartenstanzer:
Moin,
häng doch eine normale Platte rein und mounte die in das Verzeichnis hinein, so daß die Ligs auf HDD statt SSD geschrieben werden.
lks
Moin,
häng doch eine normale Platte rein und mounte die in das Verzeichnis hinein, so daß die Ligs auf HDD statt SSD geschrieben werden.
lks
Sind ja mindestens zwei verzeichnisse (logs und WER), aber ich könnte vielleicht auf die backup HDD linken. Das ist auch ne gute Idee. Danke!
Zitat von @drahtbruecke:
nein... eigentlich frisst Server 2012 R2 keine SSDs.....Zitat von @anteNope:
Moin,
ja das kenne ich leider auch ... Bei einem Kunden haben sich die SSDs im RAID totgeschrieben. Der Controller hatte davon nix mitbekommen. Teile der SSDs waren nicht mehr lesbar, dennoch lief die Kiste wochenlang weiter. Das Backup hatte davon auch nichts mitbekommen und fröhlich Datenmüsli gesichert. Ist dann erst aufgefallen als essentielle Dienste versagt haben. Backup war natürlich unbrauchbar ... Die Daten lagen auf HDDs, aber AD alles andere waren einfach tot. War eine stressige Woche...
Habe das dann bei anderen Kunden überprüft und ähnliches festgestellt. Server 2012 R2 frisst SSDs.
Moin,
ja das kenne ich leider auch ... Bei einem Kunden haben sich die SSDs im RAID totgeschrieben. Der Controller hatte davon nix mitbekommen. Teile der SSDs waren nicht mehr lesbar, dennoch lief die Kiste wochenlang weiter. Das Backup hatte davon auch nichts mitbekommen und fröhlich Datenmüsli gesichert. Ist dann erst aufgefallen als essentielle Dienste versagt haben. Backup war natürlich unbrauchbar ... Die Daten lagen auf HDDs, aber AD alles andere waren einfach tot. War eine stressige Woche...
Habe das dann bei anderen Kunden überprüft und ähnliches festgestellt. Server 2012 R2 frisst SSDs.
Ohh mein Gott, ich stelle fest, ich hab ja noch richtig Glück!
Das raid ist ein mit so nem PC Server Controller (LSI/broadcom)? Prüfen die smart Werte nicht richtig?
gute Frage... möchtest du uns nicht sagen- welcher "PC Server Controller (LSI/broadcom)" den verbaut worden ist!Prüfen die smart Werte nicht richtig?
doch das tun sie, allerdings nur- wenn der richtige Controller verbaut wird, und vor allem die dazu passenden SSDs...wenn ich Server 2012R2 lese, denke ich an einen LSI 9240 oder so... der kann das natürlich nicht!
Oh man, Du hast rückwirkend mein Volkes Beileid!
Frank
Zitat von @drahtbruecke:
Sind ja mindestens zwei verzeichnisse (logs und WER), aber ich könnte vielleicht auf die backup HDD linken. Das ist auch ne gute Idee. Danke!
Sind ja mindestens zwei verzeichnisse (logs und WER), aber ich könnte vielleicht auf die backup HDD linken. Das ist auch ne gute Idee. Danke!
Dann machst Du zwei (oder mehr) Partitionen und hängst die in die jeweiligen Verzeichnisse.
lks
Ich hatte bis vor kurzem noch zwei beim Kunden laufen. Auf dem einen nur Lexware und AD, während der andere nur sekundärer AD war. Bei beiden beobachtete ich eine Schreibleistung von ca. 50 GB pro Tag. Mit dem Process Explorer konnte ich zumindest die Prozesse identifizieren, aber das bringt nicht viel wenn diese svhost.exe und system.exe sind.
Ich hatte diverse Logs deaktiviert und das Schreibvolumen ist tatsächlich zurückgegangen. Ich hatte damals das hier geschildert: Hohe Schreibleistung unbekannter Herkunft
Trotzdem wurden laut SMART 50-100 GB Pro Tag auf die Zellen geschrieben. Verwunderlich war, dass dies erst NACH dem Austausch der SSDs durch größere angefangen hatte. Die alten SSDs hatten über ihre gesamte Arbeitszeit von 4 Jahren gerade mal 300 GB geschrieben.
@drahtbruecke
Du wirst das gleiche Problem haben, was ich hatte. Symptome passen, zuvor SSDs getauscht. Wird mal den Prozess Explorer an und lass den ein paar Tage laufen.
Ich hatte diverse Logs deaktiviert und das Schreibvolumen ist tatsächlich zurückgegangen. Ich hatte damals das hier geschildert: Hohe Schreibleistung unbekannter Herkunft
Trotzdem wurden laut SMART 50-100 GB Pro Tag auf die Zellen geschrieben. Verwunderlich war, dass dies erst NACH dem Austausch der SSDs durch größere angefangen hatte. Die alten SSDs hatten über ihre gesamte Arbeitszeit von 4 Jahren gerade mal 300 GB geschrieben.
nein... eigentlich frisst Server 2012 R2 keine SSDs.....
Also nein, ich widerspreche entscheiden! Irgendetwas kann dazu führen, dass Windows Server 2012 R2 SSDs frisst! Dieses Problem habe ich exklusiv nur mit dieser Server Version beobachtet.@drahtbruecke
Du wirst das gleiche Problem haben, was ich hatte. Symptome passen, zuvor SSDs getauscht. Wird mal den Prozess Explorer an und lass den ein paar Tage laufen.
Was kann ich dagegen tun, dass das nochmal passiert?
Wenn es die gleiche Ursache wie bei mir ist: Logging in vielen Bereichen deaktivierenDas blöde ist ja nur, wenn man so Probleme kriegt, ist es manchmal schwer zu reparieren. Leider haben wir manchmal so (alte) Spezialsoftware drauf, die sich nicht so einfach neu installieren lässt.
Kenne ich zu genüge. Nervt. Aber mit etwas Glück läuft das auch auf etwas aktuellem. Ich habe bei einem Kunden WISO 2002 auf Windows 10 laufen ... einfach mal ausprobieren 😉
