linux troubleshooting guide

High CPU or Memory on Linux: First Response

Find whether load, CPU, memory, swap, containers, or OOM kills are driving a slow Linux host before restarting services.

Problem

A Linux server is slow, requests time out, SSH feels laggy, or monitoring shows high CPU or memory. Restarting the biggest-looking process can hide evidence or make the outage worse.

First rule

Take a read-only snapshot first: load, memory, swap, top processes, container pressure, and recent OOM logs.

Audience

VPS owners, Linux administrators, developers debugging slow servers, and LFCS-style performance practice users

Cert context

Useful for LFCS and Linux+ style operations practice around processes, memory, service triage, and logs. This is independent study support.

quick start

Safe first commands

uptime
free -h
ps -eo pid,ppid,stat,pcpu,pmem,comm,args --sort=-pcpu | head
ps -eo pid,ppid,stat,pcpu,pmem,comm,args --sort=-pmem | head

Separate load, CPU, and memory

High load is not always high CPU. It can also point to I/O waits, blocked processes, or memory pressure. Start with a quick snapshot before narrowing.

uptime
free -h

Rank processes by CPU and memory

Process ranking shows where to inspect next. Treat it as evidence, not permission to kill the first PID.

ps -eo pid,ppid,stat,pcpu,pmem,comm,args --sort=-pcpu | head
ps -eo pid,ppid,stat,pcpu,pmem,comm,args --sort=-pmem | head

Check containers separately

On Docker or Podman hosts, the host process list may not explain which container or workload owns the pressure.

docker stats --no-stream
docker ps --format 'table {{.Names}}\t{{.Status}}\t{{.Ports}}'

Look for OOM kills

A process may be missing because the kernel already killed it. OOM logs explain memory pressure after the fact.

journalctl -k --since '2 hours ago' --no-pager | grep -i 'out of memory\|oom'
dmesg -T | grep -i 'killed process\|out of memory' | tail

triage logic

How to read the result

one process dominates CPU

The next step is process-specific context: logs, recent deploys, request volume, or worker queues.

Next: Capture PID, command args, and service logs before killing or restarting.

memory is low and swap is active

The host may be thrashing or under-provisioned.

Next: Identify top memory processes and check for OOM events.

OOM logs name a killed process

The symptom may be a restart loop or missing worker, not just current memory pressure.

Next: Inspect service status and recent logs for that process.

safety notes

Slow down here

Do not kill production processes before capturing the command line and service context.
Read-only process commands can still expose secrets in process arguments.
Container and service restarts should be treated as state-changing operations.

related commands