Bug 440802 - High ram consumption (1GB) when idle
Summary: High ram consumption (1GB) when idle
Status: RESOLVED WORKSFORME
Alias: None
Product: frameworks-baloo
Classification: Frameworks and Libraries
Component: Baloo File Daemon (show other bugs)
Version: 5.84.0
Platform: Arch Linux Linux
: NOR normal
Target Milestone: ---
Assignee: baloo-bugs-null
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-08-09 18:14 UTC by irchaika
Modified: 2021-09-23 04:36 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description irchaika 2021-08-09 18:14:55 UTC
SUMMARY
baloo_file's process is taking 950MB of ram from a computer with 8GB of ram. Sometimes baloo_file_extract flashes for a short time, taking another 60M. There's no cpu consumption associated with the process.

STEPS TO REPRODUCE
1. Have baloo indexer enabled (it's been enabled for months).
2. Have it be idle according to the configuration module, "idle, 100% completed"

OBSERVED RESULT
It consumes nearly a gigabyte of ram despite being idle, the problem persists across reboots (though I haven't checked how long it takes for the process to reappear and take that amount of ram)

EXPECTED RESULT
For it to not take nearly as much ram

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: 5.13.7
(available in About System)
KDE Plasma Version: 5.22.4
KDE Frameworks Version: 5.84.0
Qt Version: 5.15.2
Comment 1 tagwerk19 2021-08-11 15:05:08 UTC
(In reply to irchaika from comment #0)
> It consumes nearly a gigabyte of ram despite being idle, the problem
> persists across reboots (though I haven't checked how long it takes for the
> process to reappear and take that amount of ram)
I've seen this when I've tried indexing many files (2 million), that gives a big index. Each time you log on, baloo cross-checks your files on disc against the files in the index to see if anything has changed. In this case baloo is just reading most of the information, it gets pulled off disc and stays in RAM in case it is needed again. If "balooctl status" says idle, then baloo is not actively using the memory,

I would expect that as soon as another process needs memory, the amount used by baloo will drop.
Comment 2 tagwerk19 2021-08-20 08:20:43 UTC
Anything extra?

If baloo_file is keeping hold of memory, it would be interesting to know what it is being asked to do.
Comment 3 irchaika 2021-08-24 05:15:18 UTC
Is there any way to manually trigger a situation that'd make baloo return the memory? something that can be used reliably without having to worry about swapping or triggering the kernel oom
Comment 4 tagwerk19 2021-08-24 06:31:04 UTC
(In reply to irchaika from comment #3)
> Is there any way to manually trigger a situation that'd make baloo return
> the memory? 
Might be worth having a look at iotop to see if it is writing to disc...

What I normally see (and hope is the case here), is that baloo_file has pulled the pages of the memory mapped file into memory as part of the "have I indexed this?", "have the modified dates changed?" initial scan.

If nothing's changed these pages are "clean" and don't need to be written back to disc, they just get quietly forgotten when something else needs the space. It's the same as disc cache when you haven't edited a file...

If something's happened that means that baloo_file needs to update its basic info, then the changes will be gathered together and written back in a big transaction. We'd need to find out what that change was, but from what you say, the baloo_file_extractor is not working hard so baloo is not having to reindex a lot of file content. There's a chance that baloo is trying to catch up after it's discovered you've deleted a large number of files and it removing the entries in the index.

"balooctl indexSize" will tell you how big your index is, both as how much space is taken on disc and real data...
Comment 5 Bug Janitor Service 2021-09-08 04:35:42 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 6 Bug Janitor Service 2021-09-23 04:36:04 UTC
This bug has been in NEEDSINFO status with no change for at least
30 days. The bug is now closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!