Problemdiagnostik Ausrufer


#1

Die Zeile mit

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.)


Admintagebuch - Dokumentation der Admintätigkeiten
#2

Der Ausrufer ist Bare Metal


#3

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.


#4

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< -----------------


#5

Ins Log im Rescue Mode schauen, wird nicht helfen - das Log wurde ja nicht zuende geschrieben. Dass ein Reinstall hilft, ist auch eher unwahrscheinlich. :frowning:


#6

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?


#7

memTest und CPUburn hört sich gut an. @MPW kannst Du das lostreten?


#8

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?


#9

Kann man die Maschine nicht mit einem beliebigen ISO booten? ISO von memtest einfach booten.

Download:
http://www.memtest.org/#downiso


#10

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?

Gruß, Holger


#11

Unser Ansible löscht alle Schlüssel, die nicht eingetragen sind. Bitte schicke mir deinen, dann hinterlege ich den korrekt und permanent.


#12

Was für Hardware ist auf Ausrufer eigentlich verbaut / welche Ressourcen sind dem zugeteilt? Die Load ist gerne mal bei 5-6 und 80% der CPU-Zeit werden von SoftIRQs gefressen: https://freifunk-muensterland.de/grafana/dashboard/db/multidomanen-gateways-details?var-host=ausrufer (gaaanz unten).
Die meisten Interrupts (quasi alle) sind eth0-rx-0 und eth0-tx-0 zuzuordnen.

Womit wird virtualisiert?

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.


#13

Das ist ein Atom, nicht virtualisiert.

Collectd zieht zu viel CPU.


#14

Das ist quatsch. S. o.

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.


#15

Ich habe da vorhin iperfs drüber gejagt, da ging noch deutlich mehr drüber. Mir ist nicht klar, was da genau die Last verursacht.


#16

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.


#17

Vom Remü-Blech zu Ausrufer durch den FFRL-Tunnel.


#18

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.


#19

Es wäre noch mal ne Idee, zu schauen was die Netzwerkkarte für Offloading-Features bietet.