topWatch CPU, memory and processes live
top is a live, refreshing view of the system: load average, CPU split (user, system, iowait, steal), memory and swap, then the busiest processes. It is installed everywhere, so it is the first thing to run when someone says 'the server is slow'.
top [-b] [-n COUNT] [-d SECONDS] [-p PID,...] [-u USER] [-o FIELD]Users say the API is slow. Take one look at the whole box before you guess at causes.
topprocps-ng top: samples /proc repeatedly and redraws the screen every 3 seconds by default.
top reads the same /proc files as ps, but it reads them twice and works out rates. Each refresh it reads /proc/stat (total CPU ticks spent in user, nice, system, idle, iowait, irq, softirq, steal), /proc/meminfo, /proc/loadavg and /proc/PID/stat for every process. A process's %CPU is the ticks it used since the last refresh divided by the interval, so it is current, and it is per CPU: a process using two full cores shows 200% (press I to toggle Irix mode off and divide by the core count). The first iteration has no previous sample, which is why the first batch-mode screen is less accurate. The summary's 'avail Mem' comes from MemAvailable, the kernel's estimate of memory that can be used without swapping.
-d SECSRefresh interval (default 3.0 seconds)-n NExit after N refreshes-bBatch mode: plain output for logs, scripts and pipes-p PID,...Monitor only these PIDs (up to 20)-u USEROnly this user's processes-o FIELDSort field: %CPU, %MEM, TIME+, RES ...-HShow individual threads instead of processes-cShow full command lines instead of program names1 (key)Interactive: toggle one line per CPU coreP / M / T (keys)Interactive: sort by CPU / memory / cumulative timek / r (keys)Interactive: kill or renice a PIDq (key)QuitPanicking at 'free 412.6' in the Mem lineLinux uses spare RAM as page cache, so free is always small on a healthy box. The cache is given back on demand.
Look at 'avail Mem' at the end of the Swap lineReading a process at 380% CPU as a bug in topPer-process %CPU is relative to one core by default (Irix mode). A 4-thread process on 4 cores can show 400%.
Press 1 to see per-core lines, or Shift-I to divide by core counttop -n 1 > snapshot.txtWithout -b, top writes terminal control codes into the file and may complain about the terminal.
top -b -n 1 > snapshot.txtAssuming high load average means CPU is the bottleneckOn Linux, load counts D-state tasks waiting on disk or NFS too. Load 6 with 50% wa is an I/O problem.
Check wa and st in the %Cpu line, then iostat -x 1Try these on a Linux machine of your own. Each task has a hint and a solution.
Take a single plain-text snapshot of top and save it to ~/top.txt.
Show only your own processes in one top snapshot, sorted by memory.
Start `sleep 300 &`, then watch only that PID with top for three 1-second samples.
Run top interactively, show per-CPU lines, sort by memory, then quit.
topWatch CPU, memory and processes live
top is a live, refreshing view of the system: load average, CPU split (user, system, iowait, steal), memory and swap, then the busiest processes. It is installed everywhere, so it is the first thing to run when someone says 'the server is slow'.
top [-b] [-n COUNT] [-d SECONDS] [-p PID,...] [-u USER] [-o FIELD]Users say the API is slow. Take one look at the whole box before you guess at causes.
topprocps-ng top: samples /proc repeatedly and redraws the screen every 3 seconds by default.
top reads the same /proc files as ps, but it reads them twice and works out rates. Each refresh it reads /proc/stat (total CPU ticks spent in user, nice, system, idle, iowait, irq, softirq, steal), /proc/meminfo, /proc/loadavg and /proc/PID/stat for every process. A process's %CPU is the ticks it used since the last refresh divided by the interval, so it is current, and it is per CPU: a process using two full cores shows 200% (press I to toggle Irix mode off and divide by the core count). The first iteration has no previous sample, which is why the first batch-mode screen is less accurate. The summary's 'avail Mem' comes from MemAvailable, the kernel's estimate of memory that can be used without swapping.
-d SECSRefresh interval (default 3.0 seconds)-n NExit after N refreshes-bBatch mode: plain output for logs, scripts and pipes-p PID,...Monitor only these PIDs (up to 20)-u USEROnly this user's processes-o FIELDSort field: %CPU, %MEM, TIME+, RES ...-HShow individual threads instead of processes-cShow full command lines instead of program names1 (key)Interactive: toggle one line per CPU coreP / M / T (keys)Interactive: sort by CPU / memory / cumulative timek / r (keys)Interactive: kill or renice a PIDq (key)QuitPanicking at 'free 412.6' in the Mem lineLinux uses spare RAM as page cache, so free is always small on a healthy box. The cache is given back on demand.
Look at 'avail Mem' at the end of the Swap lineReading a process at 380% CPU as a bug in topPer-process %CPU is relative to one core by default (Irix mode). A 4-thread process on 4 cores can show 400%.
Press 1 to see per-core lines, or Shift-I to divide by core counttop -n 1 > snapshot.txtWithout -b, top writes terminal control codes into the file and may complain about the terminal.
top -b -n 1 > snapshot.txtAssuming high load average means CPU is the bottleneckOn Linux, load counts D-state tasks waiting on disk or NFS too. Load 6 with 50% wa is an I/O problem.
Check wa and st in the %Cpu line, then iostat -x 1Try these on a Linux machine of your own. Each task has a hint and a solution.
Take a single plain-text snapshot of top and save it to ~/top.txt.
Show only your own processes in one top snapshot, sorted by memory.
Start `sleep 300 &`, then watch only that PID with top for three 1-second samples.
Run top interactively, show per-CPU lines, sort by memory, then quit.