| Summary: | ksystemstats process consumes large amount of RAM | ||
|---|---|---|---|
| Product: | [Unmaintained] ksysguard | Reporter: | sk.griffinix |
| Component: | general | Assignee: | KSysGuard Developers <ksysguard-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | aarh9, ahiemstra, faure, kde, nate, notmart, plasma-bugs-null, rapiz |
| Priority: | VHI | ||
| Version First Reported In: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Manjaro | ||
| OS: | Linux | ||
| Latest Commit: | https://invent.kde.org/plasma/ksysguard/commit/de20a4c0259d255b95fabb4ccfc965f8c1bf660d | Version Fixed/Implemented In: | |
| Sentry Crash Report: | |||
| Attachments: |
heaptrack
heaptrack graph |
||
|
Description
sk.griffinix
2020-12-04 09:46:46 UTC
I can confirm this on Arch Linux. The process ksystemstats consumes 13GiB Ram. Can confirm on Manjaro 20.2, killing the process solves the problem. For me, it occurs sometimes after resume from suspend Can you run heaptrack on it? I've been running ksystemstats in heaptrack for many days, and it finally happened. B VmData grew from the already gigantic 1330860 kB to 10506584 kB which is just insane in just 10 minutes, after being stable for days. If heaptrack is correct, the memory consumption comes from.... a TON of QObject::connects in NetworkManagerBackend::onDeviceAdded(). Very surprising. Created attachment 134883 [details]
heaptrack
Created attachment 134884 [details]
heaptrack graph
Shouldn't this block
if (m_devices.contains(uni)) {
return;
}
happen before the connect()?
Or is "device" not unique for a given uni?
Git commit de20a4c0259d255b95fabb4ccfc965f8c1bf660d by Arjen Hiemstra. Committed on 15/01/2021 at 13:06. Pushed by ahiemstra into branch 'master'. NetworkManager: Do not remove devices when their active connection changes In certain cases, NetworkManager can go on a rampage sending active connection change signals in very rapid succession. This results in memory usage ballooning because lambda connections can not be unique. Rather than destroying and recreating the NetworkManagerDevice objects on active connection change, this changes things so that we only remove them from the SensorContainer but keep the actual objects around. This allows NetworkManagerDevice to track its active connection state, removing the need for constant reconnects. M +51 -22 plugins/global/network/NetworkManagerBackend.cpp M +11 -1 plugins/global/network/NetworkManagerBackend.h https://invent.kde.org/plasma/ksysguard/commit/de20a4c0259d255b95fabb4ccfc965f8c1bf660d Thanks David F |