Plasma System Monitor Preview Release

By ahiemstra, 3 November, 2020

I would like to announce the preview release of Plasma System Monitor. It can be downloaded from here 1 or you can browse the source code directly on KDE Invent. Please see the readme file for what is needed to build or run it. If you run into any bugs, please report them on bugs.kde.org.

Plasma System Monitor Overview Page
Plasma System Monitor's Overview Page

Plasma System Monitor is a brand new UI for monitoring system resources. It is built on top of Kirigami and a new system statistics service called "KSystemStats" that was debuted in Plasma 5.19. It shares a lot of code with the new system monitor applets that were also introduced in Plasma 5.19. It is meant to be a successor to KSysGuard.

History

An early version of Plasma System Monitor
An early version of Plasma System Monitor. While the visuals have not changed much, the underlying technologies changed quite a bit.

Almost two years ago a project was started to create a new backend for monitoring system resources. This was initially intended to support a new set of system monitor widgets for Plasma. While working on this, we realised that the system monitor application could also do with a refresh, which would be a lot simpler now that we had a new system to build upon. After a little bit of iteration we had something that I was mostly happy with, with one major missing feature, there was no way of adding custom pages like KSysGuard has. To support this, we ended up unifying the display code between Plasma System Monitor and Plasma's system monitor applets, allowing one to select different display styles in the applet and also when editing pages in Plasma System Monitor.

Plasma System Monitor configuration compared to Plasma applet
Unified display styles between System Monitor and Plasma: System Monitor's display configuration on the left, Plasma's applet configuration on the right.

Features

On startup, you will be greeted by the Overview page, that has been designed to give a quick overview of your entire system. It provides a view of important core resources: memory, disk space, network and CPU usage. It also provides a small version of the same table as used on the Applications page to give you a quick view of what applications are consuming the most resources.

Plasma System Monitor Applications Page
Applications Page

Another new feature is the Applications page. This shows you all running applications along with detailed statistics and graphs for those applications. This makes heavy use of the grouping features that were recently introduced to Plasma. See David Edmundson's blog for more details about this.

Plasma System Monitor Processes Page
Processes Page

The Processes page is very similar to the one in KSysGuard, but we have tried our best to streamline it and remove some of the inconsistencies in it. For example, you can now select the "Line Chart" display mode for any column that displays a numeric value. Similarly, the tree view mode no longer requires displaying all processes, but is now a simple mode toggle. (Please note: The tree view mode unfortunately requires Plasma 5.21 because some parts did not make it for the Plasma 5.20 release.)

Plasma System Monitor History Page
History Page

The History page has undergone the least functional changes, the most prominent one is that the CPU chart will now be displayed stacked by default.

Plasma System Monitor Editing Interface
Editing a new page

Should you find the pre-made pages lacking, there is a completely new UI to create and edit pages. The editing UI allows you to divide the page into several different rows, columns and sections. You can then select which sensors you want to display in which way.

Plasma System Monitor Display Style Configuration
Display style configuration

The Future

Both the application and the underlying statistics system are still undergoing a lot of development. For example, we have been working on replacing a lot of the old statistics collection code with new code that makes use of existing libraries and systems that simply did not yet exist when the original code was written. This reduces the amount of work that needs to be done to maintain things and allows us to expose new features, like support for GPUs. For Plasma System Monitor specifically, the plan is to include it by default with Plasma 5.21. We will probably not be replacing KSysGuard immediately, but longer term that is the goal.

  1. These tarballs were generated from git commit 098b91556901ccb611028b3a9156de61295b664c with SHA256 sum ec0af476c7cf992a3fc43af4e7f066c22757b7c196ee49fdbc4286bdf02948d11. They have been signed by Jonathan Riddell with key 7F05997E pub rsa2048 2016-09-06 2D1D 5B05 8835 7787 DE9E E225 EC94 D18F 7F05 997E Jonathan Riddell <jr@jriddell.org>. ↩

Tags

Comments42

KDE Style

3 years 11 months ago

wow this is impressive. It looks like it gives IO/NET/GPU/CPU data per process, IO/NET/GPU/CPU charts per process, IO/NET/GPU/CPU overall charts. Throw some sensors (temperature, fan rpm) in and you get ultimate monitor. Do i have even more crazy ideas.. yeah, identify open files and identify window (procexp style). Thanks!

Baoht Margin D…

3 years 11 months ago

I win again

Common Sense

3 years 11 months ago

Why is the overview layed out the way it is? You could place the Network & System, Applications areas next to each other, so that the information is presented vertically, which is far more useful - you see more applications and waste less space.

I.e: https://cdn.discordapp.com/attachments/277857463384932353/773245302227861524/unknown.png https://i.imgur.com/j71xTCe.png

You see more applications but less details - it's going to be a tradeoff either way. Vertical columns are not currently supported but are something I've considered adding at some point, the code is flexible enough to be able to handle that. That would allow changing this for those who want it differently.

Andres Kruger

3 years 11 months ago

Looks beautiful!!

MayeulC

3 years 11 months ago

Though the contrast is very low between the various CPU line stacks, and I am not even colourblind. Maybe lower the luminance a bit on the borders, a bit like the current ksysguard?

I also like ksysguard's "remote monitoring" capabilities. Is this going to be included somehow? One of the limitations was that it was necessary to have ksysguard on the other side, it would be nice to be able to do away with that at some point...

I assume you mean the colours for the stacked line chart on the history page. It's actually possible to change those from the editing UI, though we may be able to have a look at how the default colours are generated. Unfortunately, there's only so much we can do for autogenerated colours here.

With regards to remote monitoring, the new backend makes it somewhat harder to do but in theory it can still be supported. Personally though, I think remote monitoring is better left to a more dedicated system. One thing that might instead be interesting is to develop a plugin for the new backend that exposes a dedicated remote monitoring system as sensors for system monitor.

With regards to remote monitoring, the new backend makes it somewhat harder to do but in theory it can still be supported.

I'd be interested in that as well for monitoring remote servers.

Scott

3 years 11 months ago

I love KSysGuard and its functionality and this appears to be an excellent step forward. Thank you to all who are involved!

However I agree with the common sense guy that the overview panel should be changed from the default to what he mocked up.

I'm still going to test it out. Thanks again! :)

Ivan Dimitrov

3 years 11 months ago

Hi, thank you for the great work. I hope you can retire the kSysguard asap as it is one of the biggest resource consumers in my system. A few points:

  • I guess you know that the network monitoring doesn't work with systemd-networkd
  • it would be great if possible to choose separate colour scheme. Thanks.

Smurfy

3 years 11 months ago

But kSysguard doesn´ t need any resources if you don't start it at all? So I don´t understand why it should be retired as soon as possible.

I have just tested kSysguard on myself. It needs 28MB RAM and it shows 1% CPU load every now and then. It doesn´t look like very resource hungry.

ahiemstra

3 years 11 months ago

I guess you know that the network monitoring doesn't work with systemd-networkd

Yeah, the current network plugin in the backend only supports NetworkManager. It's been on my todo to add a backend that makes use of sysfs directly for all cases where NetworkManager is not available. I hope to have that fixed for Plasma 5.21 at least.

it would be great if possible to choose separate colour scheme. Thanks.

This is something that has been brought up for various other applications as well. I believe there are some plans to make this available for everything, but that may have been speculation. Could you open a feature request for it on bugs.kde.org?

A

3 years 11 months ago

Finally I'll be able to replace my trusty gnome-system-monitor :) Great job!

Andreas

3 years 11 months ago

Can you shed some light on the question why Intel GPUs are non exposable?

See: https://www.reddit.com/r/kde/comments/jne5tv/kde_plasmas_system_monitor_gets_a_facelift_and_a/gb1v8fz/?context=3

Thanks!!

In short, it's because the Intel driver does not expose that information.

A longer explanation: We need a non-privileged API to be able to access information from the system. Lots of things are available through either sysfs or procfs, which we expose as sensors. For GPUs, the current situation is unfortunately rather a mess:

  • amdgpu exposes several files in its sysfs nodes that we can use to get global GPU usage, memory usage, speeds, etc. This is the best situation for us. Though there is a caveat: for some GPUs, the gpu_busy_percent file will not report a usage percentage and instead produce an "invalid argument" error, so even that is not perfect. I do not know the state of other kernel drivers, but if they expose the same files they should be supported.

  • nvidia GPUs do not expose anything on sysfs, but there's a tool called nvidia-smi that can be run as non-privileged user that will export a bunch of information. It even has machine parseable output. We can support this fairly easily, though it means having another binary that gets executed.

  • intel GPUs do not expose anything on sysfs. There is a tool called intel_gpu_top, but it can only run as root. What it does is read performance counters of the GPU and print that out on the command line. This we cannot support, because we do not really have the ability to run a priviledged binary in the backend, nor would we really want to. In addition, the GPU counter interface used by intel_gpu_top is both privileged and proprietary, so neither can we make use of that directly.

Now, that said, there's some work going on to expose some statistics from the Intel GPU on sysfs. Once that lands, we will be able to support Intel GPUs - assuming we can access them. It remains to be seen when this will happen though.

Adam Ce

3 years 11 months ago

Hi, very cool to see some changes in the system monitor. I'm looking forward to have them in production :)

But also a few comments:

  1. Modern CPUs are having more and more cores. Therefore I think it's less and less useful to show the load for every core separately. On my current workstation at work I have 24 of them, at home it's also already 16. Previously I already have had 40. With these counts looking at the per core load is pretty useless. Moreover the kernel often switches between cores, so you don't have a nice graph, but something where you can't distinguish the cores any more (example: https://i.imgur.com/40RwZxF.png , thanks for hinting the stacked view btw, it's better now :). So I propose to show only the sum.
  2. With hyperthreaded CPUs, only half of the cores have full "value", the other half is not worth that much. That should be reflected in the monitor. But I don't know what would work, since the value also depends on the program. An experiment would be to show the first half of cores as 0-100%, and the rest goes above..
  3. Modern CPUs change the clock speed very often. Ages ago that concerned only notebooks, but now it's also workstations. If it's only one core, and as long as it doesn't overheat, it can get a boost for example. Again, this could be shown as 100% being the nominal clock. It might be a bit weird that it goes over 100%, but it actually goes over 100% of nominal.

Is there a way to measure the number of instructions executed? That would make this 100% view relatively easy to implement:

  • calculate 100% as the theoretical maximum of what the CPU can do at nominal clock, on all physical cores
  • boost could lift that above 100%, but in practise that would seldom happen, because of pipeline stalls, boost not working that well when all cores are loaded etc.
  • people would see how efficient some software uses the CPU, not how long it waits for main memory ;)

Some other things: 4. I think that it would make the dashboard (main view) cooler if the circle bars would be replaced by history plots. History plots also show the current information (so nothing is lost), and, well the history. So there is additional history without lost space. 5. Energy usage if available. I hated the userinterface of MacOS so much that i spent a week installing KDE on a mac book ;), but showing per app battery drain was super useful. In addition it would motivate developers to be more lenient on that front in the long run, which would also benefit KDE as a whole :D 6. I am dreaming of implementing that myself, but I won't have time in the foreseeable future: time-logarithmic history: It's useful to look at the past minute or so of the CPU usage with a precision of seconds, but when you go further into the past that is not useful. But you might want to know the average load over 1 minute an hour ago, and the average over 10 minutes 5 hours ago. That way you could see at what time that job you ran over the night started failing. The plot wouldn't move linearly to the left, all pixels at the same speed. instead, on the right, it would move faster, and slower on the left. The data would be averaged in coarser and coarser time intervals. If implemented well, this could even reduce the system load by the system monitor, because you would have smaller redraw areas (the left part of the plot doesn't need so many updates). 7. I think that is impossible right now, but showing GPU load and memory usage would be interesting.

Thanks for all the work, KDE is imo the most productive desktop, and I love it. It would be super cool, if it would become even better due to some ideas in this comment :)

Cheers, Adam

  1. There is a sensor to show the total cpu usage so you can just switch it out
  2. We also expose the frequencies of the cores as sensors, maybe plotting that could be interesting for you

I think there was talk about having those batteries stats somewhere in Plasma but getting the info in the first place is hard.

i know there is a sensor for all cpu load, but afaik there is no way to show it on the main view.

with regard to clock speed, I know that as well, but that means looking at 2 plots, and it's also not in the main view :)

Modern CPUs are having more and more cores.

Yes, which is actually one of the reasons I switched the CPU chart on the history page to use the stacked view, it should give a fair indication of the total CPU usage and how it's divided over different cores. In my mind, with more cores, individual slices become smaller which would lead to things blurring together more and more and the entire chart looking like a total CPU chart. That said I don't know how well that works in the end, I do not currently have a Threadripper system to test with unfortunately.

With hyperthreaded CPUs, only half of the cores have full "value", the other half is not worth that much.

Yes and no, it is highly dependent on the workload. More importantly however, we are limited by what the kernel exposes, which on Linux means it's all exposed as CPU cores. So there's little we can do there I'm afraid.

Modern CPUs change the clock speed very often.

Yes, they do. We have frequency sensors for that, which for Plasma 5.21 have actually been reworked a bit and will now be clearly part of the "CPU" subsystem. We may be able to add a default chart for this, though to be fair it's not something that is very important to show in my opinion. My Ryzen changes frequencies so much that I wouldn't know what to do with that data.

Is there a way to measure the number of instructions executed?

You'd need to read performance counters which often require higher privileges and have other issues. So nothing we can work with really.

I think that it would make the dashboard (main view) cooler if the circle bars would be replaced by history plots.

Maybe. They're easy enough to replace so you can try that out for yourself. If it turns out to be something a lot of people want we can reconsider the current layout.

Energy usage if available

Global energy sensors are sort of already there, but these will be properly supported in Plasma 5.21. We may be able to place them somewhere once we have all the bits in place, since I personally would also like it if we show GPU information by default. Per application usage is trickier to do, I do not know if that is available somehow in a non-privileged way from the kernel.

I am dreaming of implementing that myself, but I won't have time in the foreseeable future: time-logarithmic history

That's a pretty neat idea actually. Though for load specifically there are already average load sensors since these are exposed by the kernel. We did discuss some plans about doing more long-term data collection in the backend that we can expose for longer term charts, one explicit use case being energy monitoring.

I think that is impossible right now, but showing GPU load and memory usage would be interesting.

I actually mention this in the post, that's being worked on and will be supported for Plasma 5.21. In fact, if you have an NVidia GPU there are already sensors available, though that implementation is not ideal. With Plasma 5.21 AMD gpus will also be supported and we have a better base to build things like default charts on.

Thanks for all the work, KDE is imo the most productive desktop, and I love it. It would be super cool, if it would become even better due to some ideas in this comment :)

Thanks for the comment, there's plenty of things to think about at least. :)

Simon

3 years 11 months ago

With ksysguard I often notice memory usage increasing and can then look at the current values and plot them in my head (or with gnuplot). It would be great to have this integrated in the system monitor. Plotting the memory history for several processes would be the hit

plasma-systemmonitor has two ways of doing that actually: You can enable the inline line chart (like is shown for the CPU usage) for memory. Alternatively, the applications page has a "Details" sidebar that shows charts of resources used by the application that will also show you historical information.

Andreas

3 years 11 months ago

The read/write, upload/download and memory column now only shows the current (average) value.

It would be convenient if there were graphs for it as well for each process you cannot always look at the values just like you already have for the CPU.

Additionally the read/write would fit to the history page too.

Furthermore it would be great here if you could determine the length of the history displayed and also use a logarithmic scale for the time axis and optionally for the y-axis when needed.

It would be convenient if there were graphs for it as well for each process you cannot always look at the values just like you already have for the CPU.

This is already possible, the inline charts can be enabled for any numerical column.

Furthermore it would be great here if you could determine the length of the history displayed and also use a logarithmic scale for the time axis and optionally for the y-axis when needed.

Changing the range (and thus the amount of history) can already be done. Logarithmic scale is not yet possible, but another commenter mentioned something similar.

badpixel

3 years 11 months ago

For me disk usage is wrong, because in comparison to CPU or memory usage colors are reversed. It should show disk usage, not free space IMHO (like CPU free cycles or free RAM memory)

Andreas

3 years 11 months ago

About the overview panel: You now have "storage" in the center between "memory" and "cpu".

I'd probably put it to the right as it's the usually the most static variable overall. The other two, memory and cpu, rather belong together.

Maybe if the GPU can be exposed it could CPU / GPU/ Memory and Networks + Rates merged and the storage goes to the next line.

Just thinking out loud. :-)

Y-Kaelig

3 years 11 months ago

Hi,

Could you please tell me in detail what will not work without systemd ?

Thx

ahiemstra

3 years 11 months ago

The applications table won't work without systemd, so you'd not get any applications on the overview page or the applications page. These rely on a specific cgroup layout that, as far as I know, is only done by systemd.

Sam

3 years 11 months ago

Hi! Thank you for the release! I just tried it and it's very good!

Please please please would you implement configurable update interval, so history CPU/network graphs get more precision?

Thank you for your work.

eric

3 years 11 months ago

This is awesome, I've just installed it under Arch. Awesome job everyone The only thing is that the history memory doesn't show the swap line, even though it's currently using 2.7gb

It should, the problem is that it is usually hidden behind the memory chart. A quick fix is to set the fill opacity to something like 0.1, then you'd be able to see the swap usage. Longer term we need to find a better way to display it though, maybe stacking things could work.

Alex

3 years 11 months ago

This is the achilles hill of most (if not all) linux resource monitors.

I have a workstation with 256 threads, the single chart approach (multi-line or stacked), is a mess - the legend alone is a jambled mess.

I suggest a multi-chart approach similar to that of Windows 10, have multiple area / line charts for each thread, utilization and say thread no & frequency on an overlay - logically grouped into Socket no, and chiplet (if possible), with selectable group metric say utilization, temperature.

I know this necessitates a more dynamic, runtime view dependent on the CPU cores reported - requiring some measure of layouting for responsiveness, instead of the simplistic static single chart that can be set at compile time.

Think of this as an enterprise tool as well for sysadmins not just laptop / desktop users (hence why the overview / detail split is good).

As a minor note, also consider displaying - in the applications and Processes views:

  1. the application cgroup's or proccess' open files including mmaped files via lsof, and open ports via netstat or equivalent (summary aggregates and detailed)

  2. power use via powertop or equivalent

  3. whether sound is playing as done already in plasma, but more intelligent to show particular app instance instead of app group (as its a mess when playing sound in a browser with many instances - all of them showing sound playing even though only one is!) - can integrate with pulseaudio or pipewire or equivalent to provide these metrics

  4. provide actions to block cgroup in applications view from accessing network via say iptables / firewalld / ufw or throttle bandwidth

  5. Provide a project vision statement and a roadmap to keep expectations in check

Regards

mex

3 years 11 months ago

sorry i couldnt find how to compile this. But i really like to test it. i tried cmake it gave errors.

MEX

3 years 11 months ago

finally i found how to compile and run that beauty but i got this error Icon theme "gnome" not found. withouth sudo with sudo it says in terminal as follows

StandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root' QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root' QQmlApplicationEngine failed to load component file::/main.qml:18:1: module "org.kde.ksysguard.page" is not installed