Beiträge von volker.n

    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?

    luigi:

    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


    Code
    lsof -nP +L1 /dev/shm | grep DEL

    ist jetzt wieder leer.

    DANKE !

    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)

    Zypper Repos:

    und Ausgabe von ps sortiert nach Speichernutzung: (username ebenfalls ersetzt und die Ausgabe gekürzt, weil sie sonst unnötig lang ist)


    Ich 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.

    Alero:

    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

    Code
    Tasks: 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:

    Code
    sync; echo 1 > /proc/sys/vm/drop_caches
    sync; echo 2 > /proc/sys/vm/drop_caches
    sync; echo 3 > /proc/sys/vm/drop_caches

    Zu Alero:
    das System habe ich lediglich regelmäßig mit zypper dup angefasst und es verhält sich auch nach Neustart so merkwürdig


    Zu 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 mit

    sync; 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)