#Per process memory usage is way less than system wide memory usage

65 messages · Page 1 of 1 (latest)

languid vector
#

I’m on Fedora 42, and something’s up with my memory usage. On fresh boot I use maybe a gigabyte, maybe 2 after starting hyprland, discord, and a browser. But over time my systems ram usage grows and I can’t tell what process is consuming it. Right now I have almost a day and a half of uptime and I’m sitting at 7.44 gb. I tried closing everything, even hyprland, and it’s still almost seven and a half gigabytes. And yes I am aware of filesystem cache, I’m looking at used and available memory in btop. The total memory usage with tree and aggregate on is 1 gb, so there’s about 6.5 gb missing. Looking back at btop the memory usage has come down to 6.78 gb, so it’s more like 5.78 gb missing. Smem reports similar values, the system wide memory usage is wildly over the RSS total. Earlier my computer almost froze and I had to kill android studio to prevent it from freezing

restive inlet
willow hedge
#

search kworker/ in btop

#

their stats should all be 0 though due to limitations

languid vector
languid vector
#

this is unfortunately an issue that will require some waiting to debug

willow hedge
#

In which I’m not really sure how to debug but

#

You can try other kernels and see if anything is different

restive inlet
#

i mean, Arch uses 10GB ram to cache for me at least. but it will allocate it to other processes if memory runs low

willow hedge
#

Caching shouldn’t take up the actual memory no?

#

Aka the available section

#

She mentioned shes looking at “available” memory in btop

#

And are aware of caches

restive inlet
#

i have no clue what it usually displays, hence i find free -h more useful as it displays it all

languid vector
#

I did notice a large amount of kernel dynamic memory being used, so I decided to log it repeatedly with smem as I opened and closed various apps

#

it grew to 1.8 gb and stayed there

#

specifically under the noncache column

#

I'll have to get the free -h after another day of uptime

restive inlet
languid vector
restive inlet
#

i still want the output of free -h though in case

willow hedge
#

If it does that would be a kernel bug

languid vector
#

this is free -h, then sudo smem -ktw, then sudo smem -kt

#

I can also do sudo free -h

#

if necessary

#

I ran smem as sudo because it seems to be able to see memory usage for processes started by root

#

I was in a tty at the time

#

right now I only have vesktop open, and I'm sitting at 5.5 gb of memory usage

#

btop reports the total of all processes to be 3 gb

# 
Area                           Used      Cache   Noncache 
firmware/hardware                 0          0          0 
kernel image                      0          0          0 
kernel dynamic memory          8.0G       4.4G       3.6G 
userspace memory               1.7G     480.7M       1.2G 
free memory                    5.3G       5.3G          0 
----------------------------------------------------------
                              15.0G      10.2G       4.8G
#

smem -ktw

#

it doesn't seem to have a different output with sudo

restive inlet
# languid vector

see, this is exactly why i wanted you to see free -h. you have a couple of sections. usedis just what it says on the tin. how much the system uses total (both user and non user). buff/cache is how much the system uses to cache. now for the confusing part. available and free are two different sections. so there is a distinction. free the currently free memory on the system (just like smem shows). available on the other hand combines used + some of the buff/cache. the system prioritizes optimizations of itself when it can. but if youre running low on memory, the system will stop using the cache, un allocate it and then allocate it where its needed. its literally what i suspected. there is no leaks anywhere. this is often when i check free -h i look at the available section, because thats how much the system is willing to give up. hope this answers your question

#

in conclusion, i dont see anything out of the ordinary. i mean. look at my free -h:

[jorgen@jorch ~]$ free -h
               total        used        free      shared  buff/cache   available
Mem:           125Gi        40Gi        68Gi       591Mi        18Gi        85Gi

i have 18GB in the cache. so the free section is rather useless. prefer to look at the available secition

languid vector
restive inlet
#

do it and run free -h then. im still certain its used in the cache

languid vector
#

I closed everything, even hyprland, and ran these commands into a log file

restive inlet
#

well either way, i dont see anything wrong. the free -h output makes sense to me

#

as i said. the kernel can use several GBs of RAM to cache things. but it is willing to stop using that memory and allocate it elsewhere. so though the idling may seem high from caching, it isnt "wasted" space or a memory leak

languid vector
#

look at the available memory

#

10 gb

#

vs total

#

14

#

available doesn't include cache

#

so what's using that memory

restive inlet
restive inlet
languid vector
willow hedge
restive inlet
willow hedge
#

thats called a memory leak

restive inlet
#

well, i did forget to mention the nuance that page tables may grow a bit. but up to a limit. thats on me

#

but in this case, there doesnt seem to be a memory leak

willow hedge
#

idk maybe op can post memory usage again when near crashing