SUMMARY When a heavy process is running that utilizes most of the CPU and IO resources (e.g. Chromium compilation), plasma-systemmonitor's UI becomes completely unusable (0.2 FPS), and KWin reports is as “not responding”. At the same time, I am able to use Konsole, Dolphin and Firefox, and their UI is perfectly fine. Normally, I do not have high performance expectations for QML-based software, but since this is now the only process manager available in Plasma, it has to be able to work under demanding conditions. This was not a problem in Plasma 5 where I could always rely on the QWidgets-based process list available through Ctrl-Esc. STEPS TO REPRODUCE 1. Start a long build process that automatically utilizes all available resources (e.g. through ninja or cargo). 2. Launch the new System Monitor. 3. Attempt to kill processes used for the build. OBSERVED RESULT Unable to perform meaningful user input. EXPECTED RESULT The UI is maybe a bit slow, but usable. SOFTWARE/OS VERSIONS Operating System: openSUSE Tumbleweed 20231226 KDE Plasma Version: 5.91.90 KDE Frameworks Version: 5.248.0 Qt Version: 6.6.1 Kernel Version: 6.6.7-1-default (64-bit) Graphics Platform: Wayland Processors: 32 × Intel® Core™ i9-14900K Memory: 62.5 GiB of RAM Graphics Processor: NVIDIA GeForce RTX 4070/PCIe/SSE2 ADDITIONAL INFORMATION
The system hangs tightly, there is no response to the mouse and keyboard , i used nouveau driver Operating System: KDE neon 6.0 KDE Plasma Version: 6.0.3 KDE Frameworks Version: 6.0.0 Qt Version: 6.6.2 Kernel Version: 6.5.0-26-lowlatency (64-bit) Graphics Platform: Wayland Processors: 2 × Intel® Core™2 Duo CPU E4700 @ 2.60GHz Memory: 2.8 ГіБ of RAM Graphics Processor: NVA8
The process list specifically gets completely unresponsive even with a CPU load of 20-30%.
It is easy to reproduce on my 14 core (20 thread) system when the "Process" view is open. Monitor chews up an entire CPU core and is entirely unresponsive. Attaching `perf` and checking the results we find: 5.35% plasma-systemmo libQt6Core.so.6.7.2 [.] 0x00000000002e0525 5.34% plasma-systemmo libQt6Core.so.6.7.2 [.] 0x00000000002e0552 4.68% Thread (pooled) libc.so.6 [.] malloc 4.28% plasma-systemmo libQt6Core.so.6.7.2 [.] QObjectPrivate::maybeSignalConnected 4.09% plasma-systemmo libQt6Core.so.6.7.2 [.] 0x00000000002e0520 4.01% plasma-systemmo libQt6Core.so.6.7.2 [.] 0x00000000002e0465 1.40% plasma-systemmo libQt6Core.so.6.7.2 [.] 0x00000000002e05e3 1.21% Thread (pooled) libc.so.6 [.] cfree 0.96% Thread (pooled) libQt6Core.so.6.7.2 [.] QCoreApplication::postEvent 0.92% Thread (pooled) libc.so.6 [.] __tfind 0.87% Thread (pooled) libglib-2.0.so.0.7800.6 [.] g_main_context_wakeup 0.74% Thread (pooled) libQt6Core.so.6.7.2 [.] QObject::~QObject Another item I found when digging through the call graph is QAbstractItemModel::dataChange. This suggests it is UI related.
*** Bug 493561 has been marked as a duplicate of this bug. ***
*** Bug 487223 has been marked as a duplicate of this bug. ***
*** Bug 487136 has been marked as a duplicate of this bug. ***
Update: this now consistently happens even when the PC is idle, which to me suggests that System Monitor queries some data in a blocking manner, and it takes longer then expected (on some hardware?). I switched to using third-party monitors for now.
This is how it looks after three days of not restarting KDE system monitor: https://youtu.be/SV8-E0eZ004 This is configured to update every second. It gets close to this bad after a couple hours, but then keeps getting worse. It also uses up an entire CPU core all the time, so to get any quiet at night, I have to close it in the evening, which is not great for debugging freezes.
For me, it's exactly like that but seconds after launch…
For no particular reason, I kept the process open after I made that video and now it updates about once per 13 seconds, after 11 days of uptime, while in the video, it was updating every 5-6 seconds after 3 days of uptime. Seems like the increase slows down, so whatever causes it probably accumulates as quickly as it updates. That seems to point to the cause probably being in some code that gets executed every time the view updates.
Does it get any better if, in this situation, you switch to the History page and then back to the Processes page?
(In reply to Nate Graham from comment #11) > Does it get any better if, in this situation, you switch to the History page > and then back to the Processes page? I have none of the default pages anymore, but yes, it seems to get better after switching pages. This is after accumulating lag for "just" 1½ days, so less obvious, but seems to be the case.
It helps in the sense that it's the only default page not affected by the slowdown. “Overview” and “Apps” suffer the same issue, presumably because they also contain a process list. Just seconds after I return from “History” to “Processes”, the lags return, too — I guess the page loading mechanism is the same on application launch and on page switch.
Thanks!
Are you able to reproduce the same issues with current git master? A lot of performance work has been done recently, and I can't reproduce this issue when I do a clean build of KWin to peg all 16 cores at 100% and then launch the app.
Unfortunately, I won't be able to build from master on my machine — there's some kernel or firmware bug that makes my PC freeze or reboot during any kdesrc-build/kde-builder run. I'll have to wait for the stable release of Plasma 6.3 to verify the fixes.
Nevermind, fixed that, I guess by updating BIOS 😅 I also can't reproduce this issue on a git master build now. But I think I should test on a build with suspected fixes reverted — to confirm it's not some build config difference.
🐛🧹 ⚠️ This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information, then set the bug status to REPORTED. If there is no change for at least 30 days, it will be automatically closed as RESOLVED WORKSFORME. For more information about our bug triaging procedures, please read https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging. Thank you for helping us make KDE software even better for everyone!
This is definitely still happening for me in version 6.2.5-1, which was released 3 days ago. I have now built 6.3.80 via kde-builder and will see if it happens with that. But that doesn't show the process list and I don't want to change its configuration (because it's apparently shared with the main installation), so it will take a while for it to become noticeable that the graphs update slower than 1Hz.
This is definitely fixed in 6.3.80, no lag after a week of running it nonstop. (Afterwards, my laptop froze for unrelated reasons and I had to restart, but one week should be more than enough to confirm.)