Bug 430003 - ksystemstats process consumes large amount of RAM
Summary: ksystemstats process consumes large amount of RAM
Status: RESOLVED FIXED
Alias: None
Product: ksysguard
Classification: Unmaintained
Component: general (other bugs)
Version First Reported In: unspecified
Platform: Manjaro Linux
: VHI normal
Target Milestone: ---
Assignee: KSysGuard Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-12-04 09:46 UTC by sk.griffinix
Modified: 2021-01-18 13:14 UTC (History)
8 users (show)

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


Attachments
heaptrack (304.29 KB, image/png)
2021-01-15 10:09 UTC, David Faure
Details
heaptrack graph (127.26 KB, image/png)
2021-01-15 10:11 UTC, David Faure
Details

Note You need to log in before you can comment on or make changes to this bug.
Description sk.griffinix 2020-12-04 09:46:46 UTC
SUMMARY
Don't know which category to post in. Problem is with ksystemstats. Under certain circumstances, ksystemstats process consumes very high amount of RAM (>6 gb on 8gb machine). Problem almost always occurs after screen locking and unlocking, but is not reproducible every time. Causes computer to slow down and become almost non-responsive. Ending the process restores normal responsiveness without any apparent adverse effects
Comment 1 rapiz 2020-12-29 03:32:31 UTC
I can confirm this on Arch Linux. The process ksystemstats consumes 13GiB Ram.
Comment 2 aarh9 2021-01-01 13:26:01 UTC
Can confirm on Manjaro 20.2, killing the process solves the problem.
Comment 3 aarh9 2021-01-01 13:30:03 UTC
For me, it occurs sometimes after resume from suspend
Comment 4 David Edmundson 2021-01-01 15:21:06 UTC
Can you run heaptrack on it?
Comment 5 David Faure 2021-01-15 10:09:01 UTC
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.
Comment 6 David Faure 2021-01-15 10:09:19 UTC
Created attachment 134883 [details]
heaptrack
Comment 7 David Faure 2021-01-15 10:11:30 UTC
Created attachment 134884 [details]
heaptrack graph
Comment 8 David Faure 2021-01-15 10:18:34 UTC
Shouldn't this block

    if (m_devices.contains(uni)) {
        return;
    }

happen before the connect()?
Or is "device" not unique for a given uni?
Comment 9 Arjen Hiemstra 2021-01-18 12:51:22 UTC
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
Comment 10 David Edmundson 2021-01-18 13:14:50 UTC
Thanks David F