Exact Linux Command When a Server Hits 100% CPU

When a production Linux box is stuck at 100% CPU, load climbs, SSH feels sticky, and the host is minutes from becoming unresponsive, you need one clear diagnostic path—not a dozen half-remembered tips.

This guide is for sysadmins and developers running Ubuntu or similar servers in Australia who need a repeatable emergency command sequence, three distinct root-cause patterns, and numbered DIY fixes. If the box is already half-dead or the blast radius is a live customer site, Fixwebnode provides direct remote Linux server support so you are not left guessing under pressure.

Why a 100% CPU emergency needs a fixed command path

Full CPU is rarely “the server is busy.” It is usually one runaway process, a stuck worker pool, or a kernel/user-space loop that starves everything else—including your SSH session and monitoring agents. On Australian VPS and dedicated hosts, the same pattern shows up after deploys, cron storms, misconfigured PHP-FPM or Node workers, and log floods. Acting without a short, ordered checklist often makes the outage longer.

The workflow below starts with the exact first command I reach for, then branches into three common issues with safe DIY steps and a clear line for when to book a specialist.

What is the exact Linux command when a server is at 100% CPU in Australia?

Open an SSH session (or console if SSH is already lagging) and run top -c -o %CPU first. That single command sorts live processes by CPU, shows full command lines, and tells you in seconds whether one PID, a worker family, or system time (sy/wa) is burning the cores. From there you capture the top offenders with ps, check I/O wait if needed, then stop or throttle only the guilty process—never a blind reboot unless the host is already unreachable.

Common issues when CPU is pegged and the box is about to crash

These three problems look similar on a dashboard (“CPU 100%”) but need different fixes. Mixing them up is how people kill the wrong process or reboot a host that only needed a stuck worker restarted.

1. A single runaway process (script, binary, or leaked worker)

Symptoms: One PID owns most of a core (or all cores if multi-threaded). top shows that command line at the top every refresh. Load average rises with CPU; memory may still look fine. SSH still works but feels slow.

2. Application worker stampede (PHP-FPM, Node, Java, queue consumers)

Symptoms: Dozens of similar processes each eating CPU. Parent is php-fpm, node, java, or a queue runner. Error logs show timeouts, endless retries, or a bad deploy. Site is slow for everyone, not just one request.

3. CPU wait / softirq storm mistaken for “app CPU”

Symptoms: Load is extreme, but top shows low %user and high %wa or %si. Disk is saturated, a volume is failing, or network interrupts are spiking. Killing app PIDs does almost nothing.

How to fix each issue (DIY runbook)

Issue 1 — Single runaway process

Goal: identify the exact command line, decide if it is safe to stop, and capture evidence before you kill it.

Step 1 — Sort live processes by CPU with full command lines

top -c -o %CPU

Press c if command lines are truncated in your build; note the top PID and the full path/args. Exit with q.

Step 2 — Freeze a snapshot you can paste into a ticket

ps -eo pid,ppid,user,%cpu,%mem,stat,start,time,cmd --sort=-%cpu | head -n 20

This is the companion one-liner I keep after top: sorted CPU list with parent PID, state, and start time so you can see orphans and long-lived offenders.

Step 3 — Confirm it is not a critical system PID

ps -fp PID_HERE
ls -l /proc/PID_HERE/exe
tr '\0' ' ' < /proc/PID_HERE/cmdline; echo

Replace PID_HERE with the number from step 1. If the binary is unexpected (crypto miner path, unknown script under /tmp, stray CI job), treat it as hostile or accidental runaway—not as “the web server.”

Step 4 — Graceful stop first, then escalate

kill -TERM PID_HERE
sleep 5
ps -p PID_HERE || echo "process exited"

If it is still there and you accept data-loss risk for that worker only:

kill -KILL PID_HERE

Step 5 — Verify CPU recovered

top -b -n 1 -o %CPU | head -n 20
uptime

Load should fall within a minute on a healthy host. If the same binary respawns immediately, you have a supervisor or cron restarting it—fix that next, do not only kill children.

When to call Fixwebnode: the PID belongs to a managed app you cannot safely stop, it respawns from an unknown unit, or you suspect compromise rather than a bug.

Issue 2 — Worker stampede (PHP-FPM, Node, queues)

Goal: reduce concurrency, stop the feedback loop, then fix the bad code or config that caused the storm.

Step 1 — Name the family of processes

ps -eo pid,ppid,%cpu,cmd --sort=-%cpu | head -n 30
ps -ef | grep -E 'php-fpm|node|java|sidekiq|horizon|worker' | grep -v grep

Step 2 — Check service status and recent logs (Ubuntu/systemd examples)

systemctl status php8.3-fpm --no-pager
journalctl -u php8.3-fpm -n 80 --no-pager
tail -n 100 /var/log/nginx/error.log

Adjust the unit name for your PHP version or app (nginx, your-node-app, etc.). Look for rapid respawn, segfaults, upstream timeouts, or endless exception loops.

Step 3 — Soft relief: reload or restart the pool, not the whole server

sudo systemctl reload php8.3-fpm
# if reload is not enough:
sudo systemctl restart php8.3-fpm
sudo systemctl restart nginx

For a Node service under systemd:

sudo systemctl restart your-node-app.service
systemctl status your-node-app.service --no-pager

Step 4 — Cap damage if workers immediately return to 100%

Temporarily lower max children / instances in the pool config (PHP-FPM pool file under /etc/php/*/fpm/pool.d/, or your process manager), then reload again. Document the previous values before editing.

sudo cp /etc/php/8.3/fpm/pool.d/www.conf /root/www.conf.bak.$(date +%F-%H%M)
# edit pm.max_children downward carefully, then:
sudo php-fpm8.3 -t && sudo systemctl reload php8.3-fpm

Step 5 — Verify

ps -eo %cpu,cmd --sort=-%cpu | head -n 15
curl -sI https://127.0.0.1/ | head -n 5
uptime

When to call Fixwebnode: every reload brings the stampede back, you cannot tell which deploy introduced it, or lowering workers would violate capacity needs without a proper app fix. Remote specialists can correlate app logs, pool settings, and reverse-proxy behaviour without an emergency reboot.

Issue 3 — High load from I/O wait or softirq (not “kill the top app”)

Goal: stop treating this like an application CPU hog and measure disk and interrupt behaviour.

Step 1 — Read the CPU state line in top or mpstat

top -b -n 1 | head -n 5
command -v mpstat >/dev/null && mpstat -P ALL 1 3

If %wa or si/hi dominate while user time is modest, killing PHP or Node will not save the host.

Step 2 — Disk saturation check

iostat -xz 1 5
df -h
lsblk

Install tools only if missing and policy allows:

sudo apt-get update && sudo apt-get install -y sysstat

Step 3 — Find who is writing or reading hardest

sudo iotop -oPa -d 2 -n 3
# or without iotop:
sudo lsof +D /var/log 2>/dev/null | head
sudo du -xh /var/log | sort -h | tail -n 20

Log floods, runaway backups, and full disks often present as “CPU 100%” on small VPS plans common in Australian hosting.

Step 4 — Short-term containment

sudo journalctl --vacuum-size=200M
sudo find /var/log -type f -name '*.gz' -mtime +14 -delete
# only if a specific runaway writer is identified:
sudo systemctl stop SERVICE_THAT_FLOODS_LOGS

Do not delete active database files. If a volume is read-only or failing, schedule specialist storage recovery rather than repeated kills.

Step 5 — Verify load vs CPU composition

uptime
top -b -n 1 | head -n 8

When to call Fixwebnode: wait time stays high after log relief, disks look unhealthy, or softirq points at network/virtio issues you cannot change from user space.

When DIY is enough vs when to book Fixwebnode

DIY is enough when SSH still works, you can name a single non-critical PID or restart a known app unit, CPU drops after that action, and you have logs showing a clear bug or cron mistake. Keep the ps snapshot and journal excerpt for your post-mortem.

Book direct remote help when the host is intermittently unreachable, kills do not stick, you suspect intrusion, multiple services are interdependent (database + queue + web), or you need someone who can work a console session while you protect customer traffic. Fixwebnode is a direct specialist provider for Ubuntu/Linux server support and bug fixing—not a freelance marketplace—and works remotely with Australian teams when an emergency CPU event is bigger than a one-line kill.

Coverage and remote service areas are listed on the service areas page. For this class of outage, remote diagnosis is usually the practical path: the same top/ps/systemd checks above, run with a second pair of eyes and a recovery plan.

Book remote help before the host goes dark

If your server is already at 100% CPU, load is climbing, and you are not confident which of the three patterns you are in, do not wait for a full lockup. Capture one top -c -o %CPU screen and one ps snapshot, then start a conversation with the team that handles this exact failure mode.

Talk through the incident and book remote Linux support via Fixwebnode Ubuntu Linux server support. Bring the PID list and unit names; we will take it from the same emergency command path—ordered, production-safe, and focused on getting CPU and load back under control.