Summary: | ksgrd_network_helper uses a lot of CPU on high network load | ||
---|---|---|---|
Product: | [Unmaintained] ksysguard | Reporter: | José JORGE <lists.jjorge> |
Component: | ksysguard | Assignee: | KSysGuard Developers <ksysguard-bugs> |
Status: | RESOLVED UNMAINTAINED | ||
Severity: | normal | CC: | andysem, aspotashev, bugseforuns, burster, d.schroeter, eugene.shalygin+bugzilla.kde, gerbilsoft, iamashwin99, jlp, jose.jmaacc, jplx256, kde, krasi.root, martin.sandsmark, mauromol, maxmustermann1884, nate, r2b2x3+kdebug, rainer, slch000, springzfx, thebitpit, truckerzer0, vityas_official |
Priority: | NOR | ||
Version: | 5.17.90 | ||
Target Milestone: | --- | ||
Platform: | Other | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: | |||
Attachments: |
helper launched with --stats show more than 500 packets per second
high cpu usage while downloading with jdownloader |
Description
José JORGE
2019-11-11 18:42:06 UTC
I can confirm this. I just did a backup over SFTP, ksgrd_network_helper was stuck at 25% CPU during the entire process. I am using KSysGuard 5.17.2 After some testing it seems to me that this is caused by having the columns "Upload" and/or "Download" activated in the list of all processes. I removed these columns and ksgrd_network_helper disappered entirely. I am also using graphs to see the overall network usage, they do not seem to cause any issues. To test this, I openened two instances of KSysGuard, one showing the process list and one showing a graph of the network usage. When trying the wget example you posted, I did not see any issues. (In reply to Jan Przybylak from comment #2) > After some testing it seems to me that this is caused by having the columns > "Upload" and/or "Download" activated in the list of all processes. I removed > these columns and ksgrd_network_helper disappered entirely. YEs, this bug is against the new helper for this two columns. I do experience the same issue, ksgrd_network_helper consumes often 100% of one CPU core. If not, there are still quite high CPU spikes for just monitoring the system with ksysguard. *** Bug 414094 has been marked as a duplicate of this bug. *** This bug still exists in Plasma 5.18.2, can we expect a solution soon? It's pretty annoying to use an entire CPU core for a dumb ksysguard graph... Confirming still an issue on latest packages (right now after pacman -Syu & reboot). And is still resolved by removing the 'Download' & 'Upload' columns in KSysGuard. This is getting more and more ridiculous, now even without the "Download" and "Upload" column ksgrd_network_helper pops up consuming steadily 24%-25% of the CPU... OpenSUSE Tumbleweed Plasma 5.18.3 for what matters... *** Bug 420701 has been marked as a duplicate of this bug. *** Created attachment 128495 [details]
high cpu usage while downloading with jdownloader
On Plasma 5.19 beta I can't reproduce downloading with wget, qBittorrent or ktorrent.
But the high cpu usage occurs when I download with jdownloader even when download and upload columns of ksysguard are disabled.
See the attached screenshot please.
Operating System: Arch Linux
KDE Plasma Version: 5.18.90
KDE Frameworks Version: 5.70.0
Qt Version: 5.15.0 rc2
I posted a patch here: https://phabricator.kde.org/D29808 Instead of using std::regex, use fixed-field parsing. This improves performance significantly on my system. The patch may need some improvements, but it's been working well for me. I have observed that whenever I open chrome, my laptop fan screens, on further investigating I found out that ksgrd_network_helper was using a lot of CPU. The problem usually subsided after closing chrome. After doing some further digging, I found out Killing "Utility: Network Service" from the chrome task manager reduced the CPU fan sound and also CPU usage, ksgrd_network_helper disappears on the ksysguard too. Can someone find out if this works for them? I have observed that whenever I open chrome, my laptop fan screams, on further investigating I found out that ksgrd_network_helper was using a lot of CPU. The problem usually subsided after closing chrome. After doing some further digging, I found out Killing "Utility: Network Service" from the chrome task manager reduced the CPU fan sound and also CPU usage, ksgrd_network_helper disappears on the ksysguard too. Can someone find out if this works for them? (In reply to iamashwin99 from comment #12) > Can someone find out if this works for them? This can't be the solution : the CPU load happens when a lot of small packets are travelling in the network, and ksysguard looks inside them to know which program is using them. The fact that chromium network service generates more packets when running is only a side effect. is there a way to manually disable this check. Im facing a lot of overheating issues (thus battery issues) because of this. Adding David, I'm guessing the reason it always pegs the CPU now is that the new processdatamodel forces it to always be loaded. Looking at perf, there's nothing really standing out, so I'm guessing it's an architectural issue (e. g. nethogs doesn't have this problem). And nethogs has a library interface, so the easiest would probably be to just port it to that. Porting to libnethogs should be fairly trivial (something like http://ix.io/2HHu + delete the rest of the code in ksgrd_network_helper) A possibly relevant merge request was started @ https://invent.kde.org/plasma/ksysguard/-/merge_requests/58 >Adding David, I'm guessing the reason it always pegs the CPU now is that the new processdatamodel forces it to always be loaded.
Sorry, for the delay.
All plugins have to be loaded, as we need data for the headers; but ProcessDataModel does forward whether they're enabled or not to the plugin. The challenge was retrofitting that into ksysguard. That has all columns/attributes enabled then only filters out in the UI. plasma-system-monitor does only process network information on demand.
As for the patch - I know nethogs was the basis of the work that went into our helper, I thought it was a copy and paste, so I'm surprised we have a CPU difference. I assume there was a reason it was done like this, so I'd like to wait for Arjen, but if there's no good justification, then lets go for it.
The latest System Monitor does strange things. In "System Monitor" it reports under 10% CPU usage in Processes view. In "top" it shows ksgrd_network_h process using 35% to 78% of CPU. Hardware: 8 - Intel(R) Core(TM) i7-4770K CPU @ 3.50GHz (In reply to Mac Michaels from comment #21) > The latest System Monitor does strange things. > In "System Monitor" it reports under 10% CPU usage in Processes view. > In "top" it shows ksgrd_network_h process using 35% to 78% of CPU. > Hardware: 8 - Intel(R) Core(TM) i7-4770K CPU @ 3.50GHz Note that top shows CPU utilization per logical core and System Monitor - per system. So a process that utilizes all 8 threads of your CPU will show as 800% in top and 100% in ksysguard. Same problem in Plasma 5.21.5. Workaround: Disable the Download/Upload tabs in the "System Activity" dialog (opens with Ctrl+Esc) - it stops the `ksgrd_network_helper` process altogether. In Plasma 5.22, the ksgrd_network_helper process is no longer used if you use System Monitor instead of KSysGuard. So this bug should not be present there. (In reply to Alexander Potashev from comment #23) > Same problem in Plasma 5.21.5. Workaround: Disable the Download/Upload tabs > in the "System Activity" dialog (opens with Ctrl+Esc) - it stops the > `ksgrd_network_helper` process altogether. Plasma 5.21.4 here. No Download/Upload columns enabled and yet ksgrd_network_helper is still running. (In reply to Nate Graham from comment #24) > In Plasma 5.22, the ksgrd_network_helper process is no longer used if you > use System Monitor instead of KSysGuard. So this bug should not be present > there. Nate, the System Monitor application itself uses CPU like crazy if there is network activity, even with network columns set to "Hidden". Can you file a bug report for that? (In reply to Nate Graham from comment #27) > Can you file a bug report for that? If that helps - #442308 ksysguard is no longer maintained, in Plasma 6 there is the Plasma system monitor for this task. If your issue still happens with the Plasma 6 replacement, please re-open and we can move this bug to the new product, thanks! |