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.

  • Atemu@lemmy.ml
    7·
    3 days ago

    I don’t know what this tool is or how it gets its “memory” metric. If you want to continue to use it, please ascertain that these values correspond to RSS by cross checking with i.e. ps aux. RSS is the memory exclusively held by a given process which is typically what mean by the “memory usage” of any given process. Note however that this does not count anonymous pages of a process that are swapped or shared with other processes.

    Going into my task manager (Resources), I can see my using is using roughly 18/32GB of RAM despite closing all apps.

    This does not tell you (or us for that matter) anything without defining what “using” means here. My system is “using” 77% of RAM right now but 45% of memory is available for use because it’s cached.

    Please post the output of free -h aswell as swapon.

    Next, please post the contents of /proc/meminfo.

    Do you use ZFS?

    • Leaflet@lemmy.worldOPEnglish
      32·
      3 days ago

      Resources reports the same memory usage as btop. free tells me only 6GB is being used for cache.

      On a fresh boot, Resources and btop report less than 2GB RAM usage, obviously not including cached stuff. So for both tools to report 18GB with no apps open, it’s strange.

      ps aux looks all normal, nothing in the background using more than 1% of RAM.

      Using Fedora Silverblue 41 with btrfs.

  • solrize@lemmy.world
    5·
    3 days ago

    If you had something hog memory and a lot of other stuff got paged out of ram as a result, that can slow things down. Try running “top” and see how much swap space is in use. If it’s more than a little bit, once you have enough memory available by shutting off whatever was hogging it, try “swapoff” (pages the stuff back in, which can take a little while) followed by “swapon” to re-enable swap.

  • SavvyBeardedFish@reddthat.com
    5·
    3 days ago

    Are you by chance using an integrated GPU?

    Noticed that my AMD Radeon 680M uses quite a lot of RAM as shared memory.

    Using something like amdgpu_top will show how much RAM your iGPU is using, metric is ‘GTT’

    • Leaflet@lemmy.worldOPEnglish
      3·
      3 days ago

      I’m not sure if it is related to Newsflash is the problem. Besides, I’ve been using the same version for months, but this has only recently become a problem. And the problem persists after Newsflash is closed.

        • Leaflet@lemmy.worldOPEnglish
          3·
          3 days ago

          To my understanding, the kernel should clean up any memory leaks an app has when you close it.

  • 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).