Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Add section about CPU usage in the README

See original GitHub issue

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:

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


Issue Analytics

  • State:closed
  • Created 3 years ago
  • Reactions:1
  • Comments:7 (7 by maintainers)

github_iconTop GitHub Comments

jtpiocommented, Apr 15, 2020

We were wondering at NERSC whether or not to enable your extension (specifically the topbar part ) 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 and why we made 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 and 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, and it’s also why I’m interested in 😃

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:

Having a more generic approach could indeed be useful if we want nbresuse to expose what psutil supports:

jtpiocommented, Apr 3, 2020

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 (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: 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: 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!

Read more comments on GitHub >

github_iconTop Results From Across the Web

Add section about CPU usage in the README · Issue #29
It's a different frontend for nbresuse that gives a more "colorful" view on the current metrics. Today I started added the CPU indicator...
Read more >
Actions and Services implicitly declare a new section. All commands or options belong to the section most recently declared. Commands or options before...
Read more > · dev · Ondrej Vysocky / meric - GitLab
Intel RAPL system to limit power consumption of the CPU, it can be controlled by MERIC, see section System parameters tuning.
Read more >
HTML README Template for Fix Central packages - IBM
This solution is configured through a new configuration parameter in lsf.conf: ... The UT value is the CPU utilization exponentially averaged over.
Read more >
High CPU usage on machines with Deep Security Agent
Under CPU Usage section, set the Integrity Monitoring CPU Usage Level to Low. ... Add the following information under the ds_agent.ini file: trace=*....
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Post

No results found

github_iconTop Related Hashnode Post

No results found