Bug 414036 - ksgrd_network_helper uses a lot of CPU on high network load
Summary: ksgrd_network_helper uses a lot of CPU on high network load
Status: RESOLVED UNMAINTAINED
Alias: None
Product: ksysguard
Classification: Unmaintained
Component: ksysguard (show other bugs)
Version: 5.17.90
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: KSysGuard Developers
URL:
Keywords:
: 414094 420701 (view as bug list)
Depends on:
Blocks:
 
Reported: 2019-11-11 18:42 UTC by José JORGE
Modified: 2024-09-23 20:59 UTC (History)
24 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
helper launched with --stats show more than 500 packets per second (4.43 KB, text/plain)
2019-11-11 18:42 UTC, José JORGE
Details
high cpu usage while downloading with jdownloader (152.08 KB, image/png)
2020-05-15 21:58 UTC, Patrick Silva
Details

Note You need to log in before you can comment on or make changes to this bug.
Description José JORGE 2019-11-11 18:42:06 UTC
Created attachment 123844 [details]
helper launched with --stats show more than 500 packets per second

New helper for ksysguard shows very high CPU usage when it processes a lot of packets

STEPS TO REPRODUCE
1. launch ksysguard in the first tab
2. wget http://ftp.free.fr/mirrors/mageia.org/iso/7.1/Mageia-7.1-i586/Mageia-7.1-i586.iso
3. watch CPU usage

OBSERVED RESULT
Very high usage

EXPECTED RESULT


SOFTWARE/OS VERSIONS
Windows: 
macOS: 
Linux/KDE Plasma: 
(available in About System)
KDE Plasma Version: 
KDE Frameworks Version: 
Qt Version: 

ADDITIONAL INFORMATION
Comment 1 Jan Przybylak 2019-11-17 12:51:30 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
Comment 2 Jan Przybylak 2019-12-07 16:30:13 UTC
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.
Comment 3 José JORGE 2019-12-08 18:30:27 UTC
(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.
Comment 4 Rainer Finke 2020-01-10 17:07:12 UTC
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.
Comment 5 Patrick Silva 2020-01-23 00:26:38 UTC
*** Bug 414094 has been marked as a duplicate of this bug. ***
Comment 6 Antonio Bragatto 2020-03-13 15:29:13 UTC
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...
Comment 7 slch 2020-03-15 16:28:14 UTC
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.
Comment 8 Antonio Bragatto 2020-04-07 14:07:47 UTC
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...
Comment 9 Patrick Silva 2020-04-29 01:42:03 UTC
*** Bug 420701 has been marked as a duplicate of this bug. ***
Comment 10 Patrick Silva 2020-05-15 21:58:54 UTC
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
Comment 11 David Korth 2020-05-17 17:16:43 UTC
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.
Comment 12 iamashwin99 2020-05-18 07:36:13 UTC
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?
Comment 13 iamashwin99 2020-05-18 07:39:53 UTC
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?
Comment 14 José JORGE 2020-05-18 07:49:46 UTC
(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.
Comment 15 iamashwin99 2020-06-03 13:10:50 UTC
is there a way to manually disable this check. Im facing a lot of overheating issues (thus battery issues) because of this.
Comment 16 Martin Sandsmark 2020-12-12 13:43:14 UTC
Adding David, I'm guessing the reason it always pegs the CPU now is that the new processdatamodel forces it to always be loaded.
Comment 17 Martin Sandsmark 2020-12-12 13:54:12 UTC
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.
Comment 18 Martin Sandsmark 2020-12-12 14:13:52 UTC
Porting to libnethogs should be fairly trivial (something like http://ix.io/2HHu + delete the rest of the code in ksgrd_network_helper)
Comment 19 Bug Janitor Service 2020-12-21 16:47:26 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/ksysguard/-/merge_requests/58
Comment 20 David Edmundson 2020-12-21 17:32:24 UTC
>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.
Comment 21 Mac Michaels 2021-08-15 13:10:49 UTC
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
Comment 22 Lastique 2021-08-15 21:20:50 UTC
(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.
Comment 23 Alexander Potashev 2021-09-10 14:44:05 UTC
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.
Comment 24 Nate Graham 2021-09-10 14:48:47 UTC
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.
Comment 25 Lastique 2021-09-10 15:22:50 UTC
(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.
Comment 26 Eugene Shalygin 2021-09-11 10:26:13 UTC
(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".
Comment 27 Nate Graham 2021-09-11 14:03:37 UTC
Can you file a bug report for that?
Comment 28 Eugene Shalygin 2021-09-11 14:25:21 UTC
(In reply to Nate Graham from comment #27)
> Can you file a bug report for that?

If that helps - #442308
Comment 29 Christoph Cullmann 2024-09-23 20:59:49 UTC
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!