Cleaning System Resources & Cache memory

The cleaning seems not to be happening correctly for me, I had to reboot because everything I tried to start failed with “Out of Memory” errors and there was no way to shrink that cache. There was nothing else running apart terminal (which I was using to try to find what was causing the memory usage) and all memory was reported as used under such entry in the sidebar

1 Like

Maybe Falkon and YT watching leaked memory in system resources.

Caches, as PulkoMandy wrote, are mainly file system caches that are freed when memory is needed.

Maybe those “out of memory” errors came from system resources being exhausted instead of “normal” RAM.

It would help if you could recreate that problematic situation.
Together with the version of Haiku & Falkon used, plus the used GFX and sound drivers.

Hello. I have exactly the same issue that @javanx mention. When browse some pages with Falkon, the System resources and caches start to grow up, eating all the memory. The memory is not released even after closing Falkon browser. I am not sure, but looks like some webpages are more prone to causes this issue than others.

I will submit a ticket with more details (not sure where it belongs: Haiku trac or Haikuports bugtracker).

1 Like
+1  

I have exactly the same issue that @javanx mention.

1 Like

Feel free to put it on trac.

1 Like

Me too.
(It hurts more on 3GB of RAM)

Please check if there are files in /var/shared_memory even after closing Falkon. If so, see if deleting everything in there fixes the problem.

Please also check there aren’t lingering processes in the background.

3 Likes

No files.

There are no processes.
The problem is in the RAMFS Haiku ?

I don’t know. I think WebKitGTK uses the RAMFS more than Falkon does, ultimately, so that may not be the problem.

I will have to try and reproduce the problem. Someone who can consistently cause it, please open a ticket with more details.

3 Likes

Me also interested :

does it occur on 32bit Haiku also ?..

I mean as actually I’m on 64bit Haiku.
I have 32 GB RAM and since I installed this version some month ago … first time I went up more than 25 GB used memory.
Now as I closed Falkon
I ganed only about
max. 1.1 - 1.3 GB memory

Then I closed the Web Epiphany that is available on 32bit surely – which uses different engine and when I stopped that it also freed up some GB (max 3-4 GB - with 4 tabs with one heavy : Youtube, others were almost static by their content compared to YT), so more than Falkon stop freed up in memory.

Now I have Web+ running and used memory moves between 18092.0 MB … 18092.2 MB up and down- increasing stopped

Me also stopped earlier
2 Qmplay2 sessions
(one with a paused playing and
one with ready to play random youtube links to play)
1 waiting VLC as well for any downloaded videos.
They had not freed up much memory , but seems not occupied more as well.

I created a screenshot about desktop – opened the Memory usage in ProcessController of Deskbar’s “systray”,

and you can see the pinned
Memory usage in ActivityMonitor replicant as well.

As you can see the Haiku system resources occupy the most memory (on ritght - in the ProcessController details), but of course these can be allocated for an application as well …
as in htop Web+ (6300 MB) team and app_server (515 MB) team are the biggest ones.- by VIRT aka Virtual Memory usage.

From this - as I have not enough knowledge to investigate deeper - seems named " System resources and caches " the latter can be behind holded memory.
This way some caches should be the cause of increasing memory usage.
What the proper answer I let to answer else.

I’m curious if it happens on 32bit Haiku too ?
Noone above mentioned the actually used Haiku version.

EDIT :
fixed typos. I wrote cashes instead of caches - and had not recognized until now.

I opened a ticket

https://dev.haiku-os.org/ticket/18724

I use Haiku 64 bit hrev57465, and r1beta4+93. Both have this problem.

1 Like

RAM FS ramdisk occupies memory. Falkon creates temporary files on it, deletes them, but occupied space is not freed up.

3 Likes

I see. Thanks for your update.

It’s very easy to reproduce, just run haiku in a vm and give it 1 or 2 GB of ram and use any browser, the memory is exhausted in less than 5 minutes of browsing and is not released when you close the browser, only a reboot will, sometimes loading a single website like reddit is enough to trigger it, because we have 2 problems here, a memory leak possibly somewehe in the networking and the fact that the kernel does no release the memory after closing the browser, FWIW i remember this networking memory leak started right after the gsoc when a student worked on the tcp protocol, i hope this helps narrow down the area of investigations.

2 Likes

The problem talked about in this thread seems to be about RAMFS memory usage, though. The ticket authors mention that when using BFS instead of RAMFS for the temporary files, BFS disk usage goes up and does not decrease until after checkfs. So something else is going on there.

1 Like

What @javanx described above about using falkon is definitely a behavior that existed way before the RAMFS thing was implemented, and it’s not specific to falkon, and the RAMFS memory usage might just be yet another side effect of what ever causes the memory leak and what ever causes the kernel not to release the used memory after the apps are closed, the latter is not specific to browsers either it is just more obvious with the browsers.

2 Likes

https://dev.haiku-os.org/ticket/18724
fixed !!!

2 Likes

Cool …, unfortunately it does not help to ones who are still on Haiku Beta4 :(…

1 Like

I have created the change request for porting it to R1beta4: https://review.haiku-os.org/c/haiku/+/7218

No one had mentionned in the ticket that beta4 is also affected.

We will wait a few days to make sure there are no regressions before merging it.

3 Likes

Ahoy,

As in another thread I shared - the fix was released for Beta4 too recently :

As the sharing of post resulted as sliding a bit – I copy here the post main part here :

The release of new Haiku level with affected fix is available now

    upgrade package haiku-r1~beta4_hrev56578_93-1 to r1~beta4_hrev56578_95-1 from repository Haiku
    upgrade package makefile_engine-r1~beta4_hrev56578_93-1 to r1~beta4_hrev56578_95-1 from repository Haiku
    upgrade package haiku_loader-r1~beta4_hrev56578_93-1 to r1~beta4_hrev56578_95-1 from repository Haiku
    upgrade package haiku_datatranslators-r1~beta4_hrev56578_93-1 to r1~beta4_hrev56578_95-1 from repository Haiku
    upgrade package haiku_extras-r1~beta4_hrev56578_93-1 to r1~beta4_hrev56578_95-1 from repository Haiku
    upgrade package userland_fs-r1~beta4_hrev56578_93-1 to r1~beta4_hrev56578_95-1 from repository Haiku
    upgrade package haiku_devel-r1~beta4_hrev56578_93-1 to r1~beta4_hrev56578_95-1 from repository Haiku
    upgrade package webpositive-r1~beta4_hrev56578_93-1 to r1~beta4_hrev56578_95-1 from repository Haiku


I think this thread of post may be closed - as affected issue was finally fixed.

So this way : no more discussions needed about it.

2 Likes