FreeBSD 8.1 bleibt "hängen"

K

kai_001

Well-Known Member
Hi,

ich habe eine 8.1 PRERELEASE amd64 Installation. An einem 3Ware 9690 Controller hängen 2 Platten im Raid1 und 14 Platten als Single Drives für ZFS. RAM sind 24GB. Kiste rennt wunderbar, alles schick. Nur muss ich ca. alle 2 Wochen einen Hardreset machen, da die Kiste nix mehr macht. Netzwerk tot, lokaler Login per IPMI Karte geht auch nicht ( root eingeben und dann passiert nix mehr ). Wie kann ich rausbekommen was ihm fehlt? Habe keine error Ausgaben. Habt ihr Tipps für mich?

Danke, Kai
 
Hallo,

es gab vor einigen Tagen einen Tread, da ging es um die Ram Belegung durch ZFS, da kannst(solltest) du etwas tunen.

Gruß ré
 
Hi,

jupp ... da gings um die Panics. Habe die Sachen schon angepasst wie empfohlen, der Patch welcher UMA abschaltet ist auch schon drin.

Ich habe ja keine Kernel Panic, dass wundert mich ja so ... er bleibt einfach hängen, anpingbar issa, nur kein Login mehr möglich und alle Dienste tot.

Gruß
Kai
 
Hast du mal beobachtet in welchem Zustand die Prozesse hängen? Also, STATE, RES, MEM usw. über einen längeren Zeitraum?
 
Hi,

ich komme ja nicht mehr rauf. Da is ja dass fiese. Kann per Remote Card noch den User eingeben, aber dass wars dann ....


Kai
 
Meine Erfahrung ist, dass wenn das Dateisystem nicht mehr antwortet alle Prozesse einfrieren sobald sie darauf zugreifen. Es gilt also zu verhindern das der Debugoutput davon betroffen ist. Wie wäre es mit einem kleinen Script z.B. `( (while true; do top -Sores; sleep 5; done) | nc other.box.example.com 1234 ) &`.
Auch wenn nun das Dateisystem nicht mehr reagiert sollte dank Caches diese Schleife weiterhin output senden so habe ich bei mir mal einen defekten SCSI Bus entlarft.
 
Hi,

ich habe mehrere "größere" ZFS Installationen laufen. Eine davon in etwa der selben Größenordnung wie deine. Das von dir beschriebene Problem hatte ich auch, mehrfach, mit und ohne ZFS.

1. Poste mal bitte deinen dmesg output.
2. Wichtig wäre, ob du die mit Alt+F2 etc. noch die Konsolen wechseln kannst.

ich komme ja nicht mehr rauf. Da is ja dass fiese. Kann per Remote Card noch den User eingeben, aber dass wars dann ....
Zum Vergrößern anklicken....

Diese Aussage deutet das an ...

Ich vermute du hast Broadcom NICs. Die haben bei mir wiederholt zum einfrieren mehrerer Systeme geführt.

---

Übrigens: FreeBSD 8.1-RC2 available

http://forums.freebsd.org/showthread.php?t=15606


Gruß
 
Hi,

Konsole wechseln ging glaube ich ( muss ich mal dran denken wenns so weit ist ) :-(

Sind Intel Karten ( igb Treiber ).

Grüße
Kai
 
Hm, schade ...

Also bei mir waren es die onboard broadcom NICs. Nach deren Abschaltung im BIOS und Umstieg auf Intel gab es auf mehreren Rechnern keine Probleme mehr.
 
Im Zweifel bleibt dir nicht anderes als der harte Weg übrig:
- Den Kernel-Debugger DDB in den Kernel backen (hat praktisch keinen Overhead)
- Wenn das Problem auftritt per physischem Zugriff, seriellem Port oder Firewire-Schnittstelle in den Debugger brechen.
- Dort schauen, was ihn blockiert.

Wenn du einen Deadlock vermutest, könntest du den Kernel auch mit WITNESS bauen. Dann würde er den Lock wahrscheinlich erkennen und entsprechende Meldungen auf die Konsole / ins Log werfen. Aber der Overhead ist gigantisch, grob Faktor 4 Verlangsamung des Systems.
 
Hey Yamagi ... werde ich mal machen und hoffe nen Anhalstpunkt zu bekommen.

Meinst Du mit Overhead CPU Last? Oder auch IO vom ZFS Verbund?

Grüße
Kai
 
Alles. WITNESS ist ein Deadlock-Detektor. Simpel gesagt schreibt er einen Graph, der alle gerade gehaltenen Locks im System beinhaltet. Jeder Lock ist ein Knoten, die Beziehungen untereinander werden durch die Kanten symbolisiert. Wenn es in dem Graphen einen Zyklus (für die Nichtinformatiker: Eine Möglichkeit im Kreis zu laufen) gibt, ist das ein potentieller Deadlock. Damit das funktioniert, muss jedes Mal wenn ein Lock angefordert oder wieder freigegeben wird, dieser Lock in Form eines neuen Knoten in den Graphen eingefügt werden und man muss prüfen, ob der Graph noch zyklenfrei ist. Das ist aber, wie man sich denken kann, extrem teuer. Pro Sekunde werden im Kernel - durch den inneren Kern selbst, durch das VM, das VFS, GEOM, den Netzwerkstack, UFS, ZFS, Treiber und vielem mehr zehntausende Locks angefordert und wieder freigegeben. Statt wenigen CPU-Zyklen dauert es mit Witness jedes mal sehr lange und schluckt CPU-Last ohne Ende. Oder anders gesagt: Baust du einen Kernel mit Witness, sinkt deine verfügbare CPU-Leistung deutlich. Egal was das System genau macht. Daher steht in -CURRENT in /usr/src/UPDATING auch der Hinweis "If you think that FreeBSD 9 ist slow...", da dort WITNESS immer eingeschaltet ist.

Noch drei Hinweise zu Witness:
- Witness erkennt fast alle Deadlock, aber es gibt einige Randfälle, die er nicht greifen kann. Erkennt er nichts, kannst du nur 99% sicher sein, dass du keinen Deadlock hast. Nicht zu 100%.
- Ein erkannter Deadlock bedeutet nicht "hier wäre das System verklemmt". Es bedeutet nur, dass eine Verklemmung möglich wäre, d.h. die Voraussetzungen gegeben sind. Eintreten muss sie noch lange nicht, was das Erkennen und Beseitigen von Verklemmungen ohne Mechanismus zur Erkennung sehr schwer macht.
- Witness hat eine gewisse Neigung zu Falscherkennungen. Es gibt im Kernel einige Stellen, an denen Witness einen Deadlock erkennt, der aber niemals eintreten kann. Eine der bekanntesten dieser Stellen ist eine Falscherkennung in UFS, die du fast sicher sehen wirst, falls du es nutzt.

Wenn Witness einen Deadlock findet, schreibt er dir "lock order reversal" auf die Standardkonsole und damit auch in /var/log/messages. "lock order reversal" oder kurz LOR ist nichts anderes als ein Deadlock. Darauf folgt eine Ausgabe der Locks, die gerade gehalten wurden, also was mit wem verklemmt. Wenn Debugsymbole vorhanden sind (also ein kernel.debug gestartet wurde), gibt er auch die genauen Zeilen aus, wo die Locks angefordert wurden. Diese Informationen solltest du mit der FreeBSD LOR Page abgleichen: http://sources.zabbadoz.net/freebsd/lor.html Das kann helfen zu entscheiden, ob das Problem bekannt ist. Dann kannst du entscheiden, was du weiter machen willst. Bei den dort aufgeführten LOR gibt es in der Detailansicht auch einen Knopf weitere Informationen beizusteuern.

Ach ja: Bei den wirklich kritischen Deadlocks springt FreeBSD dann in die Panic um zu verhindern, dass das System verklemmt und du nichts mehr machen kannst. Wenn du nicht am Debugger-Prompt landen willst (sofern der Debugger aktiv ist), konfiguriere am Besten Kerneldumps. Dann schmiert er ab, dumpt, startet neu und du hast den Dump zur weiteren Analyse. Löst auch das Problem, dass du einen manuellen Reset machen musst.

Das Ding auch ne Manpage: witness(4)
 
Aber er hat 24GB RAM und braucht damit auch zumindest eine 24GB Swap Partition für Dumps.

Mir ist es jedenfalls nicht gelungen mein System mit 8GB RAM auf einer 4GB Swap zu dumpen. Obwohl der Platz für einen Minidump ja reichen müsste.
 
Ok,

habe jetzt mal options KDB und DDB reingenohmmen. Mit sysctl debug.kdb.panic=1 komme ich den debug Modus ( für trace u.s.w. ). Nur klappt dass auch wenn die Kiste später wieder hängen sollte? Oder geschieht das dann automatisch. Dazu steht im Handbuch leider nichts, oder ich habs übersehen.

PS: da war ich zu schnell .... Ctrl+Alt+ESC sollte es sein, ok, dann melde ich mich wenns so weit ist
 
Ok,

hatte grade wieder diesen Fall ... und ich bin nicht in den Debugger Mode gekommen. Läuft der Server normal, komme ich dort rein. :confused:


Jemand ne Idee?

Ich würde jetzt mal anfangen Hardware zu tauschen ....


Kai
 
Ok, da war ich zu schnell ... falsches Keyboard Layout im Terminal gewählt ... also wieder warten :-(
 
So,

hat geklappt ... die letzten trace Meldungen haben mich auf igb Probleme gebracht. Hab dazu auch was in den Mailinglisten gefunden,

Momentan hab ich Treiberversion: Intel(R) PRO/1000 Network Connection version - 1.9.6

Komischerweise ist da ein Patch zum Teil wieder rausgeflogen. Werde dass mal ändern und beobachten.

Grüße
Kai
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben