I’ve been running into an issue recently where my system will start to stutter and freeze. Going into my task manager (Resources), I can see my using is using roughly 18/32GB of RAM despite closing all apps. Normally I should be at around 2GB on a fresh boot.

I’ve only noticed this issue appearing when first interacting with an app called Newsflash, but the issue persists even after closing the app. I even tried using systemd’s soft-reboot feature and even that did not clear the memory leak. So it seems the memory leak must be in the kernel itself.

And please don’t link linuxatemyram. This is not related to cached data.

  • gnuhaut@lemmy.ml
    11·
    3 days ago

    Just in general (I don’t know if this is relevant here), some points:

    Files from disk get “cached” (copied to RAM “pages”) whenever they are read. This is called the page cache or disk cache. They stay im RAM, even if not needed right now, until RAM is full and needed for something else, at which point the pages that have not been accessed the longest time get “evicted” (i.e. overwritten) first. This speeds up file reads whenever you read a file a second time (like closing and reopening a program). It is important, when looking at RAM usage, to not count the page cache as “used”, since there is no downside to having these pages/files in RAM. It’s strictly better to use unused RAM as a cache than not use it at all. I.e. free -h shows this:

                   total        used        free      shared  buff/cache   available
Mem:           7.4Gi       5.3Gi       536Mi       656Mi       2.6Gi       2.2Gi
Swap:          7.4Gi       812Mi       6.7Gi

    So here, you might conclude that the free/unused memory is only 536Mi, but most of the buff/cache memory can be used immediately by any program by evicting the disk cache, so it’s better to look at the available memory, rather the the free memory.

    Looking at the memory used by a specific process is also misleading, since some of the memory is shared between processes. Pretty much all processes, for example, have libc mapped into memory, but in reality, there is only one copy of libc in RAM (there is some per-process overhead still). If you added up all the memory used by all you processes, you will find that it is significantly higher than actual RAM usage, since so much memory is shared.

    Also as a practical tip, install earlyoom or systemd-oomd to kill processes eating up all your RAM, before the system becomes unresponsive due to thrashing (= evicting frequently used pages from the page cache because RAM is eaten up, resulting in lots of important stuff having to be reloaded from disk constantly, often slowing the system to the point of unresponsiveness).