Mit dem Ansatzpunkt hast du recht, jedoch liegen die außerhalb meiner Reichweite ...
Ich würde zumindest die Größe des tmpfs im smh auf einen maximalen Wert begrenzen. Ich habe mal gehört der sei per default bei halber Ramgröße, was ich zu viel finde. Wo stellt man den im Tumbleweed ein?
Beiträge von volker.n
-
-
Kurze followup Frage: wo kann ich dem Tumbleweed sagen, dass er kein tmpfs im shm anlegen soll, sondern für /tmp & co direkt das fs auf der SSD nutzen soll?
-
super Hinweis, ja es war verdächtig und die "Schuldigen" waren chrome und signal-desktop.
Ich hatte gestern versucht das System zu stressen: erst swap anmachen, viele Tabs im Firefox geöffnet. gewartet bis ca. 1 GB im swap ist und dann swapoff -a gemacht. Der Swap leerte sich und der Cache wurde klein. Bei 400MB Rest im Swap sank der Cachebereich nicht mehr und bei 200MB im swap blieb das System stehn. Dann wieder warten bis der oom-Killer zuschlägt. Der niedrigste Wert den der Cache angenommen hatte war 4,2 GB (Jetzt gehe ich davon aus, dass diese von chrome und Signal waren. Ich habe die beiden jetzt mal gekillt und die Ausgabe von
ist jetzt wieder leer.
DANKE !
-
Kurzer Zwischenstand: Ich habe auf X11 ungestellt und bis jetzt keinen Hänger mehr gehabt. Ich werde mal versuchen im laufe der Woche einen Stresstest zu machen.
-
Die Umstellung auf X11 werde ich nachher mal probieren.
Neuer user ist auch eine gute Idee, denn es könnte ja sein, dass sich irgend ein Mist im Homeverzeichnis abgelegt hat, der hier für merkwürdiges Verhalten sorgt. Dann dürfte ich zum Testen aber nichts aus dem alten Home rübernehmen ... was ein vergleichbares testen erschwert. Ich mach im ersten Schritt mal das mit X11 -
Also hier die Ausgabe von TOP: (ich habe den username durch xxxxxxxx ersetzt)
Code
Alles anzeigentop - 00:32:36 up 3 days, 2:13, 3 users, load average: 3.40, 4.18, 4.02 Tasks: 322 total, 1 running, 320 sleep, 1 d-sleep, 0 stopped, 0 zombie %Cpu(s): 27.8 us, 5.7 sy, 0.1 ni, 64.6 id, 0.4 wa, 0.0 hi, 1.4 si, 0.0 st MiB Mem : 15774.16+total, 464.230 free, 13604.43+used, 8324.547 buff/cache MiB Swap: 15765.31+total, 8508.062 free, 7257.250 used. 2169.723 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 3264 xxxxxxxx 20 0 2164076 192008 13684 S 12.24 1.189 288:13.32 plasma-systemmo 1683 xxxxxxxx -2 0 3321068 711500 615152 S 11.25 4.405 6,15 kwin_wayland 513815 xxxxxxxx 20 0 5752736 704900 245596 S 9.592 4.364 111:51.76 firefox 552 root 20 0 0 0 0 S 3.638 0.000 14:09.80 btrfs-transaction 556451 xxxxxxxx 20 0 2835020 278872 45056 S 3.638 1.726 9:25.98 Isolated Web Co 574398 xxxxxxxx 20 0 2677352 155584 79184 S 3.638 0.963 2:04.91 Isolated Web Co 531124 xxxxxxxx 20 0 2902496 350828 41232 S 3.308 2.172 24:16.83 Isolated Web Co 8462 xxxxxxxx 20 0 1.106t 510560 52632 S 2.977 3.161 159:25.41 electronZypper Repos:
Code
Alles anzeigen# | Alias | Name | Enabled | GPG Check | Refresh | Priority | Type | URI | Service ---+----------------------------------------+------------------------------------------------------+---------+-----------+---------+----------+--------+-------------------------------------------------------------------------------------+-------- 1 | ftp.gwdg.de-openSUSE_Tumbleweed | Packman Repository | Yes | (r ) Yes | Yes | 99 | rpm-md | http://ftp.gwdg.de/pub/linux/misc/packman/suse/openSUSE_Tumbleweed/ | 2 | https-download.opensuse.org-176bfe89 | network | Yes | (r ) Yes | Yes | 99 | rpm-md | https://download.opensuse.org/repositories/network/openSUSE_Tumbleweed/ | 3 | https-download.opensuse.org-ad1bc8e4 | openSUSE:Tumbleweed | Yes | (r ) Yes | Yes | 99 | rpm-md | https://download.opensuse.org/repositories/openSUSE:/Tumbleweed/standard/ | 4 | network_im_signal | Signal Messaging Devel Project (openSUSE_Tumbleweed) | Yes | (r ) Yes | No | 99 | rpm-md | https://download.opensuse.org/repositories/network:/im:/signal/openSUSE_Tumbleweed/ | 5 | repo-debug | openSUSE-Tumbleweed-Debug | No | ---- | ---- | 99 | N/A | http://download.opensuse.org/debug/tumbleweed/repo/oss/ | 7 | repo-non-oss | openSUSE-Tumbleweed-Non-Oss | Yes | (r ) Yes | Yes | 99 | rpm-md | http://download.opensuse.org/tumbleweed/repo/non-oss/ | 8 | repo-openh264 | Open H.264 Codec (openSUSE Tumbleweed) | Yes | (r ) Yes | Yes | 99 | rpm-md | http://codecs.opensuse.org/openh264/openSUSE_Tumbleweed | 9 | repo-oss | openSUSE-Tumbleweed-Oss | Yes | (r ) Yes | Yes | 99 | rpm-md | http://download.opensuse.org/tumbleweed/repo/oss/ | 10 | repo-update | openSUSE-Tumbleweed-Update | Yes | (r ) Yes | Yes | 99 | rpm-md | http://download.opensuse.org/update/tumbleweed/ |und Ausgabe von ps sortiert nach Speichernutzung: (username ebenfalls ersetzt und die Ausgabe gekürzt, weil sie sonst unnötig lang ist)
Code
Alles anzeigen6997 xxxxxxxx 6.1 /usr/lib64/libreoffice/program/soffice.bin --splash-pipe=5 520142 xxxxxxxx 4.8 /usr/lib64/thunderbird/thunderbird-bin 1683 xxxxxxxx 4.3 /usr/bin/kwin_wayland --wayland-fd 7 --socket wayland-0 --xwayland-fd 8 --xwayland-fd 9 --xwayland-display :1 --xwayland-xauthority /run/user/1000/xauth_yKGHci --xwayland 513815 xxxxxxxx 4.0 /usr/lib64/firefox/firefox 8462 xxxxxxxx 3.0 /usr/lib64/electron/electron --type=renderer --enable-crash-reporter=10016d9d-1d15-4a0c-a0d5-6802aa2f335c,no_channel --user-data-dir=/home/xxxxxxxx/.config/Signal --fetch-schemes=attachment --streaming-schemes=attachment --app-path=/usr/libexec/signal-desktop --no-sandbox --no-zygote --enable-blink-features=CSSPseudoDir,CSSLogical --disable-blink-features=Accelerated2dCanvas,AcceleratedSmallCanvases --lang=de --num-raster-threads=3 --enable-main-frame-before-activation --renderer-client-id=4 --time-ticks-at-unix-epoch=-1737148769914231 --launch-time-ticks=6027950408 --shared-files=v8_context_snapshot_data:100 --field-trial-handle=3,i,4311152870638733119,6458180555497843455,262144 --disable-features=HardwareMediaKeyHandling,SpareRendererForSitePerProcess --variations-seed-version 559083 xxxxxxxx 2.3 /usr/lib64/firefox/firefox -contentproc -isForBrowser -prefsHandle 0 -prefsLen 45144 -prefMapHandle 1 -prefMapSize 288936 -jsInitHandle 2 -jsInitLen 234660 -parentBuildID 20241209150345 -sandboxReporter 3 -chrootClient 4 -ipcHandle 5 -initialChannelId {c4345a65-789e-4413-aa25-6ff3ef3e337c} -parentPid 513815 -crashReporter 6 -greomni /usr/lib64/firefox/omni.ja -appomni /usr/lib64/firefox/browser/omni.ja -appDir /usr/lib64/firefox/browser 531124 xxxxxxxx 2.1 /usr/lib64/firefox/firefox -contentproc -isForBrowser -prefsHandle 0 -prefsLen 44624 -prefMapHandle 1 -prefMapSize 288936 -jsInitHandle 2 -jsInitLen 234660 -parentBuildID 20241209150345 -sandboxReporter 3 -chrootClient 4 -ipcHandle 5 -initialChannelId {550115de-2085-4f8e-9887-69512494518e} -parentPid 513815 -crashReporter 6 -greomni /usr/lib64/firefox/omni.ja -appomni /usr/lib64/firefox/browser/omni.ja -appDir /usr/lib64/firefox/browser 556451 xxxxxxxx 1.8 /usr/lib64/firefox/firefox -contentproc -isForBrowser -prefsHandle 0 -prefsLen 45144 -prefMapHandle 1 -prefMapSize 288936 -jsInitHandle 2 -jsInitLen 234660 -parentBuildID 20241209150345 -sandboxReporter 3 -chrootClient 4 -ipcHandle 5 -initialChannelId {e175e843-303d-4bce-8233-fcffdb3dc1e6} -parentPid 513815 -crashReporter 6 -greomni /usr/lib64/firefox/omni.ja -appomni /usr/lib64/firefox/browser/omni.ja -appDir /usr/lib64/firefox/browser 1945 xxxxxxxx 1.6 /usr/bin/plasmashell --no-respawn 514528 xxxxxxxx 1.5 /usr/lib64/firefox/firefox -contentproc -isForBrowser -prefsHandle 0 -prefsLen 44624 -prefMapHandle 1 -prefMapSize 288936 -jsInitHandle 2 -jsInitLen 234660 -parentBuildID 20241209150345 -sandboxReporter 3 -chrootClient 4 -ipcHandle 5 -initialChannelId {59699e63-b4bc-4da6-8c26-8e26ce8b6c52} -parentPid 513815 -crashReporter 6 -greomni /usr/lib64/firefox/omni.ja -appomni /usr/lib64/firefox/browser/omni.ja -appDir /usr/lib64/firefox/browser 514034 xxxxxxxx 1.2 /usr/lib64/firefox/firefox -contentproc -isForBrowser -prefsHandle 0 -prefsLen 44351 -prefMapHandle 1 -prefMapSize 288936 -jsInitHandle 2 -jsInitLen 234660 -parentBuildID 20241209150345 -sandboxReporter 3 -chrootClient 4 -ipcHandle 5 -initialChannelId {d2c391fa-aa24-4087-8c55-460753b35db3} -parentPid 513815 -crashReporter 6 -greomni /usr/lib64/firefox/omni.ja -appomni /usr/lib64/firefox/browser/omni.ja -appDir /usr/lib64/firefox/browser 8084 xxxxxxxx 1.1 /usr/bin/telegram-desktop 3264 xxxxxxxx 1.1 /usr/bin/plasma-systemmonitor 513913 xxxxxxxx 0.9 /usr/lib64/firefox/firefox -contentproc -isForBrowser -prefsHandle 0 -prefsLen 55888 -prefMapHandle 1 -prefMapSize 288936 -jsInitHandle 2 -jsInitLen 234660 -parentBuildID 20241209150345 -sandboxReporter 3 -chrootClient 4 -ipcHandle 5 -initialChannelId {adb4b6d3-f378-48d4-b934-1b9f3b628d9b} -parentPid 513815 -crashReporter 6 -greomni /usr/lib64/firefox/omni.ja -appomni /usr/lib64/firefox/browser/omni.ja -appDir /usr/lib64/firefox/browser 564190 xxxxxxxx 0.9 /usr/lib64/firefox/firefox -contentproc -isForBrowser -prefsHandle 0 -prefsLen 45144 -prefMapHandle 1 -prefMapSize 288936 -jsInitHandle 2 -jsInitLen 234660 -parentBuildID 20241209150345 -sandboxReporter 3 -chrootClient 4 -ipcHandle 5 -initialChannelId {1b6a25fe-63a1-4c5c-8d8b-f464257b5ec2} -parentPid 513815 -crashReporter 6 -greomni /usr/lib64/firefox/omni.ja -appomni /usr/lib64/firefox/browser/omni.ja -appDir /usr/lib64/firefox/browser 8143 xxxxxxxx 0.9 /usr/lib64/electron/electron --use-tray-icon /usr/libexec/signal-desktop 571261 xxxxxxxx 0.8 /usr/bin/okular 572816 xxxxxxxx 0.8 /opt/master-pdf-editor-4/masterpdfeditor4 520423 xxxxxxxx 0.7 /usr/lib64/firefox/firefox -contentproc -isForBrowser -prefsHandle 0 -prefsLen 44624 -prefMapHandle 1 -prefMapSize 288936 -jsInitHandle 2 -jsInitLen 234660 -parentBuildID 20241209150345 -sandboxReporter 3 -chrootClient 4 -ipcHandle 5 -initialChannelId {d83ecff2-13e3-4ba3-8641-541e2471d3fc} -parentPid 513815 -crashReporter 6 -greomni /usr/lib64/firefox/omni.ja -appomni /usr/lib64/firefox/browser/omni.ja -appDir /usr/lib64/firefox/browser 410661 xxxxxxxx 0.7 /usr/bin/okular 21514 xxxxxxxx 0.7 /usr/bin/dolphinIch bin wirklich kein Neuling und bin schon seit 1996 mit SuSE 4.2. dabei. Ihr könnt mir glauben, dass ich schon nach Speicherfressern, Speicher leaks und ähnlichem geforscht habe. Ich hatte aber noch nicht mit diesen sehr nervigen Systemhängern zu tun, die ich auf die "Nichtverfügbarkeit" von RAM zurückführe, denn warum sollte erst das System einfrieren, nach einiger Zeit der out-of-memory-killer zuschlagen und dann wieder laufen.
Besonders spannend fand ich meinen Versuch das SWAP abzustellen. Da geht das System im Freeze obwohl noch 10GB im filecache benutzt werden, die eigentlich für App-Speicher freigegeben werden müssten.
-
Ich betreibe das System ohne Veränderung. Ich habe lediglich ausprobiert die swapiness auf 1 zu setzen, was aber keinen Erfolg gebracht hat.
Das System fängt an den App-Speicher ins swap zu verlagern, was die Reaktionszeiten der Apps verlangsamt (ist geschenkt) nach einer gewissen Zeit ist auch der Swap voll und das System hängt für ein paar Minuten bis der oom-killer eine App killt. Ein erneutes starten der gekillten App geht manchmal, aber dann habe ich gleich wieder ein freeze + oom-killer ...
Während der ganzen Zeit wird jedoch teilweise mehr 10GB (von 16!) als Cachespeicher genutzt, was mir total unsinnig erscheint.
Wenn die swappiness auf standard 60 steht passiert es schneller, bei 1 dauert es ein wenig länger und bei swapoff geht es noch schneller, weil die Phase des Auslagerns fehlt.
Ich habe auch schon nach Memory-leaks gesucht, aber der angezeigte genutzte Prozessspeicher ist einigermaßen stabil. Es sieht einfach so aus, also ob der filecache sich den RAM greift und nicht wieder freigibt.
Hier die TOP Header
CodeTasks: 322 total, 2 running, 320 sleep, 0 d-sleep, 0 stopped, 0 zombie %Cpu(s): 26.3 us, 7.0 sy, 0.0 ni, 65.2 id, 0.1 wa, 0.0 hi, 1.5 si, 0.0 st top - 21:15:28 up 2 days, 22:55, 3 users, load average: 0.66, 0.66, 0.66 Tasks: 311 total, 1 running, 310 sleep, 0 d-sleep, 0 stopped, 0 zombie %Cpu(s): 10.8 us, 3.6 sy, 0.0 ni, 85.2 id, 0.3 wa, 0.0 hi, 0.1 si, 0.0 st MiB Mem : 15774.16+total, 195.199 free, 12932.06+used, 8392.852 buff/cache MiB Swap: 15765.31+total, 9750.309 free, 6015.004 used. 2842.094 avail Mem -
Zu liugi:
ich habe alle drei probiert:
Codesync; echo 1 > /proc/sys/vm/drop_caches sync; echo 2 > /proc/sys/vm/drop_caches sync; echo 3 > /proc/sys/vm/drop_cachesZu Alero:
das System habe ich lediglich regelmäßig mit zypper dup angefasst und es verhält sich auch nach Neustart so merkwürdigZu Sauerland:
Nach Reboot werden vom KDE die Programme wieder gestartet und ich kann im Ksystemmonitor gut sehen wie der Speicher gefüllt wird. Wenn alles geladen ist, ist der Speicher wie im Anfangspost beschrieben. Jetzt läuft die Kiste ein paar Stunden und der SWAP ist trotz swappiness von 1 mit 6GB gefüllt während der Cache 7,3 GB "festhält"MiB Mem : 15774.16+total, 468.102 free, 13621.79+used, 7287.828 buff/cache
MiB Swap: 15765.31+total, 9757.898 free, 6007.414 used. 2152.367 avail Mem
-
Moin allesam.
ich habe ein aktuelles Tumbleweed am laufen und folgendes Problem:
von 16GB RAM werden gute 6GB für Programme genutzt, der Rest (ca. 9GB) als Cache. Es ist ja gewünschtes Linux-Verhalten, dass der ungenutzte Speicher vom Kernel zum file caching genutzt wird. Meine Erwartung wäre, dass der Kernel Cachespeicher freigibt, wenn neue Programme gestartet werden. Mein System verhält sich jedoch anders, denn anstatt Cachespeicher freizugeben, fängt es an den Programspeicher ins SWAP auszulagern.
Ich habe versucht mitsync; echo [1-3] /proc/sys/vm/drop_caches
den Cachespeicher zu leeren, was nicht funktionierte. Ich habe die swapiness von 60 auf 1 runtergedreht, was auch nichts nutzte. Wenn ich mit swapoff -a das swappen ganz verhindere, hängt erst das System und dann fängt der out-of-memory killer an Programme zu töten - der Cachespeicher bleibt bei seiner Größe von 9GB ...
Irgendwelche Ideen dazu?
-
Hallo allesamen,
ich habe leider genau das gleiche Problem wieder der Themenersteller. Der Cache-Memory füllt sich schleichend auf und geht auch nicht runter, wenn der Speicher voll ist. Dann kommt ein freese für ein paar Minuten bis der oom-killer zuschlägt. Irgendwann kann der oom-killer aber keine App mehr killen, weil kaum noch was da ist. Wenn ich zulange mit dem reboot warte, dann geht auch der nicht mehr ... -> 10 Sek powertaste als letzten Ausweg.echo [1-3] /proc/sys/vm/drop_caches bewirkt auch nichts.
wenn ich den swap anmache, läuft es etwas länger, fängt aber recht bald an wie blöd zu swappen, was das ganze system verlangsamt. Ich dachte immer dass der cache nur den "unbenutzten" Speicher nutzt und diesen sofort freigibt, wenn eine App speicher will.
jemand eine Idee?
(Normales Tumbelweed, mit zypper dup aktuell gehalten)