Xorg.bin: hohe CPU-Last und RAM läuft voll -- warum?

Hinweis: In dem Thema Xorg.bin: hohe CPU-Last und RAM läuft voll -- warum? gibt es 13 Antworten auf 2 Seiten. Der letzte Beitrag () befindet sich auf der letzten Seite.

    Moinsen!


    Ein Rätsel, jedenfalls für mich. Der RAM läuft voll, dann der Swap, dann wird irgendwann der Aufbau von Fenstern seeeehr zäh, und kurz danach ist im Desktop nur noch der Cursor zu bewegen. Aller RAM voll, denke ich. Ich muss dann eine andere Sitzung als root öffnen um gerade noch einen geregelten Neuststart zu bewirken.


    Das System:

    Operating System: openSUSE Tumbleweed 20231206

    KDE Plasma Version: 5.27.9

    KDE Frameworks Version: 5.112.0

    Qt Version: 5.15.11

    Kernel Version: 6.6.3-1-default (64-bit)

    Graphics Platform: X11

    Processors: 8 × 11th Gen Intel® Core™ i7-1165G7 @ 2.80GHz

    Memory: 31,1 GiB of RAM

    Graphics Processor: Mesa Intel® Xe Graphics

    Manufacturer: Framework

    Product Name: Laptop

    System Version: AB



    opensuse-forum.de/wcf/attachment/16547/


    ( ^^^ hat andere PIDs als vvv weil anderer Boot)



    ^^^ Ist es normal das Xorg so viele Unterprozesse hat?


    Back In Time ist ein bischen überaktiv dafür, dass keine seiner Backup-Platten angeschlossen ist. Es schreibt auch nicht in die Mount-Verzeichnisse ("0 B"). Beim Speicherverbrauch scheint es mir aber nicht ausreichend als Erklärung. Apps und Prozesse:


    opensuse-forum.de/wcf/attachment/16548/


    bzw.

    Wo fange ich an bei der Fehlersuche? :/

    Für den Inhalt des Beitrages 309944 haftet ausdrücklich der jeweilige Autor: rollon

    Zitat von Sauerland

    Hast du es mal mit einem älteren Kernel versucht?

    Gute Idee! Habe jetzt 6.6.3., 6.6.2 und 6.6.1 probiert, leider ohne Erfolg.


    Das Problem trat erst kürzlich auf. Eine lange Liste von Updates vor ~4 Tagen, zu lang, um einzeln downzugraden. Wären da Versuche mit 5.x noch sinnvoll, wenn doch 6.x bis dahin gut funktioniert hat?


    Ein Rollback würde mich wohl beim nächsten Updaten wieder in die jetzige Situation bringen. Man könnte die Updates einzeln oder in kleinen Gruppen vornehmen, aber das sieht nach viel Arbeit aus. :(


    Es müsste doch möglich sein, herauszufinden, wer mir den Speicher flutet und welcher Umstand Xorg ständig hochdrehen lässt...

    Für den Inhalt des Beitrages 309949 haftet ausdrücklich der jeweilige Autor: rollon

    Wenn du jetzt STRG+ESC drückst, siehst du in der Liste Prozesse, die mehrfach vorhanden sind?

    Zitat von Alero

    Wenn du jetzt STRG+ESC drückst, siehst du in der Liste Prozesse, die mehrfach vorhanden sind?

    Ja, die von Back in Time, obwohl seine Backup-Platten nicht angeschlossen sind. (Alles vvv mit Kernel 6.6.1-1.)

    Code
    localhost:~ #  ps -e | cut -d ' ' -f2- | uniq -cd | sort -r
4 pts/5    00:00:00 top
2 pts/5    00:00:00 top
2 ?        00:03:41 python3
2 ?        00:01:38 python3
2 ?        00:00:30 python3
2 ?        00:00:00 Web Content
localhost:~ #

    Sie sind schon leicht auffällig, aber sie belegen zusammen nur 77% CPU und 29% Speicher. Ich wollte mich denen erst zuwenden wenn ich nicht jede Stunde neu booten muss.


    top, sortiert nach CPU:

    Tja, das wird dann wohl ein Rollback.




    P.S. Wegen der HowTo-Links: Habe ich was grob falsch gemacht ohne es zu merken?

    Für den Inhalt des Beitrages 309954 haftet ausdrücklich der jeweilige Autor: rollon

    Der Prozess backintime müsste sich doch killen lassen. Und ansonsten: Backintime eventuell testweise deinstallieren, um überhaupt einzugrenzen, ob es daran iiegt?

    Für den Inhalt des Beitrages 309955 haftet ausdrücklich der jeweilige Autor: matbhm

    Zitat von matbhm

    Der Prozess backintime müsste sich doch killen lassen. Und ansonsten: Backintime eventuell testweise deinstallieren, um überhaupt einzugrenzen, ob es daran iiegt?

    Das war's tatsächlich. Habe ich voll daneben gelegen mit der Annahme, das wären unabhängige Probleme.


    Danke an alle für's Mitdenken und für die hilfreichen Tips!

    Für den Inhalt des Beitrages 309963 haftet ausdrücklich der jeweilige Autor: rollon

    Falls erledigt, bitte noch so markieren. Siehe meine Signatur.

    Zitat von Sauerland

    Startest du immer mit der "letzten Sitzung"?


    Was meinst Du damit? Dass ich Backintime sofort als Ursache hätte einschätzen müssen? Mein Fehler, OK.


    Die Schlüssel sind doch immer in der letzten Schublade die man durchsucht. :)

    Für den Inhalt des Beitrages 309967 haftet ausdrücklich der jeweilige Autor: rollon