Processor Details in Linux: Check CPU, Memory & Disk Usage

Processor Details in Linux: How to Check CPU, Memory and Disk Usage
If your server performs poorly, you usually do not have a problem with all three resources together. Four commands will give you the answer: lscpu to get processor details in Linux, top to see current CPU usage, free -h to evaluate memory usage, and df -h to learn about disk space usage. Running these commands in the specified order allows to understand in minutes what kind of resource limits you have: cores, RAM, or disk space.
Below you will find the explanation of each command, the meaning of its output, and the cases where the obvious interpretation is wrong.
Which resource is the actual bottleneck?
Start with uptime, free -h, and df -h, and after that, interpret the output to decide which next command to run. If you see high load average and idle CPU, it means there is either disk I/O bottleneck or the hypervisor takes some resources, so top will not be very helpful.
Symptom | Command that confirms it | Typical interpretation |
|---|---|---|
Load average exceeds number of cores with high |
| Many CPU-bound processes; profile your application or provision more cores |
Load average is high with high |
| Disk I/O bottlenecks; discover which processes read/write to disk |
Load average is high with non-zero |
| Hypervisor scheduler steals CPU cycles from VM |
Almost no RAM available |
| Memory bottleneck; system swaps |
Write errors; |
| Full file system or exhausted inodes |
|
| Some process has an open file that has already been deleted |
Go through the above table in the order given. If one of the rows describes your problem, most likely this will be the actual bottleneck; otherwise, trying several options in parallel can be inefficient.
How do I get processor details in Linux?
Run lscpu. This command gives the information about CPU model, number of cores and threads, socket layout, cache sizes, and virtualization flags on one screen. The data is <a href="https://man7.org/linux/man-pages/man1/lscpu.1.html">taken from sysfs and /proc/cpuinfo</a> and formatted in human-readable way.
Example:
$ lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
CPU(s): 8
On-line CPU(s) list: 0-7
Vendor ID: GenuineIntel
Thread(s) per core: 2
Core(s) per socket: 4
Socket(s): 1
Caches (sum of all):
L3: 16 MiBTo get only the number of processing units, you can use nproc. It will print the count as a single number, which is helpful in scripts and for make -j$(nproc).
In addition, you can get raw data directly:
cat /proc/cpuinfo
grep "model name" /proc/cpuinfo | uniq<a href="https://man7.org/linux/man-pages/man5/proc_cpuinfo.5.html">The file /proc/cpuinfo has a block for each CPU</a>; on multicore systems, the blocks are repeated. uniq can be helpful when the goal is only the model name.
An important point for virtual machines: the architecture reported by the command can differ from that of physical machine since <a href="https://man7.org/linux/man-pages/man1/lscpu.1.html">it depends on the configuration of the guest OS</a>. According to the manpage, in virtual hardware lscpu may give the wrong values for topology (for example, cores per socket). Consider the CPU count correct and socket layout optional.
How do I check CPU usage in Linux?
Run top. The second line of the output splits the CPU time into several components; it gives more information than just the total CPU time: <a href="https://man7.org/linux/man-pages/man1/top.1.html">us is user processes running time, sy is kernel running time, wa is waiting time for I/O operations, and st is time stolen by the hypervisor</a>.
Example:
$ top
%Cpu(s): 12.4 us, 3.1 sy, 0.0 ni, 82.9 id, 1.4 wa, 0.0 hi, 0.2 si, 0.0 stKey notes in top:
Press
1to view CPU usage per core. If a single-threaded process uses one core of an 8-core machine, it may be seen as 12% CPU on the top line.Process can use more than 100% CPU in the
%CPUcolumn in SMP systems; a multithreaded process uses more than 100% CPU unlesstopis in Threads mode.To get non-interactive CPU usage snapshot, run
ps aux --sort=-%cpu | headto identify top CPU consumers.
The st component deserves special attention. It means the hypervisor steals CPU time from the VM, so you cannot save any CPU time using code optimization. Consistent steal time is a signal of the provider-side problems, not the application ones.
What does the load average actually mean?
The load averages (uptime or 1-, 5-, and 15-minute values in top) show the average number of tasks <a href="https://man7.org/linux/man-pages/man5/proc_loadavg.5.html">in the run queue (R state) or waiting for disk I/O (D state)</a>. Since I/O wait time is counted here, a high load average does not mean CPU shortage.
Example:
$ uptime
14:22:07 up 31 days, 4:12, 1 user, load average: 6.42, 5.98, 4.11To interpret the load average you need the number of cores from lscpu or nproc. Load average 6.42 on an 8-core server is normal; but the same load average on a 2-core VPS means there are tasks queuing. You need to compare the 1-minute load average with the 15-minute one to understand the trend: if it grows, there is current CPU pressure; if it falls, there is no pressure anymore.
How do I check memory usage in Linux?
Run free -h and look at the available column, not at free. According to the manual page, <a href="https://man7.org/linux/man-pages/man1/free.1.html">available means an estimate of memory available for allocation for new processes without swapping, accounting for page cache and for the fact that not all reclaimable slab memory will actually be reclaimed</a>.
Example:
$ free -h
total used free shared buff/cache available
Mem: 15Gi 4.2Gi 412Mi 128Mi 11Gi 10Gi
Swap: 2.0Gi 0B 2.0GiThe important note about free -h: small value of free memory looks alarming, but in most cases it's not a problem because there is much memory available. Most of the free memory is page cache; the kernel will release it quickly if it needs more memory for applications.
used is total minus available; it means the memory that already excludes reclaimable cache. buff/cache contains kernel buffers, page cache, and reclaimable slabs; on the long-run healthy systems, it is common that buff/cache occupies a lot of memory; but available is the key indicator.
To see per-process memory usage, use ps aux --sort=-%mem | head or in top RES column (non-swapped physical memory size).
Is the server swapping?
Run vmstat 1 and look at si and so columns; <a href="https://man7.org/linux/man-pages/man8/vmstat.8.html">they show how many pages were swapped in from and out to disk per second</a>. Having non-zero swpd total value is not always problematic since those pages were previously moved to the swap and no overhead is expected; but consistent activity in si and so means the server is short of RAM and is paying disk latency for it.
Example:
$ vmstat 1
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
2 1 51200 421884 182304 2841120 128 256 1840 2210 1420 3180 8 4 76 12 0Some additional tips: r shows the number of runnable processes, b shows the number of processes blocked waiting for I/O. High persistent b and low r indicate I/O bottleneck, not CPU shortage.
How do I check disk usage in Linux?
Run df -h and see which file system is full, and use du to find out the directories responsible. Do not try to do it vice versa because du will traverse all files starting from /, and it takes time.
Example:
$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/vda1 158G 149G 1.2G 100% /
/dev/vdb1 500G 204G 271G 43% /var/lib/dataNarrowing down, one level at a time:
du -h --max-depth=1 / | sort -h
du -h --max-depth=1 /var | sort -h
du -sh /var/log/*Use -x to limit du to the current filesystem; otherwise, du will traverse other filesystems and network mounts, so the sum will not match the output of df for the specific file system. If your filesystem is too small, consult our guide on <a href="https://orbitservers.io/blog/linux-format-hdd-how-to-partition-and-format-disk-drives">partitioning and formatting disk drives in Linux</a>.
If df -h gives available space but writes fail with "No space left on device" error, you need to check inode usage. Using -i parameter in df, you can <a href="https://www.gnu.org/software/coreutils/manual/html_node/df-invocation.html">see inode utilization instead of block one</a>; it is possible that the filesystem exhausted inodes even if blocks are available.
Example:
df -i
du --inodes -d 1 /var | sort -n<a href="https://www.gnu.org/software/coreutils/manual/html_node/du-invocation.html">The du --inodes parameter shows inode usage statistics</a>, so you can find the directories with many small files (session files or unrotated queue entries).
Why does df report the filesystem full when du disagrees?
The reason for this problem is that the process opened the file for writing and did not close it even after the deletion. In this case, the file system is not able to return the blocks to the pool and needs to wait for the process closing the file; du cannot see the file because its directory entry is already deleted, but df sees the blocks used. You can find open-but-deleted files with lsof +L1.
<a href="https://access.redhat.com/solutions/2316">The solution can include stopping and restarting the process to close file descriptors</a>, or restarting the service in general; you can truncate the log file (not delete it) to free the space right away since it keeps the inode and file descriptor and releases the blocks.
> /var/log/application.logCommon mistakes
Look at
freeinstead ofavailable, misinterpret the memory situationThink that high load average means CPU shortage; check
waintopbefore adding extra coresForget about
st; high steal time means provider-level contention, not the problem of your applicationRun
dufrom/without-x; it breaks consistency withdfbecause of filesystem crossingDelete the log file that is opened by some process; restart the service to free the space
Trust the VM-provided socket and core-per-socket topology in virtualized environment; CPU count is normally correct, topology is not
Check the usage only after the problem occurs; these commands are fast and can be periodically logged (via cron)
Frequently asked questions
How do I see how many CPU cores my server has? nproc prints the count as a single number; lscpu gives the same number (CPU(s)) plus threads per core and sockets, so you can understand how many physical cores you have.
What is the difference between /proc/cpuinfo and lscpu? /proc/cpuinfo is the raw kernel file with one block per logical CPU; lscpu is the parsed information from this file and sysfs.
Does a high buff/cache value mean I need more RAM? No; this is mostly page cache and reclaimable slabs; they are freed when the application asks for memory.
What is CPU steal time? It is the time when the hypervisor stole CPU cycles from your VM, reported in top and vmstat as st.
How do I check the size of one directory? Use du -sh /path/to/directory for one human-readable size, or use --max-depth=1 parameter to get per-level breakdown.
Which command should I run first when a server is slow? Start with uptime (load average), then free -h, then df -h. These three commands are fast and will help you to determine the next step (top, vmstat, or du).
Get started with Orbit Servers
Low-latency VPS, bare metal, and colocation across the US, EU, and APAC - provisioned instantly and built for performance-critical workloads.
Get startedRelated products
Written by
Julius