{"id":813,"date":"2026-08-06T23:28:54","date_gmt":"2026-08-06T23:28:54","guid":{"rendered":"https:\/\/virtualserversvps.com\/blog\/?p=813"},"modified":"2026-10-20T22:05:30","modified_gmt":"2026-10-20T22:05:30","slug":"monitor-vps-cpu-ram-disk-usage-real-time","status":"publish","type":"post","link":"https:\/\/virtualserversvps.com\/blog\/monitor-vps-cpu-ram-disk-usage-real-time\/","title":{"rendered":"Reading Linux Performance in Under 60 Seconds: vmstat, pidstat and PSI"},"content":{"rendered":"
\n

A slow server does not hide its bottleneck: the Linux kernel accounts for every nanosecond of CPU time, every major page fault, every block-layer request and every dropped packet. The difficulty is turning that firehose into a decision in under a minute. This is a drill-down procedure \u2014 one-second system snapshot, then per-process attribution, then device-level and memory-level confirmation \u2014 using only tools that ship with a normal distribution or one apt install sysstat<\/code>. All of it reads from \/proc<\/code> and \/sys<\/code>, so it works identically on any Linux instance, whether that is a properly sized VPS with dedicated CPU shares<\/a> or a cramped container.<\/p>\n

Step 1: Establish the Baseline Before Anything Is Wrong<\/h2>\n

Tuning and diagnosis both fail without a baseline. Capture one while the box is healthy, so a later reading has something to be compared against:<\/p>\n

<code>mkdir -p \/var\/log\/baseline\nvmstat 1 60 > \/var\/log\/baseline\/vmstat.txt\ncat \/proc\/pressure\/cpu \/proc\/pressure\/memory \/proc\/pressure\/io \\\n  > \/var\/log\/baseline\/psi.txt\nsar -u -r -d 1 5 > \/var\/log\/baseline\/sar.txt<\/code><\/code><\/pre>\n
Two numbers matter most in that baseline: r<\/code> (run queue) and the PSI avg10<\/code> values. A healthy idle box shows r<\/code> at or below the vCPU count and PSI avg10<\/code> under 1.00 for all three resources.<\/p>\n
Step 2: The One-Second Snapshot<\/h2>\n
vmstat 1<\/code> remains the densest single command on Linux. Read the columns in a fixed order rather than scanning them:<\/p>\n
<code>vmstat 1 5\n# procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----\n#  r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st<\/code><\/code><\/pre>\n\n\n\n\n\n\n\n\n
Column<\/th>\nThreshold that means “act”<\/th>\nWhat it implies<\/th>\n<\/tr>\n
r<\/code><\/td>\nsustained > vCPUs<\/td>\nCPU oversubscription inside the guest<\/td>\n<\/tr>\n
si<\/code>\/so<\/code><\/td>\nany sustained non-zero<\/td>\nActive swapping; memory problem, not disk<\/td>\n<\/tr>\n
bi<\/code>\/bo<\/code><\/td>\nbo > 50 MB\/s with wa<\/code> high<\/td>\nWrite path saturated; check dirty ratio and device<\/td>\n<\/tr>\n
in<\/code><\/td>\n> 50k\/s on a 4-vCPU box<\/td>\nInterrupt storm \u2014 often network at high pps<\/td>\n<\/tr>\n
cs<\/code><\/td>\n> 100k\/s idle-ish<\/td>\nThread pool too large, or lock contention<\/td>\n<\/tr>\n
st<\/code><\/td>\n> 2% sustained<\/td>\nHypervisor steal \u2014 guest tuning cannot fix it<\/td>\n<\/tr>\n<\/table>\n
The st<\/code> row deserves emphasis. Steal time means your vCPU was runnable but the hypervisor scheduled someone else. If the baseline was 0.2% and the current reading is 6%, the instance is being oversubscribed on the host, and every sysctl in the following sections is theatre. Confirm with mpstat -P ALL 1<\/code> to see whether steal is spread across all vCPUs or concentrated on one \u2014 concentrated steal usually indicates a co-scheduled noisy neighbour or a pinned host thread.<\/p>\n
Step 3: Attribute CPU to a Process<\/h2>\n
top<\/code> averages over its refresh interval and hides short spikes. pidstat<\/code> reports true deltas between samples and separates the accounting:<\/p>\n
<code>sudo apt install sysstat\npidstat -u -p ALL 1      # user\/system CPU per process\npidstat -r -p ALL 1      # page faults, RSS growth\npidstat -d -p ALL 1      # disk read\/write per process\npidstat -w -p ALL 1      # voluntary\/involuntary context switches<\/code><\/code><\/pre>\n
Read %usr<\/code> and %system<\/code> separately. A process at 100% %system<\/code> with a small %usr<\/code> is spending its time in syscalls \u2014 typically small-buffer read\/write loops, excessive futex<\/code> traffic, or a tracing agent. That is tunable or starvable; a process at 100% %usr<\/code> needs a faster core or fewer threads.<\/p>\n
pidstat -w<\/code> is the underrated one. Involuntary context switches (nvcswch\/s<\/code>) climbing on a process whose %CPU<\/code> is below 100 means it is being preempted \u2014 either the run queue is full or its CPU affinity is competing with another hot thread. Voluntary switches (cswch\/s<\/code>) in the tens of thousands per second usually mean lock contention, not I\/O, especially in JVM and Go workloads.<\/p>\n
Step 4: Localise Disk Pressure Properly<\/h2>\n
High wa<\/code> in vmstat points at storage; iostat -x 1<\/code> tells you which layer. The trap is that %util<\/code> is nearly meaningless on NVMe, where a device can service hundreds of parallel requests and still show high utilisation at trivial latency.<\/p>\n
<code>iostat -x 1\n# Device  r\/s   w\/s  rkB\/s  wkB\/s  r_await  w_await  aqu-sz  %util<\/code><\/code><\/pre>\n