IMHO, as a daily user (yes, Haiku is my main OS),
the most important issue is the memory leaks over time.
(System has 8GB of RAM)
These are the stats with no programs running:
After 1 week, 6 days, 20 hours of uptime:
Memory usage: 6.16GB
Buffer memory usage: 291.8MB
Swap 1.39GB
After reboot:
Memory usage: 619.46MB
Buffer memory usage: 641.81MB
Swap: 0
Are you running nightly?
Nope, regular
Whatâs âBuffer memory usageâ? Thatâs not a category I know.
There was a slow memory leak caused by ping that was fixed in the nightly builds, other than this I donât know of any memory leaks as fast as what you show here. I just checked one of the package builders: it has an uptime of 78 days, and currently has ~7GB free and most of the remaining GB is used in caches, which is expected.
So, what does your usage pattern look like? Can you try and narrow down what applications cause the leak?
Buffer memory usage is what activity monitor calls it,
Total usage, buffer usage and swap.
I use falcon(90%+), qmplay and on occasion the video and audio players
I have tried to just reboot, leave it on the desktop with only activity monitor running, and memory usage creeps up by about 1MB per minute without interaction
Maybe it is related to graphics somehow, since most of programs listed use moving graphics(including activity monitor), and Im guessing the package builder you mentioned isnt heavy on the graphics
You must be using a language other than English then, because the original term here is âCached memoryâ.
Is it connected to the network? Any other programs open in the background? Is it one of the default open applications thatâs using more and more (check ProcessController memory usage statistics), and not the kernel?
I started running some test with my newly bought system, fresh install of beta5,
using slayer instead of activity monitor for more detailed info, taking screenshots every now and then with flameshot, but otherwise not using the system.
Will report my findings tomorrow, I need a good sample size first,
and then analyze and calculate the data.
Ok, I spent the last 12 hours doing a few (4 different scenarios),
These are my findings:
I was wrong about it being related to graphically âintenseâ applications,
it must be in the base system somehow.
The weird thing is that none of the applications increase in memory usage
as fast as the usage goes up, it doesnt seem to be tied to network, graphics or audio,
itâs just inherent in the system somehow?
As the final test, I restarted the system, started flameshot, opened activity monitor,
took a screenshot, waited 5 minutes, took another screenshot,
calculated the increase in memory usage and it was quite a bit worse than I thought,
I previously said 1MB per minute, but it turned out to be 7.382MB per minute,
with no matching application growing that much in that time.
Iâm befuddled, it isnt tied to a program, or user activity that can explain the source.
If you want me to run more specific test, I have 3 Haiku machines to play with,
so running long term tests is fine with me, and I have the free time to do it.
Im pondering looking through the source code, but I dont know where to begin searching,
maybe a dev can point me in the right direction that is more familiar with the source?
Does it happen on all 3 of your machines, or only one of them?
Does it happen when they are disconnected from the network? (unplug cables even if you can, or just donât connect to WiFi after boot if wireless)
Could it be Flameshot?
waddlesplash:
All machines display this (1 laptop, core2 duo, my old main machine, Opteron 8 core w/ radeon graphics card, and the newest Core i5 system using builtin graphics⌠So extremely diverse hardware)
I will reboot without the LAN connected and see what happens during the next 6 hours.
EDIT: I noticed I accidentally didnt connect the LAN cable last night, so this is without being connected
Coldfirex:
No, I rebooted the system before I went to bed (no flameshot running), started activity monitor and just left it running. It was below 600Mb last night, now its up to 1.48GB used,
while I was sleeping.
Iâm git cloning the source now, I have a hunch it might not actually be allocating the memory, since no process counter accounts for it, it might be a problem with the system wide counter itself somehow, havent used C++ for 20 years so might take some time to get into the groove again
It probably is just the kernel itself allocating the memory, then. I donât think it would be an error in the counters, theyâre very straightforward. If the counter is increasing, then something really is using that memory.
Does a fully stock install have this problem? Maybe itâs related to some add-on or application you have installed thatâs running in the background? Considering other users donât see this but all of your hardware does, even when not connected to the network, that sounds like some application youâve installed on all of them is indirectly causing the problem.
Tracking kernel memory leaks tends to be pretty difficult. Isolating the cause is usually the first and most critical step in solving them; reviewing the source code wonât help without this (thereâs millions of lines of it, after all.)
At least on Haiku R1b5 (hrev58674) x64, this is not the issueâŚ
Hour check after a good daily drive stress exercise⌠3%-4% memory usage resumed after major use. No major leak detected.
So, you can do this as a snapshot:
This will help you and others track applications, resources, and hardware drivers.
.
Simple test on my end (but virtualized). Fresh boot with just activity monitor.
âUsed memoryâ increased about 1mb per hour for about 4 hours.
After 8 hours âUsed Memoryâ is about 19mb higher than the starting point.
EDIT:
After 24 hours 52mb higher than starting point.
Closing Activity Monitor and then reopening it, still shows the system at the increased usage. Nothing within in ProcessController shows memory size that equate to this outside of the kernel_team.
Thanks for the input guys, I can only arrive at one conclusion then, Activitymonitor is a RAM hog somehow? (Might be a problem if you run it as a replicant?)
I will test this more indepth.
Still, thats not something I usually run more than occasionally ( < once a week ), so there still is something not releasing memory correctly when a program is closed/crashes (falkon does a few times a day, heavy youtube use though)
The resulting logfile from the commands you (cocobean) suggested is 2728 lines, Ill have to find somewhere to upload it, Im guessing its frowned upon to upload that much text directly to the forum
Some of this may be typical âchurnâ, and it may get released when the system actually has memory pressure. Or it could not be, and indeed this is also a leak.
The first place to go looking for kernel memory leaks (especially one thatâs only 1MB per hour) is to compare the output of the KDL slabs command over periods of time.