Bug 438787

Summary: Very limited amount of history to keep in plasma system monitor
Product: [Applications] plasma-systemmonitor Reporter: antonmx
Component: generalAssignee: KSysGuard Developers <ksysguard-bugs>
Status: CONFIRMED ---    
Severity: wishlist CC: ahiemstra, antonmx, kde, nate, plasma-bugs, postix
Priority: LO    
Version: unspecified   
Target Milestone: ---   
Platform: Other   
OS: Linux   
See Also: https://bugs.kde.org/show_bug.cgi?id=440402
Latest Commit: Version Fixed In:

Description antonmx 2021-06-17 03:29:36 UTC
SUMMARY

The amount of history to keep is limited to 999 seconds, what is incredibly low for those who want to monitor long running processes (24 hours+). I found it is possible to set higher numbers in the configuration file ($HOME/.local/share/plasma-systemmonitor/history.page), but then the application operates really slow or even freezes.

I. Gui method

STEPS TO REPRODUCE
1. start plasma system monitor
2. edit history page (or any other line graph)
3. set the parameter "amount of history to keep"  to 999 and increase by one.

OBSERVED RESULT
the parameter resets to 0.

EXPECTED RESULT
the parameter to be 1000.


II. File method.

1. Close all instances of the monitor.
1. edit .local/share/plasma-systemmonitor/history.page
2. set the historyAmount=86400 (24 hours)
3. start the monitor and select history page.

OBSERVED RESULT
application freezes for several minutes and does not update graphs.

EXPECTED RESULT
the 24 hour graphs to be plotted.




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

ADDITIONAL INFORMATION
Comment 1 Arjen Hiemstra 2021-07-01 15:06:02 UTC
The system has been designed to do real time reporting of current system status, with an update rate of 500ms. It is not meant for tracking long processes, which would need a completely different approach, where you'd collect data over a certain time period then generate a data point from the average. We have discussed doing something like that in ksystemstats, but so far it has not been implemented and it would be a fairly large task to implement.