Htop is great!

One thing not mentioned in the article is you can interact with htop using the mouse, for example clicking on column headers to sort by that column, or selecting a process.

You can get get this mouse support for example by installing the gpm package, which enables the mouse support for the terminal.

gpm is only necessary for interacting with on a Linux TTY; if you are using it in an X terminal emulator, then you merely need a terminal emulator that supports the xterm mouse extensions.

As a consequence of trying htop after a long time, I got a reminder that VIRT is not related to RES. I noticed Libreoffice Calc with 29.7 GB of virtual memory and only 198 MB actually used. I wonder why LO made a malloc of nearly 30 GB, but memory is cheap especially because it's virtual.

The next one on the list is Firefox with 8.5 GB VIRT and 994 MB RES.

By the way, I've got 16 GB of RAM and no swap. Anyway all that empty memory between VIRT and RES doesn't go to swap, it's really virtual.

At a guess: LO is requesting (via mmap) enough memory up front to represent a full spreadsheet with data in every cell from A1 to the bottom-right corner, and letting the OS supply pages for the small parts of the spreadsheet that are actually accessed. AIUI this is a common technique for big sparse arrays.

RES isn't physical memory, either. I can happily have, say, 30 GB RES on a system with only 1 GB RAM (and no swap).

smem's measures - USS, unqiue set size (unshared pages) and PSS, proportional set size (shared pages divided by their share count, ie. how many tasks share them), are far more accurate and easier to reason about than RSS and VSS.

Well, RES is physical memory, it's just some places where it gets reported don't account for physical memory that is being shared between multiple processes.

If I have a process that says it's using 1GB of RES, then you can guarantee there is at least 1GB of physical memory in use. It just might also be in use by other things also reporting their own RES usage.

Maybe not malloc but mmap

I thought it was already explained: https://news.ycombinator.com/item?id=13087904

But hey, everyone likes visual explanations ;)

Thanks for linking to that. This 'visual explanation' is hardly an explanation at all.

and the other side of the coin is discussed here: https://peteris.rocks/blog/htop/ which explains htop programmatically :)

Htop is the first software I install on any new server. Just wished that they made iotop as awesome as htop :D

If you have the time and energy you can make iotop as awesome as htop.

Have a look at nmon

atop gives me everything htop does, with io information inline.

Worth reading is the builtin documentation ("h" or F1). More things there like memory used in virtualization, T, Z and D for processes, and "l" and "s" commands.

I like these visual explanations though.

Why is it "Tasks" at the top right? Shouldn't it be "Processes"?

Tasks = user threads, user processes, kernel threads

If you have their display enabled htop will divide them down as well.

such a great tool, so easy to use, much better than top, though that is my own opinion

Very well done! :+1:

what are units of load average?

I can't think of a good way to put it without just giving examples, so here goes:

    1.0 = 100% usage of a 1-core system
    1.0 = 50% usage of a 2-core system
    4.0 = 50% usage of an 8-core system
    8.0 = 100% usage of an 8-core system

And IIRC, load average is represented usually as 3 numbers, which are over the last 5, 10, and 15 minutes.

> And IIRC, load average is represented usually as 3 numbers, which are over the last 5, 10, and 15 minutes

1, 5 and 15 minutes is the most common intervals

The load average is calculated by the kernel (processes that display it just regurgitate the first 3 columns from /proc/loadavg); and yes, it is 1, 5, and 15 minutes.

It's the number of processes either running or waiting in the queue for CPU time. This is averaged over 5, 10, and 15 minutes.

Load of 0 means idle (nothing to run), load of 1 means e.g. one process running and nothing in the queue.

https://en.wikipedia.org/wiki/Load_(computing)

Hit.... f5

Sure. But a picture is worth a thousand words. Visual explanations are cool.

I love htop. But I can't figure out a way to disable the CPU monitors. I use a machine with 768 cores which makes it kind of useless.

Open `~/.config/htop/htoprc` and modify the line:

    left_meters=AllCPUs Memory Swap 

to be

    left_meters=CPU Memory Swap

That will replace the default CPU monitor with a single meter for the average across all cores. After that, you'll be able to customize things the standard way by pressing F2 within htop.

Excellent, this worked!

Oh that is a little awkward. You can configure it, but the configuration options appear below the CPU bars. So if there's already so many that your screen is filled, that's a bit moot.

This stackoverflow has some pointers though: http://superuser.com/questions/806614/how-to-compress-or-hid...

If you don't mind me asking what kind of machine has 768 cores?

Likely a machine with a group of Xeon Phi coprocessors, each a PCI card containing 64 fully-capable x86 cores: https://www-ssl.intel.com/content/www/us/en/processors/xeon/...

The idea is that you can run embarrassingly parallel workflows without needing to recode for a GPU; just launch processes with appropriate affinities. NERSC has compute clusters with thousands of these beasts. They make astronomers very happy.

Actually a NUMA system, an SGI UV: https://www.sgi.com/products/servers/uv/

It's a NUMA system, an SGI UV: https://www.sgi.com/products/servers/uv/ It actually has 2048 cores and ~7TB of memory.

You obviously need a bigger screen

wow, 768 cores is a lot of cores! you can try posting an issue here? https://github.com/hishamhm/htop

Try reducing your cores to 16, then you'll be able to see some processes in the list!

I don't have 768 machines, but considering one writes a hypothetical bug report, what would be the instructions to trigger or reproduce the bug?

Frontpage? Really?

I'm currently submitting my article "Less Explained Visually" ;)