| Summary: | Running akonadi servers easily doubles or triples VRAM usage | ||
|---|---|---|---|
| Product: | [Frameworks and Libraries] Akonadi | Reporter: | Kai Krakow <kai> |
| Component: | general | Assignee: | kdepim bugs <kdepim-bugs> |
| Status: | CONFIRMED --- | ||
| Severity: | normal | CC: | asturm, carl |
| Priority: | NOR | ||
| Version: | 5.23.0 | ||
| Target Milestone: | --- | ||
| Platform: | Gentoo Packages | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Kai Krakow
2023-05-02 17:43:04 UTC
BTW: Running "kcmshell5 qtquicksettings" and forcing software rendering for plasma completely eliminates the issue (with Xorg staying really low on VRAM) but then plasma loudly complains about non-optimal rendering settings and I fear this can even reduce game performance if an application renders in parallel to a game (as can be observed when forcing software rendering for Discord which completely degrades GPU performance while gaming). I investigated yesterday the memory usage of akonadi and the issue is that each akonadi resources and agents create a connection with X or Wayland which results in a lot of memory usage. I have a simple fix for that https://invent.kde.org/pim/akonadi/-/merge_requests/139 but that require first making sure that each resources and agents don't actually need that connection to open a dialog or a message box and finish porting the config dialogs to a new api. Which will probably take some time. (help is welcome) Thanks for investigating. I think this example shows that KDE/Plasma should treat VRAM as a valuable resource, and it affects a lot of other KDE background processes, too. So maybe creating some infrastructure to have one single process display dialogues for background processes may be the way forward. But I understand that this is a big change. As a less intrusive interims solution, Akonadi agent and resource processes could be forced to use Qt software rendering only. It probably won't hurt too much because most of these processes only open simple dialogues, and usually probably only in the event of errors or warnings, not as part of working normally. I found that forcing Qt software rendering for the full desktop to eliminate VRAM ballooning but, as already mentioned, I'm not sure how badly it will affect desktop performance, especially if desktops apps need to render in parallel to a game. Also, it somehow prevents window previews on the taskbar to work so it has a visible impact on user experience. But it may be acceptable for Akonadi dialogues for the time until this is fixed. I found no way to force software rendering only for processes launched by Akonadi, it should be as easy as injecting an environment variable into the launcher but I don't know how or where to do that. There's `/usr/share/dbus-1/services/org.freedesktop.Akonadi.Control.service` but I'm not sure if this is the right place for trying to inject environment variables, or if that is the launcher of the main process at all... |