Ja wir sind gerade dran. Mit dem Support zusammen habenw ir rausgefunden, dass der KErnel wahrscheinlich zu alt ist für den RAM, Jetzt ziehen wir Ubuntu auf 20.04 hoch…
Hallo,
bei Hetzner kann man seinen Server im Rescue booten lassen und so den Zustand besser untersuchen.
VG Andre
1 „Gefällt mir“
Bisher habe ich in der kernel log folgendes drin gehabt:
Jan 18 08:14:17 kernel: [ 6.256557] EDAC amd64: Node 0: DRAM ECC enabled.
Jan 18 08:14:17 kernel: [ 6.256559] EDAC amd64: F17h detected (node 0).
Jan 18 08:14:17 kernel: [ 6.256563] EDAC amd64: Error: F0 not found, device 0x1460 (broken BIOS?)
So wir haben das Betreibssystem mit Kernel auf den aktuellen Stand gebracht. Diemal ohne diesen Fehler gebootet.
an 18 13:36:10 [ 5.016942] EDAC amd64: Node 0: DRAM ECC enabled.
Jan 18 13:36:10 [ 5.016943] EDAC amd64: F17h_M70h detected (node 0).
Jan 18 13:36:10 [ 5.016990] EDAC MC: UMC0 chip selects:
Jan 18 13:36:10 [ 5.016991] EDAC amd64: MC: 0: 16384MB 1: 16384MB
Jan 18 13:36:10 [ 5.016992] EDAC amd64: MC: 2: 16384MB 3: 16384MB
Jan 18 13:36:10 [ 5.016994] EDAC MC: UMC1 chip selects:
Jan 18 13:36:10 [ 5.016995] EDAC amd64: MC: 0: 16384MB 1: 16384MB
Jan 18 13:36:10 [ 5.016995] EDAC amd64: MC: 2: 16384MB 3: 16384MB
Jan 18 13:36:10 [ 5.016996] EDAC amd64: using x16 syndromes.
Jan 18 13:36:10 [ 5.016996] EDAC amd64: MCT channel count: 2
System lief, ich hab Backup Prozess angestoßen (pigz packt da einiges zusammen) und kurz darauf ist der Server wieder offline. Ich bekomme ich auch nicht über das Hetner WEbend neu gestartet, muss jedes mal mit dem Support schreiben…
Hatte ich heute morgen schon, der Support ist echt mega bemüht. Aber trotzdem kacke, Server läuft am Wochenende stabil durch und Sonntag auf Montag nacht verabschidet sich das Ganze…
Also so was hatte ich noch nicht, Kernel ist nun der aktuellste 5.8.0-38 auf einem Ubuntu 20.04. Sobald ich beispielsweise Backup via Ples starte, ist der Server nach ein paar Minuten komplett weg, nicht mehr anpingbar. Logs habe ich soweit gelesen, sehe aber nicht wirklich was außer das DRAM ECC, das aber angeblich mit dem neuen Kernel behoben sien sollte.
Ist wirklichg erade echt bescheiden. Bina m überlegen ob ich nochmal komplett neu aufsetze und eventuell auf Intel zurückwitche.
Hallo,
irgendwie erinnert mich das an das Backup „Mondo“, welches wir in früheren Versionen von linuxmuster.net verwendet haben. Dieses Backup fährt alle Dienste herunter und nach Abschluss wieder hoch.
Vielleicht ist es ja das?
Gruß
Alois
nein, es bricht alles ab. Kein Ping, kein SSH, kein REmoterestart, sogar die KVM heute morgen war tot.
Was ergibt ein Speichertest?
Gruß
Alois
Wie führe ich den am besten durch per ssh?
Hallo,
das wird man möglicherweise vor Ort anstoßen müssen. Bei Linux nennt sich das memtest. Manche Computer bieten das auch vor dem Sysemstart an.
Gruß
Alois
Ich habe jetzt zum zweiten mal das System gewechselt, nur Festplatten wurden mitgenommen. Bin mal gespannt. Sehr unwahrscheinlich dass ich dreimal ein System bekomme mit fhelerhaftem Speichher. Der komplette Hardware Check dauert 10 bis 14h, das is t ne lange Zeit dafür dass ich gerne morgen wieder online sein möchte…
Hallo,
also wenn der Server abschmiert und dann werden die Platten in einen
neuen Server gesteckt und das Problem bleibt … dann sind es die
Platten… so sehe ich das.
Also: neue Platten rein. (ich weiß: man muss komplett neu aufspielen …)
LG
Holger
Hallo,
das klingt nicht gut.
Aber ich vermute, dass der ältere Kernel nicht das Problem sein kann.
Verwendest Du schon das Programm
edac-util ?
Damit habe ich schon zweimal erfolgreich defekte ECC-RAM-Riegel diagnostiziert (ausgetauscht, Server lief wieder zuverlässig. Vorherige Faheler waren nur sporadisch, führten aber auch zum Totalabsturz).
Zweite Idee:
Du mountest per ntfs ein Laufwerk auf einem anderen Server (oder Deinem Rechner) und schreibst sämtliche Logdaten während des backups DARAUF.
Die letzten Meldungen, bevor Dein System abraucht, könnten Aufschluss über die Ursache geben, vielleicht ein Designfehler im Backup-Programm. Vielleicht verlierst Du wegen buffering ein paar Daten, aber ansonsten schreibst Du ja quasi direkt das Log auf die empfangende Serverplatte.
Viele Glück
Christoph
Platten finde ich shcon ungewöhnlich, vor allem im Raid verbung. RAM; CPU; sogar das Mainboard hätte ich in Verdacht, aber Festplatten nicht wirklich. Jetzt schauen wir mal was rauskommt, habe gerade das Backup angestoßen und Server packt mal alles mit pigz zusammen. Bekomme schon nen halben Herzinfakt wenn htop bei ssh für eine Sekunde lagt.
Hallo,
das hätte ich bis vor kurzem auch gesagt. Trotzdem waren es die Festplatten (genau genommen das Raid).
Gruß
Alois
Jetzt warten wir mal ab. Das Backup lokal hat schon mal geklappt, jetzt noch ein Durchlauf mit rausschieben via ftp. Dann gehts auch schneller mit Platten tauschen, falls es wirklich notwendig wird. Und falls dann alles klappt, machen wir die Cloud wieder auf… Ansonsten erstmal Danke an Christoph für den Tipp, das probiere ich gerne aus wenn es zu weiteren Freeze kommen sollte.
Aber das wird noch ne auregende Woche, muss glabu ich jeden Morgen mal gegen 6 schauen ob noch alles läuft. Glücklicherweise läuft unser BBB stabil.
Das klingt alles andere als gut, richtiger Schockmoment wenn der Server einfriert und absolut nicht geht und viele SuS darauf angewiesen sind.
Kernel ist jetzt auf jeden Fall uptoDate, an dem kannes jetzt ja nich mehr liegen.
gerade installiert, mc0: 0 uncorreted; 0 correctecd; no Errors to REport;
Hoffen wir mal dass da so bleibt. Kann das Programm auch dauerhaft überwachen oder wie bist du den RAM Fehlern auf die Schliche gekommen?
So Backup auf em FTP ist auch gemacht, dann aktivieren wir mal wieder die Cloud. Bin mal gepsannt ob es jetzt läuft.
RAID ist kein Garant fuer keine Ausfaelle, wir haben mal direkt auf der Platte Sektoren kaputtgeschrieben, das hat das System ueberhaupt nicht mitbekommen.
Ich hab das oben aber auch nicht alles gelesen, die Platten wuerde ich aber nicht gleich ausschliessen. Im Extremfall sind die die letzten 6 Jahre 24/7 unter Vollast gelaufen.
Hast Du Dir mal mit mdadm den Status der Platte angesehen?
Man sieht uebrigens damit auch, wieso der Hetznerserver die ersten paar Stunden so kreuzlahm ist, er baut erstmal das Array auf.
root@bbb-shit:~# mdadm --detail /dev/md2
/dev/md2:
Version : 1.2
Creation Time : Sun Apr 12 11:20:59 2020
Raid Level : raid1
Array Size : 1936078912 (1846.39 GiB 1982.54 GB)
Used Dev Size : 1936078912 (1846.39 GiB 1982.54 GB)
Raid Devices : 2
Total Devices : 2
Persistence : Superblock is persistent
Intent Bitmap : Internal
Update Time : Mon Jan 18 19:29:50 2021
State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
Name : rescue:2
UUID : 888c95a6:dce2fb27:287a2556:60076020
Events : 50414
Number Major Minor RaidDevice State
0 8 3 0 active sync /dev/sda3
1 8 19 1 active sync /dev/sdb3
Da es 2x 1.92 TB NVMe SSD sind, haben die noch nicht so viel auf dem Buckel. Außerdem glaube ich nicht, dass Hetzner lang gebrauchte SSD’s nutzt, die halten ja nicht ewig…
Naja, aktuell läuft grad alles, bion mal gepsannt wie es morgen früh aussieht wenn der Server unter Last steht. Und heute nacht mal kurz nach dem Backup schauen, ob es auch durchgelaufen ist. Mag nicht nochmal so ein Morgen erleben.
Hallo,
kannst Du uns schreiben wie der Controller heißt an dem die Festplatten hängen?
Gruß
Alois