System hängt nach spulen mit mplayer

[king-crash]

Hallo,

ich habe hier ein etwas kurioses Problem nachdem ich vor einiger Zeit von 3.2 zuerst auf 3.9 jetzt auf 3.10 geupdatet habe,
wird das System nach einigem Spulen im mplayer unerreichbar. Es ist hier allerdings ein fließender Übergang, d.h. wenn
ich noch rechtzeitig aufhöre und mplayer schließen kann passt alles wieder. Das komische an der Sache ist, dass sobald
dieses Problem auftritt sich unaufhörlich der Festplattenkopf der Systemplatte bewegt. In iotop haben dann die einfachsten
Prozesse auf einmal 99%IO, an Bytes/s kommt allerdings nicht allzu viel rüber. Maus und Tastatureingaben werden mit
delays bis über einer minute verarbeitet. Das Video allerdings ist mit cifs gemountet uns somit nicht auf dieser Platte. Mit
Kernel 3.2 gab es dieses Problem nicht, das habe ich auch nochmals getestet.

Kernel: 3.10.5
CPU: I5-2500k
Grafik: CPU

[uname]

Tritt der Fehler auch auf wenn du dieselbe Datei lokal auf der Platte hast? Dann könnte man das Netzwerk bzw. cifs erst mal als Fehlerursache ausschließen. Wäre somit evtl. etwas einfacher zu lösen.

[cosmac]

Das komische an der Sache ist, dass sobald dieses Problem auftritt sich unaufhörlich der Festplattenkopf der Systemplatte bewegt. In iotop haben dann die einfachsten Prozesse auf einmal 99%IO, an Bytes/s kommt allerdings nicht allzu viel rüber. Maus und Tastatureingaben werden mit delays bis über einer minute verarbeitet.

aber sie werden irgendwann verarbeitet, man muss nur viiiel Geduld haben Genau dieses Verhalten habe ich hier, wenn iceweasel viele große Bilder anzeigen soll. Mir geht dann der Arbeitsspeicher aus und das System fängt vermutlich an, Programmspeicher frei zu geben. Das führt dann zu extrem viel swap-I/O, aber überwiegend auf die Programmdateien. Da die im Gegensatz zur swap-Partition über die ganze Platte verteilt sind, wartet man praktisch nur noch auf die Platte. Aber das ist nur meine Theorie.

[king-crash]

Swap habe ich keinen, aber ich werde das mit dem lokal abspielen demnächst ausprobieren.

[king-crash]

Also das Problem zeigt sich auch bei Filmen auf lokalen Datenträgern.
Was ich nicht verstehe ist, was genau auf der Systemplatte gemacht wird. Sobald das System stockt läuft der Plattenkopf amok...

[Cae]

Poste mal

Code: Alles auswählen

$ free -m

-- einmal, wenn's normal ist und ein zweites Mal, wenn die Platte schreddert. Auesserdem liefert

Code: Alles auswählen

$ dmesg | tail -n 15

moeglicherweise relevante Informationen.

Gruss Cae

[king-crash]

Bingo,
der mplayer müllt den ganzen RAM zu. Aber sollte das das System nicht abkönnen?

[king-crash]

Gerade hab ich das nochmal mit meinem alten Kernel probiert. Hier wir dem mplayer vor erreichen eines kritischen Speicherstandes kein Speicher mehr vergeben. (allocate failed)
Wo kann ich denn die Limits in den Kernel mit einkompilieren?

[cosmac]

Was ich nicht verstehe ist, was genau auf der Systemplatte gemacht wird.

http://landley.net/writing/memory-faq.txt

[king-crash]

Interpretiere ich den Artikel richtig wenn ich davon ausgehe, dass aufgrund fehlender Ressourcen der Cache für u.A. die HDD fehlt und der Kernel deshalb für jede noch so kleine Anfrage den Plattenkompf bemüht um in jedem Fall nicht buffern zu müssen? Konkret wirft der Kernel vermutlich die Executables aus dem RAM und muss sie, wenn der Prozess wieder Rechenzeit bekommt von der Platte laden?

Die Lösung des Problems wäre eine Limitierung des vom Userspace benutzbaren Speichers oder?

[cosmac]

ja, so ungefähr verstehe ich den Artikel auch. Und theoretisch kann man mit ulimit auch den Speicher limitieren, probier' mal die verschiedenen Einstellungen durch. Ich war zwar vom Ergebnis nicht begeistert, aber evt. hilft es dir.

Interessant wäre ja, was sich im Kernel geändert hat, aber dazu finde ich überhaupt nichts

[king-crash]

Evtl ist die alte Version auch ein fertiger Debian Kernel. Wobei ich für meine eigenen builds immer die Standard config nehme und nur Dinge wie Processor-Type u.Ä. anpasse.