its kind of frustrating that operating systems don't show the actual memory usage of applications properly

right now linux is reporting that notedeck is using 1.8GB of memory, but thats misleading because its counting memory mmap'd in nostrdb. I had to write a script to see the "actual" memory usage:

$ smaps $(pgrep notedeck)

> Total RSS: 1840.65 MiB

> Claimable (file-backed, clean pages): 1317.52 MiB

> Effective memory usage (RSS - claimable): 523.12 MiB

its using 1.3g of page cache memory, but that gets immediately reclaimed by other apps that actually need it. its really only using 500MiB, which is still pretty high, but not as bad as 2GB.

the way mmap works is that you give it a file on disk, and the operating system gives back a pointer that looks like its somewhere in your system memory (RAM). its not a physical address, its a virtual one managed by the OS.

anytime you read from this pointer, it will read in data from disk and store it in the page cache, so to the programmer it looks like you're just accessing memory but its actually data on disk thats cached in memory.

so naturally when you scroll through a million notes, all of this data will get loaded into the page cache, and it looks like notedeck is using 8GB of memory, but in reality its just the operating system that has loaded the entire database into memory for performance. but this memory is *reclaimable* by other processes, so it doesn't have any impact on your system.

the end result: confused users, people removing the app thinking its a memory hog. le sigh.

anyways.... sorry for this long winded sunday morning rant about virtual memory.

gm #nostr

Reply to this note

Please Login to reply.

Discussion

The only recent memory heh of worrying about ram usage is trying to do stuff on a 1-2gb VPS. For desktop I'm only ever checking top for CPU because why is my fan running? Or something is glitching in a sluggish way.

Caching feels foundational to good UX with Nostr. I bet you're caching a lot of things nobody ever has to think about.

lmdb is great on purposed servers but i suspect it will be a challenge on end user devices. is a file option possible with nostrdb or does it undermine the design entirely?

what do you mean file option?

like the ability to use sqlite instead of lmdb

that would make it slower for no gain, what would be the point ?

flexibility is sometimes as important as speed.

That’s what she said 😝

some user devices may not have GBs of memory for lmdb to do its thing

i think you completely missed the point of my post. page cache is not “using” memory when it can be immediately evicted by apps allocating memory for real.

nostrdb effectively uses 0 memory since it is non-copy when querying. Nothing is copied into main memory, its just the page cache which the OS manages and is evictable, unlike explicitly allocated memory by processes.

The problem is that the OS reports this as resident set usage of the process, mixed in with other non-reclaimable memory usage, so it’s very misleading.

If your system started swapping you would see nostrdb memory usage go to 0

ack thanks for the explainer

Good morning

In a sense, you might be right, but I think it's still better that they show the total memory you use. People are trying to see if they have enough memory to run all their apps full speed. Yes, your OS might be allocating more memory to notedeck to run it faster, but that's the performance that most people are trying to measure for.

Personally I would not like it if the OS said I had plenty of free memory left, when in reality, some of my apps would run much faster if I had more.

Notedeck takes 2GBs to run smoothly without reading notes off the hard drive every time. I'd rather know that than to see it slow down without explanation.

The end of this discussion leads to acknowledging that memory isn't a binary "enough" or "not enough". Maybe the solution is for task managers to show levels of memory usage. Like having 3 numbers for each app, one for how much it needs (500MB), one for how much it's actually using (1.8GB), and one for how much it would benefit from having (potentially over the previous figure if you are memory limited).