SUMMARY Since plasma 5.16.3 there is a problem with plasmashell memory consumption. It takes about 2.1GB of RAM just after start. Remember me, was it less than 200MB before? :-o I have nothing special. Two panels. The basic (hiding) panel contains few icons, temperature monitor (CPU and GPU temperature monitoring), standard weather widget and kdeconnect. The additional hiding pannel contains network monitor only. There are not any other widgets or icons on the destop (just black background), I don't use features like activities or semantic desktop (or anyhow else you call it). KWIN compositing is turned on, but only few. I'm using this same configuration for years. The interesting is that if I don't start my usual applications and the OOM killer keeps the plasmashell running, the memory consumption gets back to normal (about 150MB) after some while (about 10 minutes). It is not preceded by any special CPU activity I have laptop with 8GB of memory but 3GB are preserved for tmpfs (ramdisks in order to spare writting cycles for SSD). The swap memory is completely turned off. Private memory 2011600 KB [heap] 5320 KB /memfd:JSGCHeap:/usr/lib/libQt5Qml.so.5 (deleted) 4396 KB /usr/lib/libLLVM-8.so 2112 KB /usr/lib/libtelepathy-qt5.so.0.0.9.7 1768 KB ~/.cache/plasma_theme_oxygen_v5.60.0.kcache Shared memory 33644 KB /usr/lib/libLLVM-8.so 6128 KB /usr/lib/dri/radeonsi_dri.so 5144 KB /usr/lib/libQt5Gui.so.5.13.0 4316 KB /usr/lib/libQt5Core.so.5.13.0 3884 KB /usr/lib/libQt5Qml.so.5.13.0 Totals Pixmap 34604 KB (Might be stored in the graphics card's memory) Private 2056140 KB (= 25624 KB clean + 2030516 KB dirty) Shared 133268 KB (= 133176 KB clean + 92 KB dirty) Rss 2189408 KB (= Private + Shared) Pss 2081083 KB (= Private + Shared/Number of Processes) Swap 0 KB STEPS TO REPRODUCE 1. Just start KDE and wait until plasma shell is fully loaded OBSERVED RESULT Plasmashell is killed by OOM killer when running my applications as usual. If not, the memory consumption gets back to normal after cca 10 minutes of running EXPECTED RESULT Plasmashell starts and keeps running consuming much less memory (cca. 150MB of RAM) SOFTWARE/OS VERSIONS Linux/KDE Plasma: Archlinux KDE Plasma Version: 5.16.3 KDE Frameworks Version: 5.60.0 Qt Version: 5.13.0 ADDITIONAL INFORMATION
Please can you run QSG_INFO=1 plasmashell and paste the output. Please move your ~/.config/plasma-org.kde.plasma.desktop-appletsrc and see if that makes a difference. Finally can you run kcmshell5 qtquicksettings and select the software renderer and see if that makes a difference.
Created attachment 121737 [details] plasmashell console output
(With the current configuration): Running with the software renderer doesn't make any difference. Even with compositing completely turned off. After the "configuration reset", plasmashell starts immediately with the "usual" size in memory, but... Today I've noticed that just after boot, the plasmashell was running with the "usual" portion of memory. But, it was killed by OOM killer after 22 minutes of uptime. If I remember well, the progress was the same yesterday in the morning. The first killing occurred after some amount of time, but each (working) day, I'm using my system exactly the same way. So, I'm going to try to configure plasma again, as it was before the configuration reset and to watch its behaviour carefully. For now, thanks for Your interest and I'm sorry for my bad English. BTW: what does the "Tokenizer Warning: 8Bit character" message mean? I mean, how to distinguish, from where it comes from? I've noticed it before within restarting akonadi (when I was fighting with akonadi problems). I'm using UTF-8 within the whole system
It seems that the problem won't appear until I enable "PIM events plugin" in settings of digital clock applet. When I enable "PIM events plugin" option, there are missing calendars to choose at all in the side "tab", but at the moment, akonadiserver, mysql and akonadi_imap_resource_3(?!) start to exhaust CPU for a lot of minutes. And RAM allocated for plasmashell starts to grow slowly (cca 200kB per second?). And then, let's say, after cca 10minutes (probably just when akonadi_indexing_agent starts) the consumed memory skyrokets up to 2GB... If there is enough of free memory and OOM killer leaves plasmashell running, then CALDAV calendar events finally appear in the digital clock calendar, and akonadi stops draining CPU. This akonadi behaviour is new too.
Ok, please file a bug with this information to akonadi. I don't think we can do much from the plasma side.
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!
Moving to Akonadi as suggested in comment 5.
Thank you for reporting this crash in KDE software. As it has been a while since this issue was reported, can we please ask you to see if you can reproduce the crash with a recent software version? If you can reproduce the issue, please change the status to "CONFIRMED" when replying. Thank you!
Oh, I'm sorry. I've tried to enable the digital clock PIM plugin few weeks ago, and it didn't crash. PIM started immediately, with working kalendar and containing valid PIM informations. There is not any CPU or (noticeable) memory impact on plasmashell. There is nice new feature like dots as events by each day. At least dots by the first visible day (of each month page) have invalid color, but damn it! Digital clock caPIM events work again within daily using! But I don't know, when it was fixed. The last unsuccessful try before, it was probably last year. I think, this ticket should be closed. Plasma: 5.25.5 Frameworks: 5.98.0