https://bugs.kde.org/show_bug.cgi?id=443693
Adam Fontenot <adam.m.fontenot+...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEEDSINFO |REOPENED
Resolution|WAITINGFORINFO |---
--- Comment #5 from Adam Fontenot <adam.m.fontenot+...@gmail.com> ---
(In reply to Nate Graham from comment #4)
> When you click "Pause Indexer", can you run `balooctl status` in a terminal
> window and paste the output? I suspect what might be going on is that the
> indexer itself does in fact get paused, but its running indexing processes
> don't.
I was able to reproduce the exact conditions. Here's a timeline.
1. Start `balooctl monitor` and `htop`.
2. Run `balooctl status`. See Output 1 below.
3. Start compiling a large piece of software that will create many new files in
a directory that is indexed by Baloo. For this test, I was compiling the Arch
Linux package `libreoffice-fresh`.
4. Observe that `baloo_file` becomes active in htop. In the monitor, note that
the status changes to "Indexing new files" or "Indexing modified files". High
CPU use by baloo is observed despite near-100% CPU demand from the compiler.
5. Open System Settings. Baloo settings page is oddly slow to load, but when it
loads it says "Idle". I have noticed that running `balooctl status` will *hang*
for a long time if the indexer is running. Presumably the indexer has briefly
caught up with the compiler?
6. Click "Pause Indexer". Baloo seems indecisive, but after 20 seconds or so
"Suspended" appears in the monitor window.
7. Observe that `baloo_file` continues to run in `htop`, using a large amount
of CPU.
8. Run `balooctl status`. See Output 2 below.
9. Start writing this bug report. As I type this, `baloo_file` has continued to
run. It has grown to over 1.7 GB of resident memory use, and continues to eat a
lot of CPU. For good measure, I am running `balooctl status` again now. It
takes over 50 seconds to complete. The monitor window continues to show
"Suspended" as its last status message. See Output 3 below.
Something that sticks out to me about this last state is that the number of
indexed files is actually *dropping* over time, and despite this, the index
size has ballooned (pun not intended) to an enormous size given the relatively
moderate number of files indexed. I know for sure that this dramatic increase
was the result of this testing, because I was recently forced to delete the
Baloo data directory after seeing this issue.
Nothing I have been able to do (including deleting the build directory entirely
and trying to force baloo to recheck it) has been able to reduce this increased
disk space usage. Every time it happens I am forced to delete Baloo's index and
start over.
I'm including the result of `balooctl indexSize` below, as Output 4. I'm in the
process of trying to write a bug report to cover disk usage problems with
Baloo, as there isn't one at present I don't think. (There's one for i/o
utilization, cpu use, memory consumption, etc.) If there is anything I can
provide to make that bug report better, please let me know. I'd like to avoid
side-tracking this bug with the disk usage problem as it isn't the central
issue here.
Content indexing has been completely disabled throughout this entire process.
Output 1 (status before compiling begins):
Baloo File Indexer is running
Indexer state: Idle
Total files indexed: 270,102
Files waiting for content indexing: 0
Files failed to index: 0
Current size of index is 134.10 MiB
Output 2 (status while compiling continues, and after Baloo is suspended):
Baloo File Indexer is running
Indexer state: Suspended
Total files indexed: 295,546
Files waiting for content indexing: 0
Files failed to index: 0
Current size of index is 182.13 MiB
Output 3 (status after writing this comment, after previously stopping the
build):
Baloo File Indexer is running
Indexer state: Idle
Total files indexed: 283,689
Files waiting for content indexing: 0
Files failed to index: 0
Current size of index is 2.37 GiB
Output 4 (current indexSize):
File Size: 2.37 GiB
Used: 114.48 MiB
PostingDB: 18.00 MiB 15.723 %
PositionDB: 18.85 MiB 16.467 %
DocTerms: 19.36 MiB 16.907 %
DocFilenameTerms: 17.24 MiB 15.061 %
DocXattrTerms: 4.00 KiB 0.003 %
IdTree: 7.27 MiB 6.350 %
IdFileName: 19.51 MiB 17.040 %
DocTime: 12.43 MiB 10.861 %
DocData: 0 B 0.000 %
ContentIndexingDB: 0 B 0.000 %
FailedIdsDB: 0 B 0.000 %
MTimeDB: 1.82 MiB 1.587 %
--
You are receiving this mail because:
You are watching all bug changes.
