# top vs. htop: Which Process Monitor Should You Use? The one-sentence difference: top is the process monitor that ships preinstalled on nearly every Linux system and works both interactively and in scripted batch mode, while htop is a more visual, mouse-friendly, scrollable monitor that you usually have to install yourself but that makes exploring, filtering, and killing processes far easier. The rule of thumb for bioinformatics: use htop for interactive digging on a machine you control, and use top when you need something guaranteed to be present, when you are on a locked-down cluster node, or when you need to capture output in a script or log file. This article walks through the top vs. htop decision the way it actually comes up during sequencing runs, genome assembly, and long pipeline monitoring, and it gives you the full difference between top and htop for bioinformatics work in one place. ## Why process monitoring matters in bioinformatics Bioinformatics is a discipline of long-running, memory-hungry jobs. A whole-genome alignment can run for days. A de novo assembly can climb past 100 GB of RAM. A single RNA-seq quantification step can spawn 32 threads that hammer every core on a shared node. When one of these jobs misbehaves, you need to see, quickly and accurately, which process is eating the CPU, how much resident memory it actually holds, and whether the machine is about to grind to a halt. Process monitors are the tools for that job, and on Linux they occupy the same role a task manager does on other operating systems. The broader context is that almost every serious bioinformatics workload runs on Linux, whether that is a university HPC cluster, a cloud virtual machine, a lab server, or a WSL environment on a Windows laptop. Fluency with core linux commands bioinformatics analysts use daily, including top, htop, ps, free, and df, separates people who merely run pipelines from people who can diagnose them. Knowing the difference between top and htop for bioinformatics work is one of the smallest, highest-yield skills in that toolbox, because these two programs answer your most common operational question: what is happening on this machine right now? The scenarios are predictable. A pipeline that normally takes six hours is still running after fourteen. A shared server becomes sluggish for everyone and you suspect your own job. A multi-threaded aligner seems to use only one core. A container dies silently and you suspect the kernel killed it for exceeding memory limits. In every case, the first diagnostic step is opening a monitor, and the monitor you reach for shapes how fast you get an answer. ## top, explained on its own terms top is part of the procps-ng package, a collection of Linux process and system utilities, and it comes preinstalled on essentially every Linux distribution you will encounter, from minimal cloud images to institutional HPC clusters. Type `top` and you get a full-screen, self-updating view that refreshes every 3.0 seconds by default. You can change the interval with `top -d 5` for a five-second refresh. ### Reading the top header The first block shows the current time, how long the machine has been up, how many users are logged in, and three load averages. Load average is the average number of tasks running or waiting to run over the last 1, 5, and 15 minutes, and on Linux it also includes tasks stuck in uninterruptible waits. A machine with 16 cores and a load average of 12 is healthy. The same load on a 4-core machine means something is queuing. The CPU line breaks processor time into categories you will learn to read at a glance: - **us**, user time, is code running in your own processes, such as an aligner or assembler. - **sy**, system time, is kernel work, often disk and network operations. - **id**, idle, is spare capacity. - **wa**, I/O wait, is time the CPU spends waiting on disk or network reads. A high wa value with low us often means your pipeline is input or output bound, not compute bound. - **st**, steal time, appears on cloud virtual machines and shows time the hypervisor gave to other tenants. Persistent steal time on a cloud instance means you are being throttled. The memory lines show total, free, used, and buff/cache amounts. A common source of panic is seeing "free" memory near zero on a server, when in reality most of that memory sits in the page cache and is instantly reclaimable. The **avail** column is the honest number to look at. ### Reading the process table The main table lists one line per process with columns that matter enormously in bioinformatics: - **PID** is the process identifier you use to target commands. - **USER** shows which account owns the job, which matters on shared servers. - **VIRT** is the total virtual address space the process has reserved. This number can be far larger than what the process actually uses, because libraries, mapped files, and reserved-but-untouched allocations all count. - **RES** is resident memory, the physical RAM the process is actively holding. This is the number to watch when deciding whether a job will exhaust a node. - **SHR** is shared memory, largely shared libraries. - **%CPU** is processor use summed across all cores, so a 16-thread Bowtie2 job can show 1600%. - **%MEM** is RES as a fraction of physical RAM. - **TIME+** accumulates actual processor time consumed. - **COMMAND** shows the program name, and pressing **c** toggles between the bare name and the full command line, which is how you distinguish one BWA run from another. ### The keys that matter in interactive top Press **h** for help, and learn a short list of keys: - **P** sorts by CPU use, the default view and the right view for most compute troubleshooting. - **M** sorts by memory use, the right view when a machine is swapping or an assembly is ballooning. - **1** toggles per-core CPU bars, which reveal whether a job is truly parallel or pinned to a single core. - **H** toggles between process-level and thread-level views, which shows you exactly how many worker threads a program spawned. - **u** filters the display to one user, essential on shared systems. - **k** kills a process. top prompts for a signal, defaults to SIGTERM, which asks the program to shut down cleanly so it can close files and remove temporary data. - **r** renices a process, lowering or raising its scheduling priority. Renicing someone else's heavy job downward is friendlier than killing it. - **f** opens the field manager, where you can add columns such as SWAP, CODE, or DATA. - **V** switches to a forest view that indents child processes under their parents. - **W** writes your current layout to `~/.toprc`, so your column set and sort order persist between sessions. ### top in batch mode, the feature htop lacks The single strongest reason to learn when to use top is `top -b`, batch mode, which prints snapshots to standard output instead of drawing a screen. This turns top into a data source rather than a dashboard: ``` top -b -n 1 -p 47821 ``` prints one snapshot for process 47821, which is exactly what you want inside a script, a cron job, or a log file. A common pattern for documenting resource use of a long job, useful for a methods section or a capacity-planning note, is: ``` top -b -d 300 -n 96 -p 47821 > mem_log.txt ``` That records one snapshot every five minutes for eight hours. You can also redirect a single snapshot into a text file to attach to a bug report. Because procps-ng top exists on essentially every Linux system, scripts that depend on it run anywhere, including minimal containers and old cluster nodes where nothing else is installed. The honest weaknesses of top: the default interface is dense and cryptic, you cannot scroll the process list with arrow keys in the classic interface, finding a specific process by name is clumsy, and killing several processes at once means repeating the kill sequence each time. These gaps are exactly where htop built its reputation. ## htop, explained on its own terms htop is an independently developed, open-source process monitor built on the ncurses text user interface library. It reads the same kernel data from `/proc` that top reads, so the underlying information is the same, but the presentation is dramatically better for exploration. The trade-off is availability. htop is not preinstalled on most minimal server images, is frequently absent from HPC cluster nodes, and does not ship with macOS, where you would install it through Homebrew. ### The htop interface Launch htop and you see three colored bar meters at the top, typically one per CPU core, plus memory and swap bars, a load average readout, and a task count. The core bars are usually green for user time, red for kernel time, and blue for low-priority nice time. The key structural difference from top is that htop is a scrolling, navigable list. Arrow keys, Page Up, and Page Down move through all processes, not just the first screenful. The function keys do most of the work: - **F1** opens help. - **F2** opens setup, where you configure meters, column sets, colors, and display options. htop saves your layout automatically in `~/.config/htop/htoprc`. - **F3** searches forward for a process name. Pressing F3 repeatedly jumps to the next match. - **F4** applies an incremental filter, showing only processes whose names match a string. Typing `sam` narrows the view to every samtools process on the node, which is the fastest way to watch a whole pipeline at once. - **F5** toggles tree view, which indents child processes under their parents. - **F6** changes the sort column. - **F7** and **F8** renice a process up and down in priority. - **F9** opens a kill menu where you choose the signal, with SIGTERM as the sensible default. - **F10** quits. Two habits make htop powerful for pipeline work. First, press **space** to tag multiple processes, then press F9 once to signal all of them together. When a stranded pipeline leaves five zombie worker processes behind, one tagged kill clears them. Second, use F5 tree view while a workflow engine such as Nextflow or Snakemake is running. You will see the workflow manager process at the root, its currently executing rule or process beneath it, and each tool invocation as a child. This immediately answers questions that flat process lists obscure, such as which step of a pipeline spawned the process that is thrashing the disk, or whether a job actually launched the 12 worker threads you requested. htop also responds to the mouse in most terminal emulators, so you can click column headers to sort and click process entries to select them. On a laptop this feels natural. Over a laggy SSH connection you may prefer the keyboard. ### Thread display and the numbers htop shows the individual threads of each process as separate lines by default, in a lighter shade, with kernel threads in grey. This matters when you are verifying parallelism. If you launched an aligner with four threads and htop shows four busy child lines, your threading works. If it shows one, you have a configuration problem. Press **H** to collapse user threads back into their parent process when the thread list gets noisy, and **K** to hide kernel threads. The command-line flags are handy for quick launches: `htop -u yourusername` shows only your processes, `htop -p 47821` focuses on one process, `htop -t` starts in tree view, and `htop -s PERCENT_MEM` starts sorted by memory. ### Getting htop where you need it Three practical installation routes, in the order bioinformaticians usually try them: 1. Ask the cluster whether htop is available as an environment module. Many HPC sites provide it through their module system, so a command like `module load htop` makes it appear without any installation rights on your part. 2. Install it in userspace with a conda-based package manager, for example `mamba install -c conda-forge htop`, which works on any system where you already use conda for bioinformatics environments and requires no administrator privileges. 3. On systems you administer, use the system package manager, for example `sudo apt install htop` on Debian-based distributions. If htop fails to start over SSH from a Windows terminal with a terminal-related error, check that your terminal type is set to something standard such as `TERM=xterm`, because htop depends on terminal capability data to draw its interface. ## The side-by-side comparison ![Comparison table mapping sorting, filtering, tree view, thread view and killing several processes to the top key and the htop key or action.](/article-images/illustrations/top-vs-htop-for-bioinformatics-interactive-keys.webp) | Aspect | top | htop | |--|--|--| | Preinstalled on Linux | Yes, on essentially every distribution | Rarely, must be installed or loaded as a module | | Installation friction | None | Low for a conda user, requires privileges or modules otherwise | | Interface style | Dense text table, classic Unix | Colored meters, navigable list, configurable | | Scrolling the process list | Not in the classic interface | Full keyboard and mouse scrolling | | Tree view of parent and child processes | Forest view toggle, limited | Strong tree view, ideal for pipeline processes | | Search and filter | Clumsy, user filter only | Fast incremental name filter and search | | Killing multiple processes | One at a time | Tag several, kill in one action | | Thread-level view | Toggle with H | Shown by default, hide with H | | Per-core CPU display | Toggle with 1 | Shown by default, configurable meters | | Mouse support | No | Yes in most terminals | | Batch and scripted output | Excellent, `-b` mode is a standard data source | None, htop is interactive by design | | Configuration persistence | `~/.toprc`, saved only when you press W | `~/.config/htop/htoprc`, saved automatically | | Memory and CPU accounting | Reads `/proc`, standard procps-ng behavior | Reads `/proc`, small differences in memory values can appear between the two tools | | Resource overhead of running it | Negligible | Negligible | | macOS availability | Yes, a different BSD-flavored top ships by default | Via Homebrew, not preinstalled | | Works in a minimal Docker container | Yes | Only if the image includes it | | Best fit | Scripts, logs, locked-down or unfamiliar systems | Interactive exploration on machines you control | Read the table column by column and the top vs. htop question resolves itself. The rows where top wins are about availability and automation. The rows where htop wins are about interactive speed and clarity. Neither tool loses on correctness, because both read the same kernel data. ## top vs. htop for bioinformatics: the criteria that decide real choices Availability. On a cluster compute node you have reached through a scheduler, on a collaborator's server, inside a slim Docker image running your pipeline, or on an old appliance running a sequencer's secondary analysis, the safe assumption is that only top exists. The single most useful habit in linux for bioinformatics work is being fully competent in top, because it is the one tool guaranteed to be present everywhere Linux runs. htop's availability is good on personal and lab machines you administer and spotty everywhere else. Scriptability. Resource documentation is a growing expectation in computational methods, and top is the tool that provides it. The batch flag `top -b -n 1` is the standard way to capture a machine snapshot from a script, and pipelines that log their own peak memory use typically wrap this pattern. htop has no batch mode and is not designed for one. If your goal is a file full of timestamps and memory readings, the choice is made for you. Interactive diagnosis. The reverse holds when your goal is to understand a live situation. Filtering to samtools processes with one keypress, seeing the pipeline tree, tagging three stranded workers and killing them together, and scrolling through 400 processes to find the one misbehaving job are all several times faster in htop. Once analysts adopt htop, they rarely return to top for interactive work, and the main reason they keep top around is that some servers they touch do not have htop installed. Shared-server etiquette. On a lab server used by several students, htop's user filter (`htop -u`) and top's user filter (**u** key) both scope the view to your own jobs. On such systems the more relevant skill is knowing how to inspect without disturbing others. Renicing a heavy job to a lower priority is usually the cooperative move, and both tools support it. Accuracy and consistency. Both tools read the same `/proc` filesystem, so both are accurate. Two known wrinkles deserve attention. First, %CPU in both tools sums across threads, so a 24-thread process can legitimately report 2400%, which startles people expecting a percentage capped at 100. Second, small discrepancies can appear between the tools' RES and %MEM values because they compute memory figures from `/proc` slightly differently. When you need a defensible number for a report, snapshot it with top in batch mode and state which tool produced the reading. Overhead. Both monitors consume negligible resources compared with any real bioinformatics workload. Choosing between them on performance grounds is unnecessary. ## Worked scenarios ### Scenario 1, verifying that an aligner is using its threads You launched a read aligner with 16 threads on a 32-core server and it feels slow. Open htop, press F4, and filter to the aligner's name. The core bars tell the story immediately: if 16 bars run hot, threading works and the bottleneck is elsewhere, possibly I/O, visible as high wa in a top header. If one bar runs hot, check the thread view. A single busy child line under the process means the program fell back to single-threaded mode, often because of a piping step in the command or an automatic thread-count heuristic. Fix the invocation, not the monitor. In top the same check is `top -H -p PID`, which switches to thread-level view for one process, and **1** to show per-core bars. It works, but you will spend more keystrokes getting there. ### Scenario 2, watching an assembly approach the memory ceiling A de novo assembly on a 64 GB workstation is climbing. Sort by memory in htop with F6, watch the RES column of the assembly process grow, and compare it to the memory bar. The decision point is whether RES is approaching the total while free memory vanishes. If you estimate the job will exceed physical RAM, you have options before the kernel intervenes: reduce the assembly's memory footprint through its own parameters, move the job to a larger machine, or kill it gracefully with F9 and SIGTERM so it can clean up its temporary files. An out-of-memory kill by the kernel is abrupt and often wastes hours of work, because the process gets no chance to write checkpoints. Note that VIRT grows constantly and means nothing by itself. Programs reserve address space they never touch. RES is the number that predicts trouble. ### Scenario 3, cleaning up after a crashed pipeline A Nextflow run died mid-execution, leaving a dozen worker processes alive and a disk filling with intermediate files. In htop, press F4, filter to the tool's name, press space on each orphan, then F9 and confirm with SIGTERM. Then press F5 and check the tree to confirm the parent is gone. The same cleanup in top means running k on each PID in sequence and retyping the filter between kills. This is the clearest practical difference between the two tools, and it is why many analysts install htop the first day they get an account on a new server. ### Scenario 4, documenting resource use for a methods section or capacity plan ![Four steps showing a top batch command run every five minutes into a log, then reading the peak resident memory for a scheduler request.](/article-images/illustrations/top-vs-htop-for-bioinformatics-batch-logging.webp) You want to know how much memory a variant-calling step really needs before requesting resources on a cluster. Run the job on a smaller test dataset with a logging loop: ``` while : ; do top -b -n 1 -p 47821 | tail -n 3 >> peak_mem.log ; sleep 300 ; done ``` Every five minutes the log gains one line of resident memory for that process. Over a full run you learn the peak and the profile, which converts directly into scheduler resource requests such as a per-job memory limit. htop cannot produce this record at all. This scenario, more than any other, answers when to use top. ### Scenario 5, teaching or troubleshooting on an unfamiliar machine A colleague sends you into a server you have never touched, with no idea what is installed. Type `top`. It is there. Everything in the first half of this article works. If htop happens to be installed, use it for speed. If not, the top key list is enough: **P** for CPU sorting, **M** for memory, **u** to scope to a user, **k** to kill, **1** for per-core, **H** for threads. This is the strongest argument for the htop-vs-top question when you must pick one to master first: learn top, because it travels everywhere, then learn htop to work faster where it is available. ## Companion commands that pair with either monitor Process monitors answer the CPU and RAM questions, but a complete diagnostic pass on a bioinformatics machine uses a few more standard utilities: - `free -h` gives a human-readable memory summary with the available-memory figure, useful to double-check what the monitor's bar implies. - `df -h` shows free disk space per filesystem. Full scratch disks are among the most common silent causes of pipeline failure, and neither monitor reports disk capacity. - `du -sh /path/to/dir` measures how large a project directory or output folder has grown. - `ps aux | grep samtools` lists matching processes statically, which is how you capture PIDs for a script without opening a monitor. - `nvidia-smi` reports GPU memory and utilization. Neither top nor htop shows GPU state, which matters for deep-learning workloads and GPU-accelerated tools. - `uptime` gives load averages in one line, the quickest shared-server health check. - `nice` and `renice` adjust scheduling priority from the shell, complementing the in-monitor versions of the same operation. A reasonable weekly rhythm on a lab server is to open htop for a live look, `df -h` for disk, and `free -h` for memory headroom before launching anything large. ## Common Mistakes and Limitations **Treating VIRT as memory in use.** VIRT counts reserved address space, which routinely reaches tens of gigabytes for programs that never touch most of it. Watch RES and %MEM instead. This single misreading causes most false alarms about memory hogs. **Misreading %CPU above 100.** Both tools sum CPU use across all threads and cores. A 32-thread process at full tilt reports roughly 3200%. The number is correct. If a process shows far less than its requested thread count in %CPU, that is the real finding, and it usually means the program or the input format limits parallelism. **Missing transient spikes.** top refreshes every 3 seconds and htop roughly every 1.5 seconds by default. A memory spike lasting half a second between refreshes is invisible. If a job dies with an out-of-memory signal and both monitors show moderate usage at the moment you look, the spike happened between samples. Periodic batch-mode logging with top, or a dedicated logger, is the answer, not tighter staring at a live screen. **Killing with excessive force.** The default signal in both tools is SIGTERM, which lets a program shut down cleanly, flush files, and remove temporary data. Sending SIGKILL, signal 9, should be a last resort for a process that ignored termination, because killed jobs often leave lock files, truncated outputs, and gigabytes of scratch data behind. **Monitoring the wrong machine.** On an HPC cluster, a job submitted through a scheduler such as SLURM runs on a compute node, not the login node where you typed the command. Running htop on the login node shows you nothing about your job. You must connect to the assigned compute node, commonly through SSH using the node name the scheduler reports, and monitor there. As a matter of etiquette and often policy, keep interactive monitoring sessions short and light on login nodes. **Confusing free memory with available memory.** A server showing a few gigabytes free is usually fine, because the kernel reclaims page cache on demand. Look at the available figure, in top's header or in `free -h`, before concluding that memory is exhausted. **Expecting GPU or disk-capacity visibility.** These monitors cover CPU, memory, and process state. Disk capacity, GPU load, network throughput, and queue position in a scheduler all require their own commands. **Over-relying on either tool for I/O diagnosis.** A job that reads a large file slowly shows low CPU use, which looks like idleness. The wa column in top hints at I/O wait, but the definitive tool for disk throughput is a dedicated I/O monitor. If a pipeline crawls with idle cores, suspect disk rather than processor. **Assuming the memory numbers will match exactly between tools.** Because top and htop compute memory figures from `/proc` through slightly different paths, small differences in RES and %MEM for the same process are normal and documented behavior in htop. Pick one tool for any comparison you plan to report, and note which one you used. **Leaving monitors running unattended.** A live monitor on a shared login node consumes a small but nonzero share of resources and clutters the screen of anyone who shares the terminal. Quit when you have your answer. ## Frequently Asked Questions ### Is htop better than top for bioinformatics? For interactive work, yes, htop is better for most people, because scrolling, filtering, tree view, and tagging multiple processes are all faster and clearer. For scripted logging, minimal containers, and unfamiliar or locked-down systems, top is better or is the only option. Most experienced analysts learn both and use htop interactively and top for anything automated. ### Does htop use more resources than top? Both use negligible resources compared with any real bioinformatics job. The difference is far too small to influence the choice. Choose based on availability and workflow, not overhead. ### Why do the CPU and memory numbers differ between top and htop for the same job? CPU percentages in both tools sum across all threads, so a 16-thread job can show 1600%, and small memory-accounting differences exist because the tools compute RES and %MEM from `/proc` through slightly different routes. Both are accurate within their own conventions. Use one tool consistently when you need comparable numbers. ### How do I kill a stuck BLAST or alignment job from the monitor? Select the process, press **k** in top or F9 in htop, and confirm the default SIGTERM signal. In htop you can tag several processes with space and kill them in one action. Only escalate to signal 9 if the process ignores SIGTERM, since a clean termination gives the program a chance to remove temporary files. ### Can I use top or htop on an HPC cluster or in a Docker container? top works essentially everywhere, including minimal containers and locked-down cluster nodes, because procps-ng ships with the system. htop works if the cluster provides it as a module, if you install it in a userspace conda environment, or if your container image includes it. On clusters, monitor on the compute node running your job, not the login node. ### Which monitor should I learn first for Linux for bioinformatics? Learn top first. It is preinstalled on every Linux system you will log into, it covers all the essential keys for sorting, filtering, and killing, and its batch mode is the standard way to document resource use in scripts. Add htop afterward for faster interactive diagnosis on the machines where it is available. ## Further Reading - [Advancements in rapid sludge moisture content detection: A comprehensive review of methods and online monitoring techniques.](https://pubmed.ncbi.nlm.nih.gov/42994235/) - [AntLink: A Biomimicry-Orientated System for Workflow Improvement at an Automobile Aftersales Service Centre.](https://pubmed.ncbi.nlm.nih.gov/42930307/) - [Real-time intelligence framework for microplastic monitoring and coastal resilience.](https://pubmed.ncbi.nlm.nih.gov/42909102/) - [Controlling ammonia in aquatic environments: a critical review linking monitoring, prevention, and recovery.](https://pubmed.ncbi.nlm.nih.gov/42905374/)