Ubuntu 17.10/18.04 friert bei hoher Last komplett ein

[A2A]

Hi, ich habe ein wirklich nerviges Problem, welches ich einfach nicht gelöst bekomme:

bei hoher CPU/Ram Last (z.B. beim laden eines 200mb, 4800dpi Jpeg in Gimp oder beim Laden von Cities Skyline) friert mein X240 komplett ein und nur durch langes drücken des Powerknopfes geht das Thinkpad aus. Alle möglichen Tastenkombinationen helfen leider nicht, das Gerät ist quasi Tot, nur der Lüfter läuft fröhlich weiter. Beim Laden von Gimp tritt das Problem meißt erst bei 2. oder 3. Bild auf, bei Cities Skyline jedes mal. Mit Debian hatte ich diese Probleme nicht, die kamen erst mit Ubuntu 17.10 und jetzt aktuell mit 18.04. Leider bin ich auf Ubuntu angewiesen, da unter Debian meine Sierra Wireless nicht funktionieren wollte.
Leider habe ich nicht so viel Ahnung, das ich jetzt einfach fröhlich Kommandos aus dem Internet übernehmen möchte, ohne zu wissen wo das eigentliche Problem liegt. Ich hoffe ihr habt ein paar Tips für mich

Ich habe ein x240 mit 8GB Ram, und eine mit Luks verschlüsselte SSD. Ubuntu wurde per Installer mit allem automatisch installiert. TLP läuft auch.


EDIT: Es hat wohl mit dem RAM zu tun, sobald das Kommando free -h bei Vefügbar gegen 0 geht friert das System ein, ich habe gerade ein paar Bilder geöffnet (die alten immer wieder geschlossen) und "Verfügbar" ging immer weiter gegen 0, trotz schließung der alten Bilder. Das letzte was ich sehen konnte waren 48mb, danach hing das System.

 

[mcb]

Swap Datei / Partition ?

Aber warte mal auf die Profis ich bin bei Linux im Neuland

 

[A2A]

Laut dem Laufwerkstool habe ich eine 8,3GB Große cryptswap, diese ist auch aktiv. Die 8,3GB große "normale" swap ist "nicht aktiv".

 

[fishmac]

Alle möglichen Tastenkombinationen helfen leider nicht, das Gerät ist quasi Tot, nur der Lüfter läuft fröhlich weiter.

Kannst Du Dich zuvor (remote) per ssh einloggen und mal 'top' mitlaufen lassen?

Beim Laden von Gimp tritt das Problem meißt erst bei 2. oder 3. Bild auf, bei Cities Skyline jedes mal. Mit Debian hatte ich diese Probleme nicht, die kamen erst mit Ubuntu 17.10 und jetzt aktuell mit 18.04.

Könnte ein Memory-Leak sein.

Leider bin ich auf Ubuntu angewiesen, da unter Debian meine Sierra Wireless nicht funktionieren wollte.
Leider habe ich nicht so viel Ahnung, das ich jetzt einfach fröhlich Kommandos aus dem Internet übernehmen möchte, ohne zu wissen wo das eigentliche Problem liegt. Ich hoffe ihr habt ein paar Tips für mich

Du könntest mal mit Fedora probieren.

 

[A2A]

Hi, leider bekomme ich ssh nicht zum laufen. Ich kann einfach keine Verbindung (habe OpenSSH installiert und UFW auf SSH allow) herstellen. Neben dem Thinkpad habe ich nur ein iOS Handy und einen RaspberryPi (Ohne Display) zur Verfügung.

Momentan möchte ich nicht schon wieder die Distro wechseln, da das ja auch immer mit etwas ausprobieren/anpassen verbunden ist. Top wär wenn wir Ubuntu zum laufen bekommen, ansonsten bin ich nämlich recht glücklich mit Ubuntu

 

[fishmac]

Hi, leider bekomme ich ssh nicht zum laufen. Ich kann einfach keine Verbindung (habe OpenSSH installiert und UFW auf SSH allow) herstellen. Neben dem Thinkpad habe ich nur ein iOS Handy und einen RaspberryPi (Ohne Display) zur Verfügung.

sshd muss laufen...

Momentan möchte ich nicht schon wieder die Distro wechseln, da das ja auch immer mit etwas ausprobieren/anpassen verbunden ist. Top wär wenn wir Ubuntu zum laufen bekommen, ansonsten bin ich nämlich recht glücklich mit Ubuntu

Schön, dass Du so einfach glücklich zu machen bist

Mit 'ulimit -m' und Start des Programms von der Shell könntest Du versuchen den Verbrauch einiger Ressourcen (-m = max memory size) begrenzen.

 

[A2A]

Ja, hatte den service gestartet. Ich probier ulimit Morgen mal aus, heute habe ich leider keine Zeit mehr.

Vielen Dank für die Hilfe

- - - Beitrag zusammengeführt - - -

Hier sind zwei Screenshots, einer kurz vor und einer nachdem sich der Rechner aufgehängt hat. Zum Test habe ich Cities Skyline genommen, dies friert das System sehr zuverlässig ein inch:

 

[dispanser]

Ich hatte in letzter Zeit ähnliche Probleme, wenn mein Ram zur Neige ging (meistens durch große Java-Prozesse). Obwohl sich der Swap auf einer SSD befand, die ja eigentlich so lahm auch nicht sein sollte, war das System praktisch tot sobald der große, laufende Prozess nicht mehr komplett im RAM liegen konnte, sondern weggeschoben wurde. Wobei ich das nur vermute; kann auch sein das z.B. der Window-Manager in den Swap gezwungen wurde.

Bei mir ging dann immer noch, mit Ctrl-Alt-F1 auf eine Textconsole zu switchen, mich dort einzuloggen, um dann mit 'killall java' alles zu vernichten.
Wobei man teilweise ewig warten musste, bis die Textconsole erschien, die Shell geladen war, usw

Inzwischen habe ich 32GB Ram, vorher habe ich mir damit beholfen, dass ich den Swap deaktiviert habe. Dann sterben halt die Prozesse, die RAM anfordern den es nicht mehr gibt.

Warum der Swap seine Funktion so überhaupt nicht erfüllen kann, verstehe ich immer noch nicht so ganz.

Vielleicht probierst du mal ohne Swap, oder Ctrl-Alt-F1, sobald das Problem auftritt.

 

[A2A]

Hi, Ctrl-Alt-F1 (mit und ohne FN) funktioniert leider nicht. Mit swap deaktiviert stürzt aber nur das Spiel ab! Es liegt also am Übergang vom Ram in den Swap. Wie bekomme ich es jetzt hin Anwendungen mit hohem RAM bedarf zum laufen zu bekommen? Mein x240 schluckt leider nur 8GB :/

 

[fishmac]

Hi, Ctrl-Alt-F1 (mit und ohne FN) funktioniert leider nicht. Mit swap deaktiviert stürzt aber nur das Spiel ab! Es liegt also am Übergang vom Ram in den Swap. Wie bekomme ich es jetzt hin Anwendungen mit hohem RAM bedarf zum laufen zu bekommen? Mein x240 schluckt leider nur 8GB :/

Tja, das Game sollte aber wohl nur 4GB RAM wegnuckeln

Läuft das Game unter Ubuntu nativ oder in Virtualbox o.ä.?

Hier sind zwei Screenshots, einer kurz vor und einer nachdem sich der Rechner aufgehängt hat. Zum Test habe ich Cities Skyline genommen, dies friert das System sehr zuverlässig ein

Welche PID hat das Game und wieso ist vor dem Spiel (0,5GB RAM frei) nach dem Spiel (0,1GB RAM frei)?

 

[joshua666]

bei hoher CPU/Ram Last (z.B. beim laden eines 200mb, 4800dpi Jpeg in Gimp oder beim Laden von Cities Skyline) friert mein X240 komplett ein und nur durch langes drücken des Powerknopfes geht das Thinkpad aus. Alle möglichen Tastenkombinationen helfen leider nicht, das Gerät ist quasi Tot, nur der Lüfter läuft fröhlich weiter.

So ein Problem hatte ich vor 2 Jahren auch mal, ein T500 mit ähnlicher Konfiguration wie bei dir. Es trat immer dann auf wenn der Rechner eine ganze Weile gelaufen war und ich viele Bilder geöffnet habe. Hatte damals gelesen, daß man den Cache über die Kommandozeile löschen kann.

https://tecadmin.net/flush-memory-cache-on-linux-server/

 

[Fusel Wusel]

Um per SSH vorher drauf zu kommen, kann ich Dir für iOS die App Termius empfehlen.

 

[A2A]

So, ich habe jetzt nochmal besser getestet Im Anhang sind drei Screenshots, einmal vor dem Starten des Spiels, einmal beim laden und einmal beim aufhängen. Das Spiel hat die PID 3152.

Das das Spiel mehr als 4GB Ram nutzt ist normal, vor allem mit großen Städten stopft das Spiel den Ram sehr gut voll. Das Spiel läuft nativ, ohne VM (auch nicht intern) auf Linux. Das Spiel ist auch nur ein Beispiel, wenn ich ein Bild in GIMP lade, dies schließe und dann noch ein, zweimal lade hängt das System genauso, da auch hier trotz jeweiligen schließen von GIMP der Ram voll läuft.

Terminus ist super, das nutze ich auch gerade.

 

[Arminius]

Hey A2A,
schau mal mit Htop oder dem taskmanager, ob da ein Dienst namens "tumbler" läuft. Den kannst du im taskmanager per Rechtsklick beenden.

 

[AlexanderS.]

Linux Kernel Debug

Man könnte sich auch mal die Ausgabe des Kernels über die serielle Schnittstelle anschauen. Da mWn das X240 keine echte serielle Schnittstelle mehr hat muss der Kernel mit

CONFIG_USB_SERIAL_CONSOLE=y
CONFIG_USB_SERIAL=y

gebaut worden sein und man muss natürlich über einen USB Seriell Wandler verfügen (bzw. zwei). Weiterhin muss der dazu passende Treiber mit CONFIG_USB_SERIAL_* im Kernel inkludiert sein. Diese Parameter kann man z.B. per

cat /boot/config-$(uname -r) | grep  CONFIG_USB_SERIAL

ermitteln. Um die Ausgabe per serielle Konsole zu aktivieren muss dem Kernel noch die Zeile

console=ttyUSB0,9600n8

mitgegeben werden. Die Zeile nimmt an das die serielle Schnittstelle hinter /dev/ttyUSB0 liegt und der Empfänger mit 9600 Baud 8N1 konfiguriert ist. Die meisten Kernel haben diese USB Seriell Optionen per Modul integriert (z.B. CONFIG_USB_SERIAL=m). Ich denke hier sollte die Ausgabe aber zumindest nach dem Laden des dazugehörigen Moduls erfolgen, habe das aber noch nicht getestet.

Vielleicht verabschiedet sich der Kernel ja noch nett kurz bevor er sich aufhängt.

Ich hatte mal mit irgendeinem älteren Kernel ein Problem mit dem OOM Killer. Dieser ermittelt in einer kritischen Situation mit wenig Speicher die "Badness" eines Prozess und killt jenen mit dem höchsten Score um Speicher freizugeben. Das Problem war dabei das diese Ermittlung nie abgeschlossen wurde, vermutlich weil der Speicher ausging und somit kein Prozess gekillt wurde. Wirklich nachvollziehen konnte ich das Problem damals nicht - aber das verändern der Parameter hat geholfen.

Hier könnte man mal probieren

sysctl vm.overcommit_memory=2
sysctl vm.overcommit_ratio=50

zu setzen. Diese beiden Parameter würden es dem Kernel verbieten Speicher zu überbuchen und somit vielleicht den Fehler einzugrenzen.

 

[A2A]

Hi, einen Prozess Namens tumbler gibt es leider nicht.

Das mit der Serielle-Schnittstelle muss ich ausprobieren, wenn ich mehr Zeit habe, momentan ist es leider etwas eng. Die benötigte Hardware habe ich aber.

 

[fishmac]

Die benötigte Hardware habe ich aber.

Apropos Hardware: Wenn Du irgendwo noch eine zweite SSD oder eine HDD hast, installier mal Fedora, o.ä. und teste ob die Probleme dort auch auftreten (Du weist schon: B-Probe öffnen... )

 

[linrunner]

Schon mal einen RAM-Test (memtest86) laufen lassen?

 

[A2A]

Nein, aber werde ich heute Abend mal machen, danke fuer den Tipp

- - - Beitrag zusammengeführt - - -

Memtest86 lief jetzt mehrere Stunden und hat keinen Fehler gefunden.

sysctl vm.overcommit_memory=2
sysctl vm.overcommit_ratio=50

Sorgt leider dafür das Gimp und Cities Skyline abstürzen, aber immerhin bleibt das System nutzbar.


Ich werde wohl es wohl erst mal dabei belassen und sobald ich das nächste mal Zeit habe auf Arch wechseln.