htop eats too many cpu cycles!

[COLABORATI]

Currently I am doing some research about cpu usage of system monitoring tools and htop is on the second position of my list of _"tools that help you monitor a stressed system but put even more stress on that system"_ - it shows itself as the second most cpu cycle eating process on a decent core i7, which is too much - htop burns more cpu cycles than the web browser on the same machine I am writing this issue with - this is not acceptable.

Please review your code to reduce that absurdly excessive cpu usage. I see interesting results with the prometheus node_exporter - do not know, if that might be inspiring, of course a different world.

Meanwhile I would like to ask for hints that you as the author might have to the trustful user: how can she reduce the load that htop itself is putting on the system?

Thank you for your attention!

[etosan]

First if you are in for a quick fix, just increase re-scan delay. It's in tenths of seconds, so 20*10 = 2 secs.

Like this:

htop -d 20

On modern, multicore hyperthreaded, linux box, delay of two seconds, usually, pushes your htop cpu usage down to one percent range.

With -d 40 (4 seconds) you are approaching 0.5-0.1% usage range. You can try to remove columns you don't need, as it means less processing for htop, but I bet changes from that would be marginal.

For your information top provided by your distribution usually runs with delay equivalent to 3 secs.

With default settings, top reports itself at 0.3-0.7 % of cpu time on my box:

$ top
> 2732 eto       20   0   18528   3404   2160 R   **0.3**  0.0   0:00.84 top

Let's see how htop compares with same delay:

$ htop -d 30
>  0  0:00.51 17072  5800  2712  0.0  5708 R  **0.3** eto       htop -d30

As you see there is no tangible difference between the two.

So easiest form of control is to increase/decrase re-scan delay:

• if you want precise process activity tracking, decrease delay
  
  
  
  • you have to suck up cpu usage increase, but you can observe processe come and go almost realtime
  
  
• if you want informal machine observation, increase delay and lower your cpu dusage (like 10 secs)
  
  
  
  • you will miss lot of very shortlived processes but htop will be not be eating cpu
  
  

It's tradeoff you have to make depending on what is important to you.

Now let's look at your comparison with prometheus. Comparing top (or htop) to node_exporter is completely useless, or as native english speakers would say like comparing "apples to oranges".

On linux, *top tools run continuosly in the foreground, and each time timer fires they rescan whole /proc directory scanning for changes in each and every process of the system.

Prometheus is completely different, it slacks of doing literally nothing (hopefully), waking up once in a while (and at much slower rate) cherry-picking few non-process related files from /proc.

I urge you to find me a single collector here https://github.com/prometheus/node_exporter/tree/master/collector that does something even remotely similar to what top (or for that matter htop does). More over I want to invite you to write "top like" collector for prometheus, that will not exhibit same /proc limitations that top and htop hit.

[hishamhm]

@etosan Thank you for the detailed response! It clarifies the situation quite clearly.