Discussion:
sid Plasma 5.8.7 - plasmashell frisst Speicher
(zu alt für eine Antwort)
Helge Reimer
2017-08-28 19:40:01 UTC
Permalink
Hallo,

wie der Betreff schon sagt läuft bei mir sid mit Plasma 5,8,7.
Seit einem kürzlichem dist-upgrade frisst mir der Prozess 'plasmashell' den
gesamten Speicher weg.
Man kann dabei zusehen, wie der Speicherbedarf von Anfangs 148MB auf viele GB
ansteigt. Irgendwann ist es soweit und das System ist aufgrund des
Speichermangels nicht mehr zu bedienen.
Bei einem anderen Benutzer auf dem selben Rechner ist das nicht der Fall.

Ich vermute, es liegt an irgendeinem 'Miniprogramm' für Plasma. Hat einer von
euch eine Idee, wie ich dem auf die Spur komme?
Oder sollte ich gleich den harten Weg einschlagen und die Plasmakonfiguration
umbennen/löschen und Plasma neu einrichten?

Wäre schon nervig. Hab ja lange genug an der config rumgefummelt.
Bin für jeden Tip dankbar.

Gruß
Helge
Elimar Riesebieter
2017-08-28 20:20:02 UTC
Permalink
Post by Helge Reimer
Hallo,
wie der Betreff schon sagt läuft bei mir sid mit Plasma 5,8,7.
Seit einem kürzlichem dist-upgrade frisst mir der Prozess 'plasmashell' den
gesamten Speicher weg.
Man kann dabei zusehen, wie der Speicherbedarf von Anfangs 148MB auf viele GB
ansteigt. Irgendwann ist es soweit und das System ist aufgrund des
Speichermangels nicht mehr zu bedienen.
Bei einem anderen Benutzer auf dem selben Rechner ist das nicht der Fall.
Ich vermute, es liegt an irgendeinem 'Miniprogramm' für Plasma. Hat einer von
euch eine Idee, wie ich dem auf die Spur komme?
# apt install htop
$ htop
-> <F6> M_SIZE

Elimar
--
Post by Helge Reimer
what IMHO then?
IMHO - Inhalation of a Multi-leafed Herbal Opiate ;)
--posting from alex in debian-user--
Martin Steigerwald
2017-08-28 20:40:02 UTC
Permalink
Hallo.
[…]
Post by Elimar Riesebieter
Post by Helge Reimer
Ich vermute, es liegt an irgendeinem 'Miniprogramm' für Plasma. Hat
einer
von euch eine Idee, wie ich dem auf die Spur komme?
# apt install htop
$ htop
-> <F6> M_SIZE
Das geht einfacher und genauer mit Strg-Esc: Und ja, der Prozess-Monitor von
Plasma berechnet da die noch genauere Proportional Set Size (PSS). Das
konnte der schon, bevor mir dafür ein Konsolen-Werkzeug bekannt war.
Ursachen- Forschung mit Kontextmenü "Detaillierte Informationen". Ggf. auf
"more" klicken. Genauer geben das auch Befehlszeilen-Werkzeuge nicht aus.
Ansonsten gibt es die PSS auch in Atop, Taste [m] für Speicher-Ansicht,
Taste [R], sowie schön übersichtlich via smemstat, das schneller arbeitet
als das Python-Skript smem. Einzelspeicherbereiche wie pmap -x auf die
entsprechende PID, Spalte RSS. Aber der Prozess-Monitor von Plasma zeigt
das auch an. Und ist damit das genaueste Programm zur Auswertung des
Speicherverbrauches eines Prozesses, das ich je in einer Desktop-Umgebung
gesehen habe. Natürlich ist auch wichtig, die anzeigten Werte zu verstehen.
Aber es liefert ja sogar noch eine Erklärung mit, die hier allerdings in
englisch ist. Aber da hat sich ein Entwickler mal echt so richtig
ausgetobt. :)
Hier mal so ein Beispiel:

Process 3323 - kmail

Summary

The process kmail (with pid 3323) is using approximately 624.0 MB of memory.
It is using 608.8 MB privately, and a further 97.4 MB that is, or could be,
shared with other programs.

Dividing up the shared memory between all the processes sharing that memory we
get a reduced shared memory usage of 15.2 MB. Adding that to the private
usage, we get the above mentioned total memory footprint of 624.0 MB.
Library Usage

The memory usage of a process is found by adding up the memory usage of each
of its libraries, plus the process's own heap, stack and any other mappings,
plus the stack of its 22 threads.

Private
more
610672 KB [heap]
1956 KB /usr/lib/x86_64-linux-gnu/libQt5WebKit.so.5.9.1
1892 KB /var/lib/aspell/de-common.rws
392 KB /usr/lib/x86_64-linux-gnu/libkmailprivate.so.5.2.3
304 KB /usr/share/fonts/opentype/freefont/FreeSans.otf

Shared
more
17484 KB /SYSV00000000 (deleted)
8740 KB /usr/lib/x86_64-linux-gnu/libQt5WebKit.so.5.9.1
4568 KB /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5.9.1
4448 KB /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5.9.1
4304 KB /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.9.1
Totals

Private 623396 KB (= 4704 KB clean + 618692 KB dirty)
Shared 99784 KB (= 82300 KB clean + 17484 KB dirty)
Rss 723180 KB (= Private + Shared)
Pss 638929 KB (= Private + Shared/Number of Processes)
Swap 0 KB


Full Details

Information about the complete virtual space for the process is available,
with sortable columns. An empty filename means that it is an anonymous mapping.
Both the MMU page size and the kernel page size are 4 KB.

[die lasse ich mal weg]

Danke,
--
Martin
Martin Steigerwald
2017-08-28 21:00:01 UTC
Permalink
Post by Martin Steigerwald
Hallo.
[…]
Post by Elimar Riesebieter
Post by Helge Reimer
Ich vermute, es liegt an irgendeinem 'Miniprogramm' für Plasma. Hat einer
von euch eine Idee, wie ich dem auf die Spur komme?
# apt install htop
$ htop
-> <F6> M_SIZE
Das geht einfacher und genauer mit Strg-Esc: Und ja, der Prozess-Monitor
von Plasma berechnet da die noch genauere Proportional Set Size (PSS).
Das konnte der schon, bevor mir dafür ein Konsolen-Werkzeug bekannt war.
Ursachen- Forschung mit Kontextmenü "Detaillierte Informationen". Ggf.
auf "more" klicken. Genauer geben das auch Befehlszeilen-Werkzeuge nicht
aus.
Ansonsten gibt es die PSS auch in Atop, Taste [m] für Speicher-Ansicht,
Taste [R], sowie schön übersichtlich via smemstat, das schneller arbeitet
als das Python-Skript smem. Einzelspeicherbereiche wie pmap -x auf die
entsprechende PID, Spalte RSS. Aber der Prozess-Monitor von Plasma zeigt
das auch an. Und ist damit das genaueste Programm zur Auswertung des
Speicherverbrauches eines Prozesses, das ich je in einer Desktop-Umgebung
gesehen habe. Natürlich ist auch wichtig, die anzeigten Werte zu verstehen.
Aber es liefert ja sogar noch eine Erklärung mit, die hier allerdings in
englisch ist. Aber da hat sich ein Entwickler mal echt so richtig
ausgetobt. :)
Process 3323 - kmail
Summary
The process kmail (with pid 3323) is using approximately 624.0 MB of memory.
It is using 608.8 MB privately, and a further 97.4 MB that is, or could be,
shared with other programs.
Noch eins oben drauf:

- KMail virtueller Adreßraum (VSZ): 4.2G
- KMail physikalischer belegter Speicher (RSS): 706.2M
- KMail PSS: 624.8M (was eben der Plasma-Prozess-Monitor oben auch sagt)

So *weit* und noch weiter können die Angaben voneinander abweichen.

Würde KMail wirklich 4,2 GiB physikalisch belegen, wäre das schon ein Viertel
des in diesem ThinkPad T520 verbauten Speichers, was bei gerade mal insgesamt
ca. 6754 MiB belegten Speicher neben Amarok, mysqld mit 1 GiB InnoDB Buffer
Pool, Akregator, Konsole und was weiß ich noch schon eine Ansage wäre:

***@merkaba:~> free -m
total used free shared buff/cache available
Mem: 15830 6754 176 993 8899 7758
Swap: 12287 0 12287

Da KMail aber eben, je nach Sichtweise, nur ca. 706 MiB bzw. ca. 624 MiB
Speicher physikalisch belegt, sieht das durchaus anders aus.

Ciao,
--
Martin
Martin Steigerwald
2017-08-28 21:10:03 UTC
Permalink
Post by Martin Steigerwald
Würde KMail wirklich 4,2 GiB physikalisch belegen, wäre das schon ein
Viertel des in diesem ThinkPad T520 verbauten Speichers, was bei gerade
mal insgesamt ca. 6754 MiB belegten Speicher neben Amarok, mysqld mit 1 GiB
InnoDB Buffer Pool, Akregator, Konsole und was weiß ich noch schon eine
total used free shared buff/cache available
Mem: 15830 6754 176 993 8899 7758
Swap: 12287 0 12287
Achja, die zweite, ebenfalls noch laufende Desktop-Sitzung mit KMail und was
weiß ich alles noch, hatte ich da noch vergessen.

Kurzum: Die addierte virtuelle Größe aller Prozesse würde definitiv nicht in
die 16 GiB physikalischen Speicher in diesem Laptop passen.

Ciao,
--
Martin
Martin Steigerwald
2017-08-28 20:40:02 UTC
Permalink
Hallo.
Post by Elimar Riesebieter
Post by Helge Reimer
wie der Betreff schon sagt läuft bei mir sid mit Plasma 5,8,7.
Seit einem kürzlichem dist-upgrade frisst mir der Prozess 'plasmashell' den
gesamten Speicher weg.
Man kann dabei zusehen, wie der Speicherbedarf von Anfangs 148MB auf viele
Speicherbedarf ist natürlich viel zu unspezifisch. VIRT SIZE, VSZ und so weiter
sind mal in der Regel ganz weit weg vom tatsächlichen physikalischen
Speicherbedarf.
Post by Elimar Riesebieter
Post by Helge Reimer
GB ansteigt. Irgendwann ist es soweit und das System ist aufgrund des
Speichermangels nicht mehr zu bedienen.
Bei einem anderen Benutzer auf dem selben Rechner ist das nicht der Fall.
Ich vermute, es liegt an irgendeinem 'Miniprogramm' für Plasma. Hat einer
von euch eine Idee, wie ich dem auf die Spur komme?
# apt install htop
$ htop
-> <F6> M_SIZE
Das geht einfacher und genauer mit Strg-Esc: Und ja, der Prozess-Monitor von
Plasma berechnet da die noch genauere Proportional Set Size (PSS). Das konnte
der schon, bevor mir dafür ein Konsolen-Werkzeug bekannt war. Ursachen-
Forschung mit Kontextmenü "Detaillierte Informationen". Ggf. auf "more"
klicken. Genauer geben das auch Befehlszeilen-Werkzeuge nicht aus.

Ansonsten gibt es die PSS auch in Atop, Taste [m] für Speicher-Ansicht, Taste
[R], sowie schön übersichtlich via smemstat, das schneller arbeitet als das
Python-Skript smem. Einzelspeicherbereiche wie pmap -x auf die entsprechende
PID, Spalte RSS. Aber der Prozess-Monitor von Plasma zeigt das auch an. Und
ist damit das genaueste Programm zur Auswertung des Speicherverbrauches eines
Prozesses, das ich je in einer Desktop-Umgebung gesehen habe. Natürlich ist
auch wichtig, die anzeigten Werte zu verstehen. Aber es liefert ja sogar noch
eine Erklärung mit, die hier allerdings in englisch ist. Aber da hat sich ein
Entwickler mal echt so richtig ausgetobt. :)

Die PSS ist die Unique Set Size, also der physikalische Speichern, den der
Prozess für sich selbst braucht, plus der gemeinsam mit anderen Prozessen
genutzte Speicher jeweils geteilt durch die Anzahl der Prozesse, mit denen der
Prozess sich jeden gemeinsam genutzten Speicherbereich teilt.

So oder so zeigt top auch die RSS an, alleine dafür ist es also nicht
erforderlich htop zu installieren.

Danke,
--
Martin
Helge Reimer
2017-08-28 21:10:03 UTC
Permalink
Das geht einfacher und genauer mit Strg-Esc: Und ja, der Prozess-Monitor von
Plasma berechnet da die noch genauere Proportional Set Size (PSS). Das
konnte der schon, bevor mir dafür ein Konsolen-Werkzeug bekannt war.
Ursachen- Forschung mit Kontextmenü "Detaillierte Informationen". Ggf. auf
"more" klicken. Genauer geben das auch Befehlszeilen-Werkzeuge nicht aus.
Das ist KSysGuard. Kenne ich natürlch. daher weiß ich ja, dass 'plasmashell'
mir Probleme macht.
Man kann sich 'detailierte Speicherinformationen' für die einzelnen Prozesse
anzeigen lassen.
Das fuktioniert bei mir auch. Wenn ich mir das für 'plasmashell' anzeigen
lassen möchte, dann verabschiedet sich KSysGuard mit
'Speicherzugriffsfehler'.

Den Rest von deinem Text verstehe ich noch nicht, sorry.
Martin Steigerwald
2017-08-28 21:20:01 UTC
Permalink
Post by Helge Reimer
Das geht einfacher und genauer mit Strg-Esc: Und ja, der Prozess-Monitor
von Plasma berechnet da die noch genauere Proportional Set Size (PSS).
Das konnte der schon, bevor mir dafür ein Konsolen-Werkzeug bekannt war.
Ursachen- Forschung mit Kontextmenü "Detaillierte Informationen". Ggf.
auf "more" klicken. Genauer geben das auch Befehlszeilen-Werkzeuge nicht
aus.
Das ist KSysGuard. Kenne ich natürlch. daher weiß ich ja, dass
'plasmashell' mir Probleme macht.
Die virtuelle Größe kommt aber nicht aus KSysGuard. Zumindest nicht aus der
Haupt-Ansicht. Die zeigt das Werkzeug nämlich da gar nicht an. Was ich
durchaus sinnvoll finde, da virtuelle Größe mit der Load Average eine Metrik
ist, die Menschen am häufigsten nicht richtig verstehen.

So wenig wie die virtuelle größe etwas über den physikalischen
Speicherverbraucht aussagt, so wenig sagt die Load Average über die CPU-
Auslastung aus.

Ich betone das so deutlich, weil ich das immer wieder sehe, dass Menschen
behaupten "Die Erde sei flach", während sie… grob eine kugelartige Form hat.
Post by Helge Reimer
Man kann sich 'detailierte Speicherinformationen' für die einzelnen
Prozesse anzeigen lassen.
Das fuktioniert bei mir auch. Wenn ich mir das für 'plasmashell' anzeigen
lassen möchte, dann verabschiedet sich KSysGuard mit
'Speicherzugriffsfehler'.
Interessant.
Post by Helge Reimer
Den Rest von deinem Text verstehe ich noch nicht, sorry.
Ja, und das ist der Punkt. Solange Du das nicht verstehst: verwende immer nur
RSS oder PSS als Anhaltsgröße.

Die Werte die KSysGuard in der Prozessliste in der Spalte "Speicher" zeigt,
sind an sich okay. Auch wenn ich von "618.644 K" gerade irgendwie nicht auf
entweder 623,8 MB (PSS) oder 608,7 MB (Unique Set Size) komme. Und die RSS ist
das auch nicht. Da könnte das Tool klarer sein. Auch mit MiB versus MB und so.

So, aber damit genug für heute.
--
Martin
Helge Reimer
2017-08-28 21:30:03 UTC
Permalink
Post by Martin Steigerwald
Die virtuelle Größe kommt aber nicht aus KSysGuard.
Nein, das habe ich von htop.
Post by Martin Steigerwald
Post by Helge Reimer
'Speicherzugriffsfehler'.
Interessant.
Allerdings.
Post by Martin Steigerwald
Ja, und das ist der Punkt. Solange Du das nicht verstehst: verwende immer
nur RSS oder PSS als Anhaltsgröße.
Mache ich ja eigentlich auch. Im aktuellen Fall steckt aber scheinbar ein
bisschen mehr dahinter und ich wollte wissen, was ich tun kann,
Post by Martin Steigerwald
Die Werte die KSysGuard in der Prozessliste in der Spalte "Speicher" zeigt,
sind an sich okay. Auch wenn ich von "618.644 K" gerade irgendwie nicht auf
entweder 623,8 MB (PSS) oder 608,7 MB (Unique Set Size) komme. Und die RSS
ist das auch nicht. Da könnte das Tool klarer sein. Auch mit MiB versus MB
und so.
Ja, OK.
Bei mir zeigt KSysGuard bei 'plasmashell' in der Spalte 'Speicher' im Laufe
der Zeit aber irgendwas mit '7.000.000 K' und weiter aufwärts.
Für mich ziemlicheindeutig, dass mit 'plasmashell' was nicht stimmt.
Martin Steigerwald
2017-08-28 21:50:01 UTC
Permalink
Post by Martin Steigerwald
Die Werte die KSysGuard in der Prozessliste in der Spalte "Speicher" zeigt,
Post by Martin Steigerwald
sind an sich okay. Auch wenn ich von "618.644 K" gerade irgendwie nicht auf
entweder 623,8 MB (PSS) oder 608,7 MB (Unique Set Size) komme. Und die RSS
ist das auch nicht. Da könnte das Tool klarer sein. Auch mit MiB versus MB
und so.
Ja, OK.
Bei mir zeigt KSysGuard bei 'plasmashell' in der Spalte 'Speicher' im Laufe
der Zeit aber irgendwas mit '7.000.000 K' und weiter aufwärts.
Für mich ziemlicheindeutig, dass mit 'plasmashell' was nicht stimmt.
Okay.

Dann dürfte smemstat ebenfalls unter PSS ähnlich viel anzeigen. Das würde ich
nochmal prüfen.

pmap -x auf die PID von plasmashell gibt eine Liste der einzelnen
Speicherbereiche aus. Ähnlich wie "Detaillierte Speicherinformationen", das
bei Dir ja crasht. Das ist dann allerdings schon etwas aufwendiger zu
analysieren. Mit strace geht es noch eine Ebene tiefer, aber das ist noch
aufwendiger. KCacheGrind / valgrind, da weiß ich aber gerade nicht, das Ding
für Speicherlecks heißt da irgendwie anders, glaube ich, wäre auch noch eine
Möglichkeit, aber ebenso aufwendig.

Wie das klappt, da auf einzelne Plasmoid/Widget-Ebene runter zu gehen, ist so
eine Sache, da die in der Regel im Prozess laufen… in der Regel als
Javascript/QML. eine Auflistung nach Threads bringt da ebenfalls nichts, da die
Tools da jeweils den Speicherverbrauch des Gesamtprozesses mit allen Threads
anzeigen.

atop hat in der Speicheransicht, Taste [m], auch RGROW, das anzeigt, wieviel
Speicher mehr Plasmashell belegt… aber im Grunde fordert Plasmashell ja zuviel
Speicher an, wenn da in KSysGuard irgendwas mit "'7.000.000 K'" steht. Das ist
also schon bekannt.

Ansonsten:

- Einzelne Widgets abschalten um zu sehen, ob ein Widget die Ursache ist.
- Mit einem neuen Benutzer und Standard-Konfiguration testen
- ~/.xsession-errors hat vielleicht noch Hinweise.

- Ansonsten Bugreport? Idealerweise Upstream.

Ciao,
--
Martin
Helge Reimer
2017-08-28 22:00:01 UTC
Permalink
Post by Martin Steigerwald
- Einzelne Widgets abschalten um zu sehen, ob ein Widget die Ursache ist.
Ich konnte mal eine Blick erhaschen, dass 'Redshift' bei irgendwas
fehlgeschlagen ist, aufgrund von Speichermangel.
Das wird er erste Kandidat zum abschalten.
Hat mein anderer user ohne Speicherprobleme auch nicht aktiv.
Post by Martin Steigerwald
- Mit einem neuen Benutzer und Standard-Konfiguration testen
Anderer User geht ja ohne Probleme.
Post by Martin Steigerwald
- ~/.xsession-errors hat vielleicht noch Hinweise.
Das ist ellenlang. Heute nicht mehr.
Helge Reimer
2017-08-28 21:50:01 UTC
Permalink
Post by Helge Reimer
Post by Martin Steigerwald
Post by Helge Reimer
'Speicherzugriffsfehler'.
Interessant.
Allerdings.
Als 'root ' tritt das Problem nicht auf. Folgendes kommt dabei heraus.
Kann man damit was anfangen?

Process 3467 - plasmashell

Summary

The process plasmashell (with pid 3467) is using approximately 5.7 GB of
memory.
It is using 5.7 GB privately, and a further 78.8 MB that is, or could be,
shared with other programs.
Dividing up the shared memory between all the processes sharing that memory we
get a reduced shared memory usage of 12.3 MB. Adding that to the private
usage, we get the above mentioned total memory footprint of 5.7 GB.
Library Usage

The memory usage of a process is found by adding up the memory usage of each
of its libraries, plus the process's own heap, stack and any other mappings,
plus the stack of its 12 threads.
Private
more
5850184 KB [heap]
64264 KB /dev/nvidiactl
1988 KB /usr/lib/x86_64-linux-gnu/libnvidia-glcore.so.375.82
944 KB /usr/lib/x86_64-linux-gnu/libQt5Multimedia.so.5.9.1
580 KB /usr/bin/plasmashell
Shared
more
9976 KB /usr/lib/x86_64-linux-gnu/libnvidia-glcore.so.375.82
4380 KB /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5.9.1
4312 KB /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.9.1
3396 KB /usr/lib/x86_64-linux-gnu/libQt5Qml.so.5.9.1
3316 KB /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5.9.1
Totals

Private 5936336 KB (= 29148 KB clean + 5907188 KB dirty)
Shared 80692 KB (= 80632 KB clean + 60 KB dirty)
Rss 6017028 KB (= Private + Shared)
Pss 5948967 KB (= Private + Shared/Number of Processes)
Swap 0 KB
Martin Steigerwald
2017-08-28 22:00:01 UTC
Permalink
Post by Helge Reimer
Post by Helge Reimer
Post by Martin Steigerwald
Post by Helge Reimer
'Speicherzugriffsfehler'.
Interessant.
Allerdings.
Als 'root ' tritt das Problem nicht auf. Folgendes kommt dabei heraus.
Kann man damit was anfangen?
Process 3467 - plasmashell
Summary
The process plasmashell (with pid 3467) is using approximately 5.7 GB of
memory.
It is using 5.7 GB privately, and a further 78.8 MB that is, or could be,
shared with other programs.
Dividing up the shared memory between all the processes sharing that memory
we get a reduced shared memory usage of 12.3 MB. Adding that to the
private usage, we get the above mentioned total memory footprint of 5.7 GB.
Library Usage
The memory usage of a process is found by adding up the memory usage of
each of its libraries, plus the process's own heap, stack and any other
mappings, plus the stack of its 12 threads.
Private
more
5850184 KB [heap]
^^^^^^^

Hier dürfte dann nur noch ein Profiling-Programm für Funktionen, um
Hauptspeicher anzufordern, weiterhelfen. Möglicherweise in diese Richtung:

massif-visualizer - Tool for visualizing memory usage recorded by Valgrind
Massif

Verwendet hab ich das selbst noch nicht.

Und hier braucht es mitunter schon gewisse Programmierkenntnisse, um draus
schlau zu werden.
Post by Helge Reimer
64264 KB /dev/nvidiactl
Hast Du vielleicht den NVidia-Treiber aktualisiert?


Posted on 27. August 2017 by Martin Flöser
Warning: NVIDIA driver 384.69 seems to be broken with QtQuick

https://blog.martin-graesslin.com/blog/2017/08/warning-nvidia-driver-384-69-seems-to-be-broken-with-qtquick/
Post by Helge Reimer
1988 KB /usr/lib/x86_64-linux-gnu/libnvidia-glcore.so.375.82
944 KB /usr/lib/x86_64-linux-gnu/libQt5Multimedia.so.5.9.1
580 KB /usr/bin/plasmashell
Shared
more
9976 KB /usr/lib/x86_64-linux-gnu/libnvidia-glcore.so.375.82
4380 KB /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5.9.1
4312 KB /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.9.1
3396 KB /usr/lib/x86_64-linux-gnu/libQt5Qml.so.5.9.1
3316 KB /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5.9.1
Totals
Private 5936336 KB (= 29148 KB clean + 5907188 KB dirty)
Shared 80692 KB (= 80632 KB clean + 60 KB dirty)
Rss 6017028 KB (= Private + Shared)
Pss 5948967 KB (= Private + Shared/Number of Processes)
Swap 0 KB
Gutnacht.
--
Martin
Helge Reimer
2017-08-28 22:50:02 UTC
Permalink
Post by Helge Reimer
Post by Helge Reimer
Post by Martin Steigerwald
Post by Helge Reimer
'Speicherzugriffsfehler'.
Interessant.
Allerdings.
Als 'root ' tritt das Problem nicht auf. Folgendes kommt dabei heraus.
Mittlerweile sind wir bei 11.189.444 K angekommen. 12.216.956 sind verbaut.
Gleich geht gar nichts mehr.
'KSysGuard' als root sagt erstmal

QStandardPaths: wrong ownership on runtime directory /run/user/1000, 1000
instead of 0

'detailierte Speicherinformationen' für 'plasmashell' lassen sich nicht mehr
anzeigen.
'KSysGuard' beendet sich ohne kommentar.
Helge Reimer
2017-08-28 20:40:02 UTC
Permalink
Post by Elimar Riesebieter
$ htop
-> <F6> M_SIZE
OK, danke.
'baloo_file' und 'krunner' haben eine virtuelle Größe von 257GB.

Werde mal testweise versuchen baloo abzuschalten.
Bei dem anderen Benutzer auf dem Rechner ist baloo aber auch aktiv und der hat
das Speicherproblem nicht.
Martin Steigerwald
2017-08-28 20:50:01 UTC
Permalink
Post by Helge Reimer
Post by Elimar Riesebieter
$ htop
-> <F6> M_SIZE
OK, danke.
'baloo_file' und 'krunner' haben eine virtuelle Größe von 257GB.
Die virtuelle Größe sagt nichts, aber auch *rein gar nichts* über den
tatsächlichen physikalischen Speicherverbrauch aus.

Wer etwas Anderes behauptet, hat die virtuelle Speicherverwaltung von Linux
(und den meisten anderen modernen Betriebssystemen) schlicht nicht verstanden.
Post by Helge Reimer
Werde mal testweise versuchen baloo abzuschalten.
Bei dem anderen Benutzer auf dem Rechner ist baloo aber auch aktiv und der
hat das Speicherproblem nicht.
Nochmal:

Die virtuelle Größe sagt nichts, aber auch *rein gar nichts* über den
tatsächlichen physikalischen Speicherverbrauch aus.

Das ist so ähnlich als wenn plötzlich alle zur Bank gehen würden und alle ihre
Konten und Sparkonten abheben würden… virtueller Adreßraum ist ein Riesen
Hokus Pokus. Der Linux Kernel pokert da standardmäßig, was das Zeug hält.


Leider sehe ich das immer wieder: Anwender schauen sich Werte in irgendwelchen
Top-artigen Programmen an und verstehen sie nicht. (Und ja, ich weiß wovon ich
rede, denn ich unterrichte das seit Jahren.)

Ich mag jetzt ausholen und die virtuelle Speicherverwaltung von Linux
erklären. Es dürfte genug Referenzen im Internet geben – mit wahrscheinlich
unterschiedlicher Qualität. Daher nur kurz:

- Eingeschränkt aussagekräftig ist die Resident Set Size (RSS, Resident)
- Am genauesten ist meines Erachtens die von mir erwähnte Proportional Set
Size.

Und wir hat das Thema hier bestimmt schon mehrere Male - wie ich stark
vermute, mit längeren Erklärungen von mir. Ist aber eine ganze Weile her.

Danke,
--
Martin
Helge Reimer
2017-08-29 16:10:02 UTC
Permalink
Hallo nochmal,

ich habe den Auslöser für mein Problem gefunden.
Das eigentliche Problem liegt wahrscheinlich viel weiter unten in den untiefen
von Qt und Plasma.

Der Auslöser war das Plasmoid 'Medien-Rahmen'.
Das hatte ich auf dem Desktop liegen und mir schön eine Diashow vieler
Urlaubsbilder anzeigen lassen.
Nach dem entfernen des Medienrahmens begnügt sich 'plasmashell' laut KSysGuard
mit knappen 80MB und selbst wenn ich den Medienrahmen wieder hinzufüge
(unkonfiguriert) werden es gerade mal 119MB. Auch schon happig, aber keine
11GB wie noch gestern.
Ich verzichte erstmal drauf oder konfiguriere etwas daran herum, aber das
Problem hat sich für mich damit erledigt.

Danke trotzdem.

Helge
Martin Steigerwald
2017-08-30 07:30:02 UTC
Permalink
Post by Helge Reimer
Hallo nochmal,
ich habe den Auslöser für mein Problem gefunden.
Das eigentliche Problem liegt wahrscheinlich viel weiter unten in den
untiefen von Qt und Plasma.
Der Auslöser war das Plasmoid 'Medien-Rahmen'.
Das hatte ich auf dem Desktop liegen und mir schön eine Diashow vieler
Urlaubsbilder anzeigen lassen.
Nach dem entfernen des Medienrahmens begnügt sich 'plasmashell' laut
KSysGuard mit knappen 80MB und selbst wenn ich den Medienrahmen wieder
hinzufüge (unkonfiguriert) werden es gerade mal 119MB. Auch schon happig,
aber keine 11GB wie noch gestern.
Ich verzichte erstmal drauf oder konfiguriere etwas daran herum, aber das
Problem hat sich für mich damit erledigt.
Wollte noch schreiben, dass ich Redshift Plasmoid auch verwende… und damit
keine Probleme habe.

Danke,
--
Martin
Loading...