Check CPU, memory and disk usage on a Linux server
By the end: You will have measurements to investigate whether a slowdown involves CPU, memory or disk. CPU does the processing, RAM is temporary working space, and disk stores files.
When a server slows down, first identify the resource involved. Memory pressure, CPU load, disk capacity and an application waiting for an external service are different problems. Record several measurements during the incident, together with their timestamps, instead of relying on a single screenshot.
Applies to: Ubuntu 24.04 LTS and Debian 13 with standard procps and GNU coreutils tools. These commands do not change settings, delete files or restart services. SSH access is required. If a tool is missing, do not run an arbitrary installation script during an incident.
The same slowdown can have different causes.
Record the measurement time and repeat the same checks during normal use.
- CPU: processing
Is the processor continually busy? Check load together with busy processes.
- RAM: working space
Check available memory together with ongoing swap activity.
- Disk: stored data
Check capacity, inodes and I/O separately; do not delete files at random.
A slow external service can also delay an application; not every issue needs a bigger package.
1. Record the time and processor count
First connect to the server with SSH. Every command in this guide runs on the server. Run one line at a time and record its output.
| Command | Information to expect |
|---|---|
date -Is | Measurement time and time zone offset |
uptime | Time since boot and three load averages |
nproc | Processing units available to this process |
There is no single “good” load value for every server. Compare measurements during the issue with normal use.
Run these commands on the server:
date -Is
uptime
nproc
The load averages in uptime cover the previous 1, 5 and 15 minutes. They are not CPU utilization percentages: runnable work and tasks in uninterruptible sleep can both contribute. Assess sustained high load alongside the processors visible to the server and the measurements below.
DCHost's VPS and VDS pages list the same packages. The listed CPU count does not mean that physical cores are exclusively assigned to you. Proxmox/KVM infrastructure alone is not an application performance guarantee.
2. Check available memory and swap activity
Use the server window. free -h displays memory in readable units. vmstat 1 5 produces five reports at one-second intervals; taking a few seconds is normal.
free -h
vmstat 1 5
Do not judge free output by the free column alone. Linux uses some memory as cache. The available column estimates how much memory can be used by new applications without swapping.
The first vmstat report calculates CPU and I/O rates over the time since boot; subsequent reports use each sample interval. Process and memory values reflect the current state. si and so show swap input/output, us and sy show CPU usage, and wa shows I/O wait. Persistently low available memory together with continuing swap activity warrants investigation. Data being present in swap is not, by itself, proof of a problem.
vmstat column | Plain meaning |
|---|---|
si / so | Data moving between RAM and swap |
us / sy | CPU use by applications and the kernel |
wa | CPU time waiting for I/O completion |
Check: The first report's CPU/I/O averages cover the time since boot. Compare later samples for the current trend. Swap is disk space used to assist memory; stored swap data alone is not a fault.
3. Check disk capacity and inodes separately
Disk size and file records have separate limits.
- Disk space: df -hT
Shows room for the total size of files. Look at the Use% column.
- Inodes: df -i
Shows use of file and directory records. Look at the IUse% column.
Check the filesystem holding the application data, not only the / filesystem.
We are checking two different limits:
- Disk space: Is there room for the total size of the files?
- Inodes: Is there capacity to record new files or directories?
One limit can be exhausted while the other still has room. That is why we run both commands.
df -hT
df -i
df -hT shows each filesystem's capacity and type. Check more than /: databases or application data may use separate filesystems. df -i shows inode usage, which relates to the number of files and directories. New files may fail even with free gigabytes if inodes are exhausted.
Do not delete logs, database files or backups before identifying what occupies the space. Deleting active files risks data loss and may not immediately release space if a process still holds them open. A package upgrade also does not prove that the guest filesystem expanded automatically; measure capacity again after a storage change.
Check: Use% shows disk space use; IUse% shows inode use. Inspect the filesystem holding your application data and record values approaching capacity, with the time.
4. Identify busy processes
In the server window: The first command sorts by CPU; the second sorts by memory. head -n 11 shows the first 11 lines, including the heading. PID identifies a running process.
Expected result: Process names and usage percentages appear. Seeing a process in this list does not mean you should stop it.
ps -eo pid,comm,%cpu,%mem --sort=-%cpu | head -n 11
ps -eo pid,comm,%cpu,%mem --sort=-%mem | head -n 11
These commands show process names and usage instead of full command lines, reducing the risk of exposing secrets passed as arguments. The CPU percentage from ps is not an instantaneous benchmark. Check whether the same process remains busy throughout the incident. High usage may be expected during a backup or batch job; do not terminate a process merely because it tops the list.
Choose the next investigation
| Findings observed together | What to investigate next |
|---|---|
Low available memory and ongoing swap activity | Application/database memory needs and concurrent jobs |
| Sustained high CPU and the same busy process | Application queries, queues and scheduled work |
| Capacity or inode exhaustion | Growing data, retention policies and storage planning |
Sustained high wa with low application CPU usage | Storage I/O, related processes and error logs |
| Normal resources but one slow page | That page's queries, API requests and application errors |
wa alone does not prove a disk fault; assess it alongside process and storage measurements. Waiting for an external API does not necessarily produce high wa either. After a change, repeat the same measurement under comparable use. Before upgrading based on a percentage, check that the new package increases the resource your application actually needs.
Final check: After a change, measure the same operation under comparable use. Check whether the customer-facing slowdown improved as well as whether the percentages changed.
Prepare evidence for support
Start with the service ID, incident time and time zone, affected operation, recent changes and short relevant command output. Remove hostnames and personal information before posting publicly. Do not share passwords, private keys or complete application configuration files. Read-only measurements require no rollback.