What Is the Difference Between VIRT and RES in htop?

When monitoring system performance in Linux using htop, understanding memory consumption is crucial for troubleshooting resource bottlenecks. Two of the most commonly misunderstood columns are VIRT (Virtual Memory) and RES (Resident Memory). While both metrics reflect a process’s memory footprint, they represent fundamentally different things: VIRT measures the total memory a process thinks it has access to, including allocated but unused space and swapped data, whereas RES measures the actual, physical RAM the process is currently consuming. Distinguishing between the two helps system administrators accurately identify whether a process is genuinely draining system resources or simply reserving address space.

Understanding VIRT (Virtual Memory)

The VIRT column represents the total virtual memory address space allocated to a process. It is a theoretical figure that includes everything the process has mapped into its environment, regardless of whether it is actively occupying physical RAM.

VIRT is composed of:

• The process’s executable code.
• All data structures, heaps, and stacks.
• Shared libraries used by the process (even if they are already loaded into memory by other applications).
• Memory that has been requested and allocated by the application but not yet written to.
• Memory that has been swapped out to disk.

Because Linux uses an “optimistic” memory allocation strategy called overcommitting, processes can request massive amounts of virtual memory that they may never actually use. Consequently, a high VIRT value is rarely a cause for concern on its own.

Understanding RES (Resident Memory)

The RES column stands for Resident Set Size. This metric represents the actual, physical RAM that a process is actively consuming at that exact moment. If you want to know how much of your hardware’s RAM a specific application is draining, RES is the metric you should look at.

RES is composed of:

• The process’s private physical memory (the data it is actively computing).
• The used portions of shared libraries that are currently resident in physical RAM.

Unlike VIRT, RES cannot be overcommitted. It corresponds directly to physical hardware limitations. If the total RES of all running processes approaches the limit of your physical RAM, the system will begin swapping data to disk or trigger the Out-Of-Memory (OOM) killer to terminate processes.

Key Differences at a Glance

The relationship between these two columns can be best understood by comparing how they handle allocation, hardware impact, and shared resources:

• Physical vs. Theoretical: VIRT is a representation of the process’s total requested address space (virtual), while RES is a strict measurement of physical hardware utilization (RAM).
• The Impact of Swapping: If a portion of a process is inactive and the Linux kernel moves it to swap space on the hard drive, that memory remains counted in the VIRT column but is subtracted from the RES column.
• The Shared Library Factor: If five different processes use the same 10 MB shared library, all five processes will show an additional 10 MB in their VIRT columns. However, that library is only loaded into physical RAM once, meaning the RES columns will share that weight rather than replicating it. This can sometimes make the sum of all RES columns appear higher than the actual RAM utilization of the system.

Which Metric Should You Monitor?

When debugging a slow system or investigating a suspected memory leak, RES is almost always the more important metric to watch. A high RES value means the process is actively taking up physical space that other applications might need.

On the other hand, a massive VIRT value alongside a tiny RES value usually just indicates that a program (such as a Java application or a database) has pre-allocated a large address space for future efficiency, which is standard behavior and safe to ignore.