SUMMARY I was downloading a bunch of files in Firefox - about 600 files at a rate of about one file every three seconds. These were simple text files, almost all around 20 KB (and none larger than 25 KB). So not an especially fast download rate, and not especially large files. (These files were all going in ~/Downloads. I have Baloo completely disabled.) This resulted in a very small CPU increase in Firefox itself, but when trying to figure out why my fans went crazy, I noticed that kactivitymanagerd had a core at 100% for the duration of the download (~30 minutes). STEPS TO REPRODUCE 1. Download a bunch of small text files in Firefox. DEBUGGING I didn't manage to get a flame graph, but did some quick debugging during the download process with `strace`. Things I noticed: * The following syscall occurred 18580 times over the course of a 1-2 minute `strace`: newfstatat(AT_FDCWD, "/etc/localtime", {st_mode=S_IFREG|0644, st_size=3552, ...}, 0) = 0 * The most significant activity seems centered around `~/.local/share/recently-used.xbel`. There are about 1000 bookmarks in this file, and `kactivitymanagerd` is reading from it off and on throughout the entire `strace`. Since it's an XML file I assume there is probably a considerable amount of parsing being done on the file that doesn't show up in the `strace`. It's not clear to me what `kactivitymanagerd` is doing with the data from this file. * Most of the rest of the syscalls are related to XDG paths, like `~/.local/share/applications`. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.27.5 KDE Frameworks Version: 5.106.0 Qt Version: 5.15.9 Kernel Version: 6.3.2-arch1-1 (64-bit) Graphics Platform: X11
Hi Adam! Sorry we were not able to get to this yet. Can you still reproduce the issue in Plasma 6.3.4 or later? Thanks a lot!
(In reply to Nate Graham from comment #1) > Hi Adam! Sorry we were not able to get to this yet. Can you still reproduce > the issue in Plasma 6.3.4 or later? Thanks a lot! I think this needs a little more testing to confirm some specifics of the issue (I don't remember how / why I downloaded so many files), but I was able to reproduce it in principle - even saving a single file causes kactivitymanagerd to noticeably spike. However, I think this issue might be caused by the file picker. When I click save, it's appears to be the *portal* that is updating ~/.local/share/recently-used.xbel, and kactivitymanagerd then reads / parses this file, and that's the CPU activity I see. (Both the default Firefox file picker and the KDE xdg-desktop-portal one seem to trigger this.) The issue doesn't seem to be the result of the download itself - I see the CPU activity even if the file fails to download. I tried the most obvious thing I could think of, which was to disable the "recent files / remember opened documents" option in system settings. However, I ran into an issue that was rather disturbing - neither disabling the option nor *explicitly* clearing the history ("forget everything") deleted the contents of the file recently-used.xbel nor did they affect the behavior of this issue. Am I misunderstanding what these settings are supposed to do, or is this a bug that I need to report separately? Manually deleting the recently-used.xbel file knocked the CPU time used by kactivitymanagerd down to almost nothing, indicating that parsing this file (which could get very large if history pruning is not enabled or is broken) is probably responsible for the issue.
> However, I think this issue might be caused by the file picker. Sorry, I didn't word this part particularly well. The ultimate cause of the issue isn't the file picker, it is (or appears to be) kactivitymanagerd taking a long time to parse a large file of recent documents. The file picker is the mechanism by which the browser causes this to happen, since clicking save in the file picker updates the recent documents.
I'm changing the title and moving this to reflect the generic nature of what I take the issue to be. Adding two "see also" links. There is an existing confirmed report that *adding* an entry to the recently used list adds ~100 ms latency to the application calling the KRecentDocument function. There's another confirmed report related to the privacy issue I mentioned in a comment above: KDE adds items to recently-used even when this is disabled in the settings. I think *this* issue is about kactivitymanagerd using inotify on recently-used.xbel and parsing it whenever the file is updated. This doesn't add latency to operations like the other issue, but it can consume even more CPU time (claiming a full core in this case) because it seems to reparse the whole file whenever it changes.
(In reply to Adam Fontenot from comment #4) > I'm changing the title and moving this to reflect the generic nature of what > I take the issue to be. > > Adding two "see also" links. There is an existing confirmed report that > *adding* an entry to the recently used list adds ~100 ms latency to the > application calling the KRecentDocument function. There's another confirmed > report related to the privacy issue I mentioned in a comment above: KDE adds > items to recently-used even when this is disabled in the settings. > > I think *this* issue is about kactivitymanagerd using inotify on > recently-used.xbel and parsing it whenever the file is updated. This doesn't > add latency to operations like the other issue, but it can consume even more > CPU time (claiming a full core in this case) because it seems to reparse the > whole file whenever it changes. Unfortunately to do its, it has too, but it maintains a 500 files limit in the file to cap the time it spends in parsing. We could simply disable the inotify watch or the parsing when the history is turned off indeed. But an optimization already would be to throttle the inotify events: limit them to 1 every 10ms for instance would be a sufficient optimization already. https://bugs.kde.org/show_bug.cgi?id=468461 was the opposite case: when opening an application, it has been largely mitigated.
(In reply to Méven from comment #5) > (In reply to Adam Fontenot from comment #4) > > I'm changing the title and moving this to reflect the generic nature of what > > I take the issue to be. > > > > Adding two "see also" links. There is an existing confirmed report that > > *adding* an entry to the recently used list adds ~100 ms latency to the > > application calling the KRecentDocument function. There's another confirmed > > report related to the privacy issue I mentioned in a comment above: KDE adds > > items to recently-used even when this is disabled in the settings. > > > > I think *this* issue is about kactivitymanagerd using inotify on > > recently-used.xbel and parsing it whenever the file is updated. This doesn't > > add latency to operations like the other issue, but it can consume even more > > CPU time (claiming a full core in this case) because it seems to reparse the > > whole file whenever it changes. > > Unfortunately to do its, it has too, but it maintains a 500 files limit in > the file to cap the time it spends in parsing. > > We could simply disable the inotify watch or the parsing when the history is > turned off indeed. > But an optimization already would be to throttle the inotify events: limit > them to 1 every 10ms for instance would be a sufficient optimization already. Is the 500 file limit new? When I reported this back in 2023, I noted at the time that the file had about 1000 entries. As to throttling, is there a way I could benchmark the performance? Back in 2023 when this issue first came up for me, it appears that downloading a single file every few seconds was enough to peg the core to 100%, so limiting it to 1 every 10 ms wouldn't even be close to enough. Of course this was with 1000 files and maybe the performance has been improved since then. Does kactivitymanagerd ignore inotify events triggered while it is currently processing due to a previous event? If not then one issue here (which might explain the consistent 100% CPU usage) would be that the work stacks up during periods when many files are added, and kactivitymanagerd doesn't catch up until whatever is adding recent files has finished doing so.
(In reply to Adam Fontenot from comment #2) > (In reply to Nate Graham from comment #1) > > Hi Adam! Sorry we were not able to get to this yet. Can you still reproduce > > the issue in Plasma 6.3.4 or later? Thanks a lot! > > even saving a single file causes > kactivitymanagerd to noticeably spike. I had the exact same issue and was pulling out my hair wondering why this was happening in Plasma 6.3.x. I've fixed this (see below) and have no issues in 6.4.4. > However, I think this issue might be caused by the file picker. When I click > save, it's appears to be the *portal* that is updating > ~/.local/share/recently-used.xbel, and kactivitymanagerd then reads / parses > this file, and that's the CPU activity I see. (Both the default Firefox file > picker and the KDE xdg-desktop-portal one seem to trigger this.) The issue > doesn't seem to be the result of the download itself - I see the CPU > activity even if the file fails to download. It even happens when you simply *run* a program, like Spectacle, and even from the commandline, which is something I do a lot. Like a lot. > I tried the most obvious thing I could think of, which was to disable the > "recent files / remember opened documents" option in system settings. > However, I ran into an issue that was rather disturbing - neither disabling > the option nor *explicitly* clearing the history ("forget everything") > deleted the contents of the file recently-used.xbel nor did they affect the > behavior of this issue. Am I misunderstanding what these settings are > supposed to do, or is this a bug that I need to report separately? I tried that too, and was dismayed that neither solved the issue. It wasn't until I found this bug report that I was able to learn that my ~/.local/share/recently-used.xbel file was 11MB(!) and that was the cause of the slowdown, processing that. I do a lot of automated work and even with the Settings -> Recent Files -> Keep history -> For 1 month, the file was 11MB of XML data. > Manually deleting the recently-used.xbel file knocked the CPU time used by > kactivitymanagerd down to almost nothing, indicating that parsing this file > (which could get very large if history pruning is not enabled or is broken) > is probably responsible for the issue. That worked for me. By renaming recently-used.xbel to .old and letting the file start fresh, the problem instantly went away. No more kactivitymanagerd pegging a CPU core at 100% and turning on my fans. It would be great to have a safeguard in place that checks for an overly large ~/.local/share/recently-used.xbel and if so, trims it down or deletes it, as it's useless if it's in the giant 11MB range that I found mine to be. Or at least fix the System Settings -> Recent Files -> Clear History -> Forget Everything functionality. When I invoke that, it doesn't eliminate recently-used.xbel. Nor changing the "Remember opened documents" setting to "Do not remember". Curiously, under Plasma 6.4.4, I have Keep history set to 1 month, yet it's keeping the recently-used.xbel file small at 192KB and only saving 2 days worth of entries. So something is working right, but I had to essentially delete recently-used.xbel first before it could right itself.
*** Bug 484837 has been marked as a duplicate of this bug. ***
I want to add, that I still experience 100 % CPU from kactivitymanagerd (kactivitymanagerd-6.4.4-1.fc42.x86_64) after moving away ~/.local/share/recently-used.xbel and doing systemctl --user restart plasma-kactivitymanagerd.service. I originally posted some more info in https://bugs.kde.org/show_bug.cgi?id=484837#c7 and I see the same ltrace now: $ ltrace -p $(pidof kactivitymanagerd) ... _ZN14QReadWriteLock14tryLockForReadE14QDeadlineTimer(0x5584b046b568, 0x7fffffffffffffff, 0x100000000, 0x7fff94386a90) = 1 _ZN14QReadWriteLock6unlockEv(0x5584b046b568, 0x7fffffffffffffff, 0x5584b0473660, 0x5584b04800c0) = 1 _ZN14QReadWriteLock14tryLockForReadE14QDeadlineTimer(0x5584b046b568, 0x7fffffffffffffff, 0x100000000, 0x7fff94386a90) = 1 _ZN14QReadWriteLock6unlockEv(0x5584b046b568, 0x7fffffffffffffff, 0x5584b0473660, 0x5584b04800c0) = 1 _ZN14QReadWriteLock14tryLockForReadE14QDeadlineTimer(0x5584b046b568, 0x7fffffffffffffff, 0x100000000, 0x7fff94386a90) = 1 _ZN14QReadWriteLock6unlockEv(0x5584b046b568, 0x7fffffffffffffff, 0x5584b0473660, 0x5584b04800c0) = 1 So I'm not convinced this error is related to a big ~/.local/share/recently-used.xbel alone. Is there anything more I can try? Also, right now, I see high cpu only on my Default activity - if I switch to another activity, the cpu usage goes down immediately. If I switch back to Default, it goes up again.
PDF files don't open, open slowly, or bog down computer, (kactivitymanagerd uses a lot of CPU when opening a file) Whenever I open PDF files in "Documents", kactivitymanagerd uses 100% of a CPU core for a long time. Plasma v5.27.12 Reportedly, this has something to do with recently-used.xbel or RecentDocuments (both in ~/.local/share/). I deleted both, restarted kactivitymanagerd and PDF files now open responsively. systemctl --user restart plasma-kactivitymanagerd.service systemctl --user status plasma-kactivitymanagerd.service https://www.reddit.com/r/kde/comments/1hwqecx/kactivitymanagerd_uses_a_lot_of_cpu_when_opening/
(In reply to MartinG from comment #9) > I want to add, that I still experience 100 % CPU from kactivitymanagerd > (kactivitymanagerd-6.4.4-1.fc42.x86_64) after moving away > ~/.local/share/recently-used.xbel and doing systemctl --user restart > plasma-kactivitymanagerd.service. I originally posted some more info in > https://bugs.kde.org/show_bug.cgi?id=484837#c7 and I see the same ltrace now: > > $ ltrace -p $(pidof kactivitymanagerd) > ... > _ZN14QReadWriteLock14tryLockForReadE14QDeadlineTimer(0x5584b046b568, > 0x7fffffffffffffff, 0x100000000, 0x7fff94386a90) > = 1 > _ZN14QReadWriteLock6unlockEv(0x5584b046b568, 0x7fffffffffffffff, > 0x5584b0473660, 0x5584b04800c0) > = 1 > _ZN14QReadWriteLock14tryLockForReadE14QDeadlineTimer(0x5584b046b568, > 0x7fffffffffffffff, 0x100000000, 0x7fff94386a90) > = 1 > _ZN14QReadWriteLock6unlockEv(0x5584b046b568, 0x7fffffffffffffff, > 0x5584b0473660, 0x5584b04800c0) > = 1 > _ZN14QReadWriteLock14tryLockForReadE14QDeadlineTimer(0x5584b046b568, > 0x7fffffffffffffff, 0x100000000, 0x7fff94386a90) > = 1 > _ZN14QReadWriteLock6unlockEv(0x5584b046b568, 0x7fffffffffffffff, > 0x5584b0473660, 0x5584b04800c0) > = 1 > This shed some light. Another thing you could do to help debug is to use perf, with for instance hotspot https://github.com/KDAB/hotspot A flamegraph showing where the kactivitymanagerd processus is spending its time during the CPU spike in particular. > > So I'm not convinced this error is related to a big > ~/.local/share/recently-used.xbel alone. Is there anything more I can try? > Also, right now, I see high cpu only on my Default activity - if I switch to > another activity, the cpu usage goes down immediately. If I switch back to > Default, it goes up again. A lock issue could be at hand, lock and unlocking in quick succession could cause this 100% CPU spike. Which lock is concerned.