https://bugs.kde.org/show_bug.cgi?id=400704
--- Comment #50 from tagwer...@innerjoin.org --- (In reply to postix from comment #48) > You can see that Baloo stucks most of the time in > `Baloo::PositionDB::get(QByteArray const&)` and > `Baloo::PostingDB::get(QByteArray const&)` called from > `Baloo::WriteTransaction::commit()` A lot has changed since this bug was originally reported: an understanding of the effects of changing device numbers, as occurs with BTRFS, and the systemd contraints on RAM usage. I would say it's worth opening a new bug, including details of the system, and we can try to pin down what's happening. The first think I'd want to check is whether the index holds multiple records for a file, you can check with "baloosearch -i ...." (or baloosearch6). If you get multiple hits for one file than the index is holding the unnecessary info and having to read and rewrite the records, which are far, far larger records, whenever anything changes. I suspect you would quite easily see this as CPU load - as far as I remember Baloo sorts the entries within the record. Could be loads of work. -- You are receiving this mail because: You are watching all bug changes.
