TR Forums

I just noticed I had quite a lot of RAM in use that I couldn't account for through htop, ramdisks, or ZRAM swap. Htop said FF was taking ~1.6 GB and everything else (ramdisks and such included) should have totalled less than 500 MB, but RAM use was more like 2.9 GB, for a shortfall of ~800 MB. When I shut down FF, RAM use dropped all the way to 400 MB. Apparently FF was responsible for 2.5 GB, not the 1.6 GB it was labelled as resident in. On booting FF back up again, it's behaving more normally, with 900 MB resident / 100 MB shared and system RAM use at 1.25 GB. The system does have a bit over a week of uptime, and FF had been up long enough to accumulate 11 hours of CPU time. What happened here? Alternately, how could I debug this more properly if it happens again?

To be clear, this isn't an actual problem of any sort, I'm just curious.

Edit: I forgot to mention this is Arch Linux.

Sounds like a leak. It happens. Not all that much you could do beyond shutting FF down more often.

DancinJack wrote:

Sounds like a leak. It happens. Not all that much you could do beyond shutting FF down more often.

Most likely, but what I'm really wondering is why it didn't show as FF's use.

Maybe standby memory.

https://technet.microsoft.com/en-us/mag ... ernel.aspx

when a physical page (which is typically 4KB in size) that's owned by a process was reclaimed by the system, the Memory Manager typically placed the page at the end of the Standby List. If the process wanted to access the page again, the Memory Manager took the page from the Standby List and reassigned it to the process. When a process wanted to use a new page of physical memory and no free memory was available, the Memory Manager gave it the page at the front the Standby List.

https://blogs.msdn.microsoft.com/tims/2 ... -part-two/
https://www.youtube.com/watch?v=AjTl53I_qzY

I forgot to mention this is Arch Linux.

As far as I know, stuff like what you're describing shows up for me under a separate heading (cache). Cache tends to expand to fill available memory very quickly, but used (committed) memory doesn't show that kind of behavior.

Resident memory is memory that's actually being used. A process may also have memory pages paged out to disk as well. Linux has some very interesting memory usage in terms of caching disk agressively and paging out untouched memory pages.

I wouldn't worry about it unless you have some issue. Was there some behaviour in your system that led you to go digging through the RAM stats?

Nah, I just noticed it was using a bit more memory than it should have been and got curious.

Linux's pagefile use isn't half as weird as Windows' or OS X's are, and if you don't like how Linux does it you can just tweak vm.swappiness. I don't have any swap set up on disk, I just use ZRAM - basically it's a compressed ramdisk I set to be swap (it nominally gets a compression ratio of ~2:1, compresses about as fast as disk access, decompresses a lot faster, and doesn't wear on my SSD). I also don't use much RAM in the first place unless I'm gaming, so the ZRAM swap rarely even comes into the picture. (It's got 3.93M in it right now, and had 17 point something MB in it when things were being weird.)

To phrase the question differently.... Firefox was supposedly resident in 1.6 GB, but when I shut it down the system's committed memory use decreased by 2.5 GB instead. Everything else that I could see on the system was using <400 MB all put together both before and after FF was stopped, and pagefiles/ramdisks/whatever added up to a mere 27 MB. How is this possible?

All I've been able to think of is that FF was/is somehow causing a memory leak in the kernel, but that doesn't sound very plausible.

Whoa, it's doing it again already. Everything else still looks like ~400 MB, swap use is 3.93M, Firefox is resident in ~1600M (climbs slowly until GC, but stays in that area) and sharing 103M, and committed system RAM use is at a whopping 3 GB. FF's about:memory agrees with the ~1600M resident figure. Forcing FF to garbage collect (minimize memory usage, more precisely) had no significant effect on anything.

htop (total mem use up top, resident and shared per-process along the left, sorted by resident):


free:


ramdisks (in bytes):


Quick, what else should I check?

This is a long shot, but the next time you see it happening, try running the following as root:

This will flush and drop all memory that has been allocated as filesystem cache. (It is non-destructive, the only impact should be a small temporary performance hit as stuff that was being actively used gets read back in to filesystem cache from your physical I/O devices.)

I say "long shot" because I don't see how Firefox could be influencing the filesystem cache this way; exiting Firefox should have no effect on the cache.

More likely this is a Firefox bug... misuse/abuse of mmap() system call or somesuch, perhaps.

That did it alright - dropped my committed RAM use from 2.9 GB to 1.2 GB. I thought free listed filesystem caches under buf/cache, though? I may have some reading to do. Is there some way handy I could look at these filesystem cache allocations in particular? Also, any suggestions for reading on this? Thanks!

synthtel2 wrote:

I may have some reading to do.

Heh, you and me both -- like I said, I thought it was a long shot! (And I do this sort of stuff for a living these days...)

At least the good news is that this should be completely harmless in practice. By definition, any RAM that gets freed up when you hit that "drop_caches" pseudo-file would have been recycled automatically by the system if it had started to run short of physical RAM.

As an aside... the drop_caches trick is very useful if you are running any sort of storage benchmarking under Linux. It prevents the results from being tainted by disk blocks which are already resident in cache, potentially improving consistency of results from run to run.

synthtel2 wrote:

I just noticed I had quite a lot of RAM in use that I couldn't account for through htop, ramdisks, or ZRAM swap. Htop said FF was taking ~1.6 GB and everything else (ramdisks and such included) should have totalled less than 500 MB, but RAM use was more like 2.9 GB, for a shortfall of ~800 MB. When I shut down FF, RAM use dropped all the way to 400 MB. Apparently FF was responsible for 2.5 GB, not the 1.6 GB it was labelled as resident in. On booting FF back up again, it's behaving more normally, with 900 MB resident / 100 MB shared and system RAM use at 1.25 GB. The system does have a bit over a week of uptime, and FF had been up long enough to accumulate 11 hours of CPU time. What happened here? Alternately, how could I debug this more properly if it happens again?

To be clear, this isn't an actual problem of any sort, I'm just curious.

Edit: I forgot to mention this is Arch Linux.

Firefox on all platforms, including Windows, Ubuntu, Suse, Fedora, and the BSD's has a bug in it, or some plugin it uses by default does because if you open a lot of tabs, with certain pages, if you monitor ram usage you will see that under "plugins" the ram usage is through the roof, on my system with 16gb of ram I have seen a plugin eat up all the ram and bring the whole system to a crawl. The good thing with Linux is that it doesn't last long, usually within a minute of 2 the plugin releases the ram it's eating up and things go back to normal.