bedeutet nur, dass zum Zeitpunkt des Absturzes in die Logdatei geschrieben wurde, wobei das Journal die entsprechende Größenänderung schon auf die Platte geschrieben hat, die eigentlichen Daten aber noch nicht. Beim Neustart wurde dann das Journal verarbeitet, wodurch sichergestellt wurde, dass die Metadaten der Logdatei korrekt sind, aber die neuen Daten fehlten und die Datei enthält deshalb 0-Bytes.
Leider sagt das nichts über die Ursache des Absturzes aus.
Zur Disgnostik fällt mir auch nicht viel ein. Ist andorfer eine VM? Dann kann ggf. auf der VM-Konsole etwas stehen. Ansonsten kann alles mögliche die Fehlerursache sein, von defekter Hardware bis zu defekten Treibern. (Ich hab z.B. ein ARM-Board mit einer SATA-Platte, wo manchmal das Filesystem abstürzt und der Rest das Systems problemlos weiter funktioniert - solange man nicht auf die Platte zugreift.)
Ich habe Zugriff auf TTYS1 über eine WebConsole, aber da komme ich nach dem Absturz auch nicht mehr dran.
Ich eröffne gerade einen Call beim Provider. Mal hören, was die sagen.
Schade, aber ich habe nun einmal keinen Premium Support Vertrag …
----------------- 8< -----------------
hello,
Unfortunately I can’t help for this return
Did you try to reinstall your server, or to look your log in rescue mode ?
Regards Julien M
----------------- 8< -----------------
Ins Log im Rescue Mode schauen, wird nicht helfen - das Log wurde ja nicht zuende geschrieben. Dass ein Reinstall hilft, ist auch eher unwahrscheinlich.
Eine Neuinstallation wird glaube ich auch nicht helfen. Solche Fehler können schwer zur Analysieren sein, wenn es wirklich die Hardware ist. Freeze ist Freeze.
Man könnte auf der Maschine kdump, crash usw. installieren und sich an das Problem herantasten.
Aber das ist nicht trivial und einfach. Das Lesen von diesen Dumps auch nicht…
Vielleicht reicht es ja auch schon einen Memtest laufen zu lassen über Nacht und mit cpuburn (Warnungen lesen) die CPU quälen?
Müsste ich genauso ergoogeln, wie das unter Debian geht. Die Memtesterei hat den Fehler bei mir damals allerdings auch nicht gefunden. Von daher halte ich auch nur bedingt viel davon.
Mal was anderes, wir sollten erstmal rausfinden, ob es eine Kernelpanik war, oder ob die Hardware einen Schlag hat.
Dazu müsste man mal irgendwie auf die Konsole schauen können, wenn das Ding abschmiert. Bei den Kernelpaniken, die von dem GRE-Offloading verursacht wurden, hat man das immer auf TTY1 gesehen. Könnte es sein, dass die auf der falschen TTY ausgegeben werden oder können wir direkt annehmen, da wir nichts sehen, ist da auch nichts?
Heute mal wieder auf die Trafficstatistik geschaut, nachdem es längere Zeit ruhig war.
Zwischen 12:10 und 13:05 (alles ca.) war null Traffic auf der Leitung.
Ich dachte mir, schau mal mit PuTTY drauf, aber das ging mangels Key nicht.
Hat den jemand runtergeschmissen?
Die Kiste schiebt ~ 100 Mbit/s rein und ~ 100 Mbit/s raus. des1 beispielsweise schiebt gerade ~ 350 Mbit/s rein und ~ 350 Mbit/s raus, die SoftIRQs fressen 60% der CPU Time und die Load geht nur mal kurzfristig über 1. Möglicherweise sollte man im Hypervisor von ausrufer mal die netzwerkkarte auf virtIO umstellen.
80% der CPU Zeit sind Software Interrupts, die hauptsächlich von eth0 veranlasst werden. Ich habe aber collectd testweise dennoch gestoppt: kein Unterschied.
PS: Wie ich gerade sehe, scheint des1 bei 350 Mbit/s duplex saturiert zu sein. …muss ich mir auch mal anschauen.
Meinst du jetzt bei ausrufer oder bei des1? Ich kenne das mit den interrupts leider eher theoretisch und kann nicht mit dem finger drauf zeigen, was es jetzt ist. Aber ich denke, wir sollten bedenken, dass da ja nicht eine tcp connection drüber geht, sondern ein riesiger Berg. des1 hat ~400 l2tp connections und ~4000 Users (nach DHCPv4 leases). Daher können die prozesse ihre zeitscheiben vermutlich nicht so optimal nutzen und das ganze teil wird ineffizient.
Ich schaue mal, was ich da noch rausfinden kann. Für Tipps wäre ich sehr dankbar.
Son typischer Atom hat halt im Vergleich zu was richtigem eher mäßige Performance, zudem fehlen denen im Allgemeinen einige nützliche sonder Funktionen welche die CPU Last senken können (Bsp: Virtualisierung). Außerdem haben die im Allgemeinen weniger Cache, schlechtere Instruction Pipelines oder sogar nur In-Order Instruktion Pipelines, das kann je nach Anwendung ordentlich Performance kosten, gerade wenn die CPU alles macht.
