Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Explanation of everything you can see in htop/top on Linux (2019)

peteris.rocks

Post reply on HN
Print view View original

41–50 of 71 posts

Re: Explanation of everything you can see in htop/top on Linux (2019)

#41

Post by JdeBP »

zackify wrote: post #37
imrehg wrote: post #13

I've relatively recently migrated over to using btop[0], and it's the kind of modern interface, useful and informative, that I needed. As others mention it - it seems to shows the Watts used as well :) (and network, and GPU, and disks,....) [0]: https://github.com/aristocratos/btop

Same. Btop is the best

Well, unless one is using FreeBSD or OpenBSD, where the btop code is still using 32-bit integers to calculate 64-bit sizes, and falling prey to unsigned integer wraparound. htop's code calculates using size_t, which ends up as a 64-bit integer on 64-bit architectures.

* https://news.ycombinator.com/item?id=48778757 (https://crocidb.com/post/freebsd-ate-my-ram/)

* https://github.com/aristocratos/btop/pull/1728

Re: Explanation of everything you can see in htop/top on Linux (2019)

#42

Post by Zardoz84 »

zepearl wrote: post #34

For the ones that don't know "nmon", have a look at it as well! (press "h" to see the list of available monitors - press it again to make it go away, press "q" to quit) https://nmon.sourceforge.io/pmwiki.php Especially disk throughput and I/O (keys "d" & "D") can be very useful.

very useful tool. I install it on every machine where I have control. I appreciate the "Wide" CPU usage graph, that can handle huge core counts easily

Re: Explanation of everything you can see in htop/top on Linux (2019)

#43

Post by lukan »

sevg wrote: post #22
amelius wrote: post #12

[flagged]

> Nowadays most of my processing happens on the GPU, so htop/top better evolve or become mostly irrelevant If you’re a 3D rendering designer, an ML engineer or a crypto bro, then sure. Here are the common workloads (for the average SWE on HN) that use CPU/RAM: - compilation/builds - language servers and IDEs - test suites - local containers - local databases - node tooling - browsers - data processing - compression a…

And your browser for instance might crash, if it runs out of gpu memory, which will surprise you if you only look for cpu/ram.

(Happened to me)

Re: Explanation of everything you can see in htop/top on Linux (2019)

#44

Post by cb321 »

A different usage paradigm from *top that I have come to like better is to do differential ps-like reports and system-wide (like vmstat) reports which leaves everything in your terminal scrollback buffer as in: https://github.com/c-blake/procs { written in the uncommonly efficient, expressive Nim programming language }.

Re: Explanation of everything you can see in htop/top on Linux (2019)

#45

Post by sedatk »

AnotherGoodName wrote: post #31

I appreciate the note on virtual memory not being reliable. This is what Windows task manager reports by default and it's terrible. Resident size is the most reliable metric. Anything else can be wrongfully inflated by things like harmless memory mapped files that won't actually hurt anything. eg. memory map 2GB of logfiles, it'll only be paged in if reading that portion of the logfile so isn't really using memory bu…

> This is what Windows task manager reports

Just to clarify, Windows Task Manager uses Private Working Set by default for process memory usage which does NOT include shared pages with other processes such as libraries or memory mapped files (hence the name “private”). It only shows the memory that maps to privately allocated physical memory per process. It’s probably closer to Resident Set on Unix.

You probably meant the memory usage in performance tab but I wanted to clarify in case people mistake it for all memory usage fields.

Re: Explanation of everything you can see in htop/top on Linux (2019)

#46

Post by kergonath »

justthetop wrote: post #21
FpUser wrote: post #18

Earlier quoted context omitted.

>"What good does it do to stick your head in the sand?" Get the fuck out. I do write for GPU as well. One does not replace the other.

For high performance work, gpus have replaced cpus a long time ago.

There is plenty of "high performance work" that still requires CPUs.

Re: Explanation of everything you can see in htop/top on Linux (2019)

#47

Post by d3Xt3r »

AnotherGoodName wrote: post #31

I appreciate the note on virtual memory not being reliable. This is what Windows task manager reports by default and it's terrible. Resident size is the most reliable metric. Anything else can be wrongfully inflated by things like harmless memory mapped files that won't actually hurt anything. eg. memory map 2GB of logfiles, it'll only be paged in if reading that portion of the logfile so isn't really using memory bu…

> Resident size is the most reliable metric

Actually, Proportional Set Size is more accurate than RSS. See: https://en.wikipedia.org/wiki/Proportional_set_size

Re: Explanation of everything you can see in htop/top on Linux (2019)

#48

Post by cb321 »

d3Xt3r wrote: post #47
AnotherGoodName wrote: post #31

I appreciate the note on virtual memory not being reliable. This is what Windows task manager reports by default and it's terrible. Resident size is the most reliable metric. Anything else can be wrongfully inflated by things like harmless memory mapped files that won't actually hurt anything. eg. memory map 2GB of logfiles, it'll only be paged in if reading that portion of the logfile so isn't really using memory bu…

> Resident size is the most reliable metric Actually, Proportional Set Size is more accurate than RSS. See: https://en.wikipedia.org/wiki/Proportional_set_size

`procs display` (mentioned elsethread https://news.ycombinator.com/item?id=48788167 ) supports PSS via its %M format code.

One issue with that relative to RSS is permissions. Historically, all procs could see the RSS used by procs of all other users (at least if they could see the PIDs at all). So, RSS requires no special permissions, but the Linux kernel team decided PSS should not be as promiscuous for whatever reasons (I didn't do a deep dive). So, I'm always having to do (the equivalent of) `sudo pu`.

Re: Explanation of everything you can see in htop/top on Linux (2019)

#49

Post by amelius »

JdeBP wrote: post #38
amelius wrote: post #17

Earlier quoted context omitted.

Nails and hammers are great but most of us have moved on to screws and screwdrivers. What good does it do to stick your head in the sand? CPUs are great for orchestrating work, GPUs are great for actually doing the work.

Screws have been around for about 3 millennia at this point. They have patently failed to obviate the use of nails. So by this analogy we can expect the 'Only GPUs do the work.' believers to be still promising this, any day now, about three thousand years hence. (-:

Software is getting more complicated and a lot of it depends on both cpu and gpu.

If you have a systems tool that gives an overview of resources used, then better monitor them both.

Imho failing to do so is not future-proof. Your opinion might differ.

Re: Explanation of everything you can see in htop/top on Linux (2019)

#50

Post by hinkley »

imrehg wrote: post #13

I've relatively recently migrated over to using btop[0], and it's the kind of modern interface, useful and informative, that I needed. As others mention it - it seems to shows the Watts used as well :) (and network, and GPU, and disks,....) [0]: https://github.com/aristocratos/btop

I still occasionally use alpine as a base image for containers and it looks like both doesn’t do musl so that’s out.
Post reply on HN