Add section about CPU usage in the README

Just like for the memory usage, there could be a section in the README file that demonstrates how to specify the options.

Also it looks CPU is not tracked by default, which could be confusing if a user only sets cpu_limit:

https://github.com/yuvipanda/nbresuse/blob/783735980c8dc09907499fb4a1bd401b8d22adf8/nbresuse/__init__.py#L72-L77

Was there a reason to make cpu usage tracking an opt-in option?

Thanks!

[jtpio]

We were wondering at NERSC whether or not to enable your extension (specifically the topbar part https://github.com/jtpio/jupyterlab-topbar ) by default for all users. One thing some users wanted to have a graphical interface for tracking their memory and CPU usage, which is why I made this (now very out of date) JupyterLab extension several months ago https://github.com/NERSC/jupyterlab_resuse and why we made jupyterlab-cpustatus https://github.com/NERSC/jupyterlab-cpustatus .

Since your extension already has a graphical portion built-in, and already supports the latest version of JupyterLab, and already has support for CPU tracking built-in, it seems like we should even more seriously consider installing it for all users system-wide.

These are really nice extensions!

It looks like there is indeed some overlap between https://github.com/NERSC/jupyterlab_resuse and https://github.com/jtpio/jupyterlab-system-monitor. For the system-monitor extension I would also like to add a panel with more information so it’s not only in the top bar. The panel could contain different views for the metrics and more details.

It’s tracked in https://github.com/jtpio/jupyterlab-system-monitor/issues/24, and it’s also why I’m interested in https://github.com/yuvipanda/nbresuse/issues/31 😃

In any case though thank you so much for updating your extension to use this new feature of NBResuse! I’m really grateful – I honestly thought no one outside of NERSC would have ever noticed or used the new feature.

Many thanks to you and anyone involved for the work on nbresuse!

The basic idea, as far as I understand, is to develop a common interface for any possible resource, instead of needing to reinvent the wheel every time (e.g. like I did with the CPU monitoring). It is perhaps now out-dated since one of its stated aims is to avoid conflict with Prometheus metrics, but now NBResuse uses Prometheus.

I haven’t thought too much about it, but psutil should be helpful for that too: https://psutil.readthedocs.io/en/latest/#psutil.net_io_counters

Having a more generic approach could indeed be useful if we want nbresuse to expose what psutil supports: https://psutil.readthedocs.io/en/latest/#system-related-functions

[jtpio]

Thanks for the detailed answer!

Yes, part of the reason for not making the CPU usage tracked by default is because it isn’t displayed in the NBExtension included in this package, and a JupyterLab extension is required to display it in JupyterLab https://github.com/NERSC/jupyterlab-cpustatus (Also unfortunately that JupyterLab extension appears to be out-of-date as of February due to the release of JupyterLab 2.0. NERSC/jupyterlab-cpustatus#3)

Also since the CPU tracking feature was added recently and not by Yuvi (i.e. by me, who is not nearly as skilled as Yuvi), in other words it was/is somewhat experimental, my recollection was that Yuvi thought (and I agreed) it would be safest to not enable it by default, so as to ensure backwards compatibility/avoid possibly breaking NBResuse for users who don’t use the CPU tracking feature.

OK this sounds like the safest for now. Although cpu tracking mostly adds new attributes to the response payload, it is possible that some users expect a specific schema for the response or don’t want this metric to be shared. Also it could probably be enabled by default in a future version, maybe when bumping to 1.x.

Indeed there is already a memory item in the core status bar. Also the logic doesn’t need to change to add CPU metrics since it’s the same request to /metrics. So (1) should be feasible without too much effort.

(3) sounds like a good idea in the long run.

As a side note, I maintain a JupyterLab extension that displays these metrics in the top area: https://github.com/jtpio/jupyterlab-system-monitor It’s a different frontend for nbresuse that gives a more “colorful” view on the current metrics. Today I started added the CPU indicator as well, and merge it very soon: https://github.com/jtpio/jupyterlab-system-monitor/pull/20. Both indicators share the same model / data (one request to retrieve both the memory and cpu stats). But this required rewriting some of the logic already in core lab. So (1) would indeed be very useful so other frontends can reuse the logic of the model to build alternative views.

Maybe we should join efforts on this!