--- title: "How to check CPU, RAM, disk and network usage on Linux | StreetHosting" description: "Find your VPS bottleneck in minutes with top, free, vmstat, df, iostat and ss: what each number means and which command to run for each symptom." url: "https://streethosting.com.br/en/guides/vps/check-cpu-ram-disk-network-linux" type: "page" language: "en-US" --- VPS · 10 min · Beginner Published on Sep 28, 2026 · Updated on Sep 28, 2026 # Quick terminal diagnostics: CPU, memory, disk and network on your VPS When a VPS slows down, each right command rules out one hypothesis. Here is a one-minute checklist and how to read load average, available memory, disk latency and network connections. By [Equipe StreetHosting](https://streethosting.com.br/en/autores#equipe-streethosting) · StreetHosting infrastructure and support team [Hardware and datacenter](https://streethosting.com.br/en/guides/topics/hardware) [Linux administration](https://streethosting.com.br/en/guides/topics/linux) Summarize with: [](https://chat.openai.com/?q=Summarize%20the%20key%20points%20of%20this%20StreetHosting%20guide%3A%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Fvps%2Fcheck-cpu-ram-disk-network-linux.%20Highlight%20the%20step-by-step%20instructions%2C%20the%20prerequisites%20and%20the%20most%20common%20mistakes. "ChatGPT") [](https://claude.ai/new?q=Summarize%20the%20key%20points%20of%20this%20StreetHosting%20guide%3A%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Fvps%2Fcheck-cpu-ram-disk-network-linux.%20Highlight%20the%20step-by-step%20instructions%2C%20the%20prerequisites%20and%20the%20most%20common%20mistakes. "Claude") [](https://www.google.com/search?udm=50&aep=11&q=Summarize%20the%20key%20points%20of%20this%20StreetHosting%20guide%3A%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Fvps%2Fcheck-cpu-ram-disk-network-linux.%20Highlight%20the%20step-by-step%20instructions%2C%20the%20prerequisites%20and%20the%20most%20common%20mistakes. "Google AI Mode") [](https://x.com/i/grok?text=Summarize%20the%20key%20points%20of%20this%20StreetHosting%20guide%3A%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Fvps%2Fcheck-cpu-ram-disk-network-linux.%20Highlight%20the%20step-by-step%20instructions%2C%20the%20prerequisites%20and%20the%20most%20common%20mistakes. "Grok") [](https://www.perplexity.ai/search/new?q=Summarize%20the%20key%20points%20of%20this%20StreetHosting%20guide%3A%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Fvps%2Fcheck-cpu-ram-disk-network-linux.%20Highlight%20the%20step-by-step%20instructions%2C%20the%20prerequisites%20and%20the%20most%20common%20mistakes. "Perplexity") Share: [](https://x.com/intent/tweet?text=How%20to%20check%20CPU%2C%20RAM%2C%20disk%20and%20network%20usage%20on%20Linux&url=https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Fvps%2Fcheck-cpu-ram-disk-network-linux "Share on X") [](https://www.facebook.com/sharer/sharer.php?u=https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Fvps%2Fcheck-cpu-ram-disk-network-linux "Share on Facebook") [](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Fvps%2Fcheck-cpu-ram-disk-network-linux "Share on LinkedIn") [](https://wa.me/?text=How%20to%20check%20CPU%2C%20RAM%2C%20disk%20and%20network%20usage%20on%20Linux%20https%3A%2F%2Fstreethosting.com.br%2Fen%2Fguides%2Fvps%2Fcheck-cpu-ram-disk-network-linux "Share on WhatsApp") For agents: Copy as Markdown [.md](https://streethosting.com.br/en/guides/vps/check-cpu-ram-disk-network-linux.md) In this guide 7 sections * [One-minute checklist](https://streethosting.com.br/en/guides/vps/check-cpu-ram-disk-network-linux#roteiro) * [CPU: usage, load average and steal](https://streethosting.com.br/en/guides/vps/check-cpu-ram-disk-network-linux#cpu) * [Memory: what real usage looks like](https://streethosting.com.br/en/guides/vps/check-cpu-ram-disk-network-linux#memoria) * [Disk: space and performance](https://streethosting.com.br/en/guides/vps/check-cpu-ram-disk-network-linux#disco) * [Network: interfaces, ports and connections](https://streethosting.com.br/en/guides/vps/check-cpu-ram-disk-network-linux#rede) * [Symptom, command and likely cause](https://streethosting.com.br/en/guides/vps/check-cpu-ram-disk-network-linux#sintomas) * [When the problem is a lack of resources](https://streethosting.com.br/en/guides/vps/check-cpu-ram-disk-network-linux#falta-recurso) Quick answer To **check CPU, RAM, disk and network on Linux** right now, use `uptime` and `top` for load and processes, `free -h` for memory (look at the available column), `df -h` and `iostat -xz 1` for disk space and latency, and `ss -tulpn` with `ip -s link` for ports, connections and network errors. Follow that order and in one minute you know which resource is at its limit. ## One-minute checklist[](https://streethosting.com.br/en/guides/vps/check-cpu-ram-disk-network-linux#roteiro) When a VPS slows down, the temptation is to open htop and stare at the list moving. A fixed checklist is faster: each command rules out one hypothesis, and in one minute you know whether the bottleneck is CPU, memory, disk or network. First, install the sysstat package, which brings iostat, mpstat, pidstat and sar: `sudo apt install -y sysstat htop` 1. `uptime`: load average over 1, 5 and 15 minutes. Compare it with the vCPU count shown by `nproc`. 2. `sudo dmesg -T | tail -20`: recent kernel errors, such as the OOM killer and disk failures. 3. `vmstat 1 5`: process queue, swap in use and disk wait on a single screen. 4. `mpstat -P ALL 1 3`: usage of each core, including iowait and steal. 5. `free -h`: memory that is actually available. 6. `iostat -xz 1 3`: latency and queue for each disk. 7. `sar -n DEV 1 3`: inbound and outbound traffic per interface. 8. `top` or `htop`: who is consuming, now that you already know what. The order matters. Starting with top shows the heaviest process, but it does not tell you whether that process is the cause or the victim. A database at the top of the list may just be waiting on a slow disk, and optimizing the database would fix nothing. In commands with numbers at the end, like 1 5, the first is the interval in seconds and the second is the number of samples. In vmstat and iostat, the first line is the average since boot; read the following ones, which show what is happening now. ## CPU: usage, load average and steal[](https://streethosting.com.br/en/guides/vps/check-cpu-ram-disk-network-linux#cpu) The load average shown by uptime has three averages, over 1, 5 and 15 minutes, of the number of processes running or waiting to run. On Linux, processes stuck waiting for disk count too. The number only makes sense compared with the total vCPU count: a load of 2 on a 2 vCPU VPS is a full queue; on 8 vCPUs there is plenty of headroom. If the 1-minute average is far above the 15-minute one, the problem has just started. In top, the line starting with %Cpu(s) summarizes processor usage, and each field tells part of the story: * **us and sy:** time spent in programs and in the kernel. High us is the application working; persistently high sy can be an excess of system calls or network interrupts. * **wa (iowait):** CPU idle while waiting for the disk. If this number is high, the bottleneck is I/O, not the processor. * **st (steal):** time when the VM wanted CPU and the hypervisor did not deliver it. It only exists on virtual machines and is explained in [what CPU steal is on a VPS](https://streethosting.com.br/en/guides/vps/what-is-cpu-steal-vps). * **id:** idle time. id near zero with high us is a truly saturated CPU. Inside top, the 1 key splits the cores, P sorts by CPU and M by memory. The per-core view matters: a single-threaded process pinned at 100% of one core shows up as 25% of the total on a 4 vCPU VPS, and goes unnoticed if you only look at the average. To confirm outside top: `mpstat -P ALL 1 3 pidstat -u 1 5 ps aux --sort=-%cpu | head -n 10` mpstat repeats the per-core analysis, with separate %iowait and %steal columns. pidstat shows who used CPU in each second, which catches short-lived processes that vanish before you open top, such as cron scripts. This guide is about the snapshot of the moment; to follow the VPS continuously, with charts and history, see [monitoring resources with htop and Netdata](https://streethosting.com.br/en/guides/vps/monitor-vps-resources-htop-netdata). ## Memory: what real usage looks like[](https://streethosting.com.br/en/guides/vps/check-cpu-ram-disk-network-linux#memoria) free -h is the most misread command on Linux. Sample output on a 4 GB VPS: ` total used free shared buff/cache available Mem: 3.8Gi 1.7Gi 240Mi 12Mi 1.9Gi 1.9Gi Swap: 2.0Gi 0B 2.0Gi` The column that matters is available, not free. Linux uses spare memory as disk cache (buff/cache) and hands that space back the instant a program asks for it. Low free with high available is a healthy machine making use of its RAM. The warning sign is low available, around 10% of the total. `swapon --show vmstat 1 5 ps aux --sort=-%mem | head -n 10` Swap that is occupied but idle is not a problem: those are old pages the kernel moved out of RAM. The problem shows up in the si and so columns of vmstat, which show swapping to and from disk per second. If they stay non-zero all the time, the system is swapping memory to disk right now, and everything gets slow. Swap keeps the service from going down during a spike, but it does not replace RAM; the limits are covered in [setting up swap on Ubuntu on your VPS](https://streethosting.com.br/en/guides/vps/set-up-swap-ubuntu-vps). In the ps output, the RSS column shows how much physical memory each process occupies, in KB. When memory runs out completely, the kernel picks a process and kills it. The service seems to have crashed on its own, and the application log says nothing. The proof is in the kernel log: `sudo dmesg -T | grep -i -E "out of memory|killed process" sudo journalctl -k -b -1 | grep -i oom # previous boot, if the VPS rebooted` ## Disk: space and performance[](https://streethosting.com.br/en/guides/vps/check-cpu-ram-disk-network-linux#disco) Disk answers two different questions: is there still space? And is it responding fast? Start with space: `df -h df -i lsblk` df -h shows space per filesystem and df -i shows inodes, which are the file entries. A disk with space to spare and inodes at 100% refuses to create files just the same, with the same disk full error. If either one passed 85%, the next step is finding the culprit, as shown in [finding out what is using space on your VPS](https://streethosting.com.br/en/guides/vps/find-what-uses-disk-space-on-vps). Now performance: `iostat -xz 1 3 pidstat -d 1 5` In iostat, look for the VPS disk (on KVM, usually vda) and watch three groups of columns. r\_await and w\_await are the average time, in milliseconds, of each read and write. `aqu-sz` is the average queue size. %util is the fraction of time with some request in progress. On NVMe, waits of a few milliseconds are normal; tens of milliseconds consistently indicate a saturated or contended disk. %util near 100% does not prove a bottleneck on NVMe, because those disks serve many requests in parallel, so trust the wait and the queue more. pidstat -d shows who is reading and writing, in the kB\_rd/s and kB\_wr/s columns. The most common culprits are a database without an index doing table scans, a backup running at peak time, a log in debug mode writing nonstop and active swap. To measure disk latency like a ping, install ioping and run `ioping -c 10 /`. It is a quick way to compare before and after a change, or to bring concrete numbers to support. ## Network: interfaces, ports and connections[](https://streethosting.com.br/en/guides/vps/check-cpu-ram-disk-network-linux#rede) `ip -br a ip -s link show eth0 sar -n DEV 1 5` ip -br a lists interfaces and addresses in short form. The public interface of the VPS may be called eth0, ens3, ens18 or similar; use whatever name shows up there in the other commands. ip -s link shows the receive and transmit counters with the errors and dropped columns: growing errors point to a problem on the interface, and growing drops under load usually indicate saturation. sar -n DEV shows rxkB/s and txkB/s every second. A 1 Gbps uplink is about 120,000 kB/s, so you can see right away whether the link is near its limit. `sudo ss -tulpn ss -s ss -Htn state established | wc -l` ss -tulpn lists the TCP and UDP ports in listening state with the owning process (sudo is required to see the process name). It is the definitive check for whether the service is listening and on which address: 127.0.0.1 only accepts connections from the machine itself, while 0.0.0.0 or \[::\] accept connections from outside, if the firewall allows it. ss -s summarizes the counters, and the last line counts established TCP connections. To find out whether a few addresses account for most of the connections, which helps separate a legitimate spike from abuse, group by source IP: `ss -Htn state established | awk '{print $4}' | sed 's/:[0-9]*$//' | sort | uniq -c | sort -rn | head` These commands look at the VPS from the inside. For problems between the VPS and whoever is connecting, such as packet loss at one hop along the path, use [MTR to diagnose the route](https://streethosting.com.br/en/guides/infrastructure/how-to-use-mtr), and to measure the real throughput of the link, see [how to test network speed with iperf3](https://streethosting.com.br/en/guides/vps/test-vps-network-speed). ## Symptom, command and likely cause[](https://streethosting.com.br/en/guides/vps/check-cpu-ram-disk-network-linux#sintomas) Keep this table for the next time someone says the server is slow. It ties the symptom to the command that confirms the hypothesis. | Symptom | Command | What to look at | Likely cause | | ------------------------------- | --------------------------- | --------------------------------- | --------------------------------------- | | Everything slow, high load | vmstat 1 5 | r column above the vCPU count | Saturated CPU | | High load with idle CPU | vmstat 1 5 and iostat -xz 1 | High b and wa columns, high await | Slow or saturated disk | | Slow with no heavy process | mpstat -P ALL 1 | %steal above 5% | CPU contention on the host | | Service crashed on its own | sudo dmesg -T | Line with Killed process | Out of memory and OOM killer | | Freezes of a few seconds | vmstat 1 | si and so non-zero | Swap in active use | | No space left on device error | df -h and df -i | Usage at 100% | Space or inodes exhausted | | Site does not open from outside | sudo ss -tulpn | Port missing or only on 127.0.0.1 | Service stopped or wrong listen address | | Slow downloads | sar -n DEV 1 | Traffic near the uplink | Saturated link | | Connections dropping | ip -s link | errors and dropped growing | Faulty interface or saturation | ## When the problem is a lack of resources[](https://streethosting.com.br/en/guides/vps/check-cpu-ram-disk-network-linux#falta-recurso) Every diagnosis ends one of two ways. Either there is a culprit you can fix (a query without an index, a log in debug mode, a process stuck in a loop, a backup at the wrong time), or the normal load simply does not fit on the VPS. The signs of the second situation are consistent: available below 15% on a normal day, load above the vCPU count at every peak hour and disk above 80% even after a cleanup. In that case, more optimization only postpones the bill. Upgrading through the control panel increases memory, vCPU and disk, charges only the prorated difference for the cycle and requires a VM restart. To work out the right step without guessing, use the numbers you just collected with the method in [how much VPS your project needs](https://streethosting.com.br/en/guides/vps/how-much-vps-do-i-need). StreetHosting VPS run on KVM with NVMe, in São Paulo, with Anti-DDoS included. The Ryzen 9 9950X line, with DDR5 and up to 5.7 GHz, goes from R$ 40.00 per month (1 vCPU, 2 GB, 20 GB NVMe) to R$ 846.00 (14 vCPU, 64 GB, 640 GB). The Xeon line goes from R$ 26.00 (2 vCPU, 2 GB, 20 GB) to R$ 553.00 (24 vCPU, 64 GB, 640 GB) and delivers more vCPU per real. If the diagnosis showed one saturated core, as with a game server or a single-threaded application, the Ryzen clock speed matters more. If it showed many processes competing for CPU in parallel, the Xeon vCPU count gets you further. Compare the tiers on the [VPS page](https://streethosting.com.br/en/vps). In this guide * [One-minute checklist](https://streethosting.com.br/en/guides/vps/check-cpu-ram-disk-network-linux#roteiro) * [CPU: usage, load average and steal](https://streethosting.com.br/en/guides/vps/check-cpu-ram-disk-network-linux#cpu) * [Memory: what real usage looks like](https://streethosting.com.br/en/guides/vps/check-cpu-ram-disk-network-linux#memoria) * [Disk: space and performance](https://streethosting.com.br/en/guides/vps/check-cpu-ram-disk-network-linux#disco) * [Network: interfaces, ports and connections](https://streethosting.com.br/en/guides/vps/check-cpu-ram-disk-network-linux#rede) * [Symptom, command and likely cause](https://streethosting.com.br/en/guides/vps/check-cpu-ram-disk-network-linux#sintomas) * [When the problem is a lack of resources](https://streethosting.com.br/en/guides/vps/check-cpu-ram-disk-network-linux#falta-recurso) ## Frequently asked questions How do I check CPU usage on Linux? Use top or htop for the total and the process list, and mpstat -P ALL 1 for per-core usage, including iowait and steal. Also compare the load average from uptime with the vCPU count reported by nproc. Which command shows RAM usage on Linux? free -h. Look at the available column, which is the memory programs can still use. The free column is usually low because Linux uses spare RAM as disk cache and hands that space back as soon as a program asks for it. How do I know if the disk is the bottleneck on my VPS? Run iostat -xz 1, from the sysstat package, and watch r\_await, w\_await and the queue size. Constant waits of tens of milliseconds, together with high iowait in top, mean processes are stalled waiting for the disk. How do I see open ports on Linux? sudo ss -tulpn lists the TCP and UDP ports in listening state with the process name. If the address is 127.0.0.1, the port only accepts connections from the machine itself; 0.0.0.0 accepts connections from outside, as long as the firewall allows it. What does a high load average mean? It means the average number of processes running or waiting for a resource stayed above the vCPU count for several minutes. A load of 4 is fine on 8 vCPUs and a queue on 2. On Linux, processes waiting for disk count too. Next step See VPS plans Root VPS in Brazil with NVMe and Anti-DDoS. [See VPS plans](https://streethosting.com.br/en/vps) [See Ryzen VPS Ryzen 9 9950X VPS in São Paulo with root access, NVMe and gamer Anti-DDoS.](https://streethosting.com.br/en/vps/ryzen) ## Related guides [VPS Intermediate How to monitor VPS resources with htop and Netdata You only know you need a bigger plan once you can see the numbers. htop gives you a quick snapshot in the terminal, and Netdata gives you a full dashboard with CPU, RAM and disk history. 3 min Read guide](https://streethosting.com.br/en/guides/vps/monitor-vps-resources-htop-netdata) [VPS Beginner What is taking up disk space on your VPS: how to find and free it A full disk takes down databases, stalls updates and makes applications fail without a clear error message. Here is how to find the culprit in a few commands and what you can delete without breaking anything. 9 min Read guide](https://streethosting.com.br/en/guides/vps/find-what-uses-disk-space-on-vps) [VPS Intermediate CPU steal on a VPS: what it is, how to measure it, what to do Steal time is the most direct sign that your virtual machine is competing for CPU with others on the same host. Learn to measure it, tell noise from a real problem and build a ticket that support can actually investigate. 9 min Read guide](https://streethosting.com.br/en/guides/vps/what-is-cpu-steal-vps) [← Back to the Guide Center](https://streethosting.com.br/en/guides)