Replying to Avatar jb55

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

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?

Reply to this note

Please Login to reply.

Discussion

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