Htop Explained Visually(codeahoy.com)
codeahoy.com
Htop Explained Visually
https://codeahoy.com/2017/01/20/hhtop-explained-visually/
40 comments
and the other side of the coin is discussed here: https://peteris.rocks/blog/htop/
which explains htop programmatically :)
I thought it was already explained: https://news.ycombinator.com/item?id=13087904
But hey, everyone likes visual explanations ;)
But hey, everyone likes visual explanations ;)
Thanks for linking to that. This 'visual explanation' is hardly an explanation at all.
such a great tool, so easy to use, much better than top, though that is my own opinion
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.
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.
Maybe not malloc but mmap
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.
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.
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.
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.
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.
Hit.... f5
Sure. But a picture is worth a thousand words. Visual explanations are cool.
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.
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.
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.
If you have their display enabled htop will divide them down as well.
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.
I like these visual explanations though.
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.
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...
This stackoverflow has some pointers though: http://superuser.com/questions/806614/how-to-compress-or-hid...
wow, 768 cores is a lot of cores! you can try posting an issue here? https://github.com/hishamhm/htop
You obviously need a bigger screen
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?
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.
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.
Open `~/.config/htop/htoprc` and modify the line:
left_meters=AllCPUs Memory Swap
left_meters=CPU Memory Swap
Excellent, this worked!
Try reducing your cores to 16, then you'll be able to see some processes in the list!
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
1, 5 and 15 minutes is the most common intervals
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)
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)
Very well done! :+1: