How to Diagnose CPU Bottlenecks and Memory Pressure in Linux

Handling a critical ticket while a production server is grinding to a halt is stressful. The fastest engineers are not the ones who type the most commands. They are the ones who preserve evidence, separate CPU pressure from memory and I/O pressure, and choose the lowest-risk action that restores service.

Start with the simple picture

A slow Linux server usually needs you to answer three questions:

1. Is the CPU too busy? Think of the CPU as workers at a service counter. If every worker is busy and more work keeps arriving, a queue forms.
2. Is the server running short of memory? Think of RAM as a fast work desk. When the desk is full, Linux may move less-used information to much slower disk space called swap.
3. Are programs waiting for storage or another I/O operation? The CPU may not be busy at all; applications can still feel frozen while they wait for a slow disk, network storage, or heavy swapping.

Your goal is not to react to one large number. Your goal is to identify which of these three situations is delaying useful work.

Beginner glossary: the numbers you will see

The 60-second initial triage

Start with four commands. Run them one at a time and read the explanation below before trying more advanced tools.

uptime
free -h
top
vmstat 1 5

• uptime shows the load average. Run nproc to see how many logical CPUs the server has.
• free -h shows memory and swap in human-readable units. Focus first on the available memory.
• top shows CPU fields and which processes are using the most CPU or memory. Press P to sort by CPU or M to sort by memory.
• vmstat 1 5 takes five samples, one second apart. Ignore the first line because it summarizes activity since boot; use the later lines to see what is happening now.

Compare load average with the CPU count, but treat it as a clue. A load above the CPU count suggests a queue is building. The queue may be waiting for CPU time or may be blocked on I/O, so check us, sy, id, and wa before deciding.

Part 1: is the CPU the bottleneck?

A CPU bottleneck exists when runnable work consistently demands more compute time than the available CPUs can supply. A brief spike is not enough; look for sustained pressure that matches the user-visible slowdown.

1. Read the CPU fields correctly

vmstat 1 5
mpstat -P ALL 1 5
pidstat -u -w 1 5

• us (user): application code is consuming CPU. Compression, encryption, query processing, garbage collection, loops, or expensive requests may be involved.
• sy (system): the kernel is doing substantial work. Investigate syscalls, networking, interrupts, I/O, and context switching.
• id (idle): close to zero across the observation window means little CPU capacity remains.
• wa (I/O wait): the CPU is idle while tasks wait for I/O. This points away from pure compute saturation and toward storage or another blocking path.
• r in vmstat: runnable processes. A sustained run queue above available CPUs supports a CPU contention diagnosis.

2. Isolate the process and thread

ps -eo pid,ppid,stat,comm,%cpu,%mem --sort=-%cpu | head -n 11
top -H -p <PID>
pidstat -u -w -p <PID> 1 5

For a multithreaded process such as Java, Node.js, Python workers, Nginx, or a database, the process total is only the first clue. Use the thread view to identify whether one thread is spinning, many workers are legitimately busy, or the process is spending time in context switches.

3. Check pressure, not just utilization

cat /proc/pressure/cpu
cat /proc/pressure/io

This is an optional advanced check. Pressure Stall Information (PSI) measures how much time programs lose while waiting for CPU, memory, or I/O resources. Rising CPU some averages mean at least some tasks are waiting for CPU time. Beginners can first become comfortable with top, free, and vmstat, then add PSI later.

4. Mitigate with the lowest-risk action

1. Reduce incoming work: pause a batch, shed optional traffic, lower worker concurrency, or scale out if the platform supports it.
2. Lower a non-critical process priority: sudo renice -n 19 -p <PID>. Verify the new priority and service impact.
3. Constrain a known-safe workload: prefer service, container, or cgroup CPU limits. Temporary affinity such as sudo taskset -cp 0,1 <PID> can help in a controlled incident, but poor affinity choices can make latency worse.
4. Stop gracefully: use the service manager or kill -TERM <PID>, wait, and confirm shutdown. Use kill -KILL <PID> only as a last resort because it prevents cleanup and can leave partial work behind.

Part 2: is memory pressure slowing the server?

Linux intentionally uses spare RAM for page cache, so the free column is not the number that matters most. Focus on available, active reclaim, swap-in and swap-out activity, pressure, process growth, and OOM events.

1. Confirm active pressure

free -h
vmstat 1 10
cat /proc/pressure/memory
pidstat -r 1 5

Allocated swap is not automatically a problem; Linux may leave cold pages in swap even after pressure has passed. Sustained non-zero si and so in vmstat, low available memory, elevated memory PSI, and slow I/O together are much stronger evidence of active thrashing.

2. Find the consumers and the growth pattern

ps -eo pid,ppid,stat,comm,rss,%mem --sort=-rss | head -n 11
pidstat -r -p <PID> 1 10
cat /proc/<PID>/status | egrep 'VmRSS|VmSwap|Threads'

One snapshot tells you who is large. Repeated samples tell you who is growing. Distinguish expected cache, a workload spike, too many workers, a process leak, and a restrictive container memory limit before deciding the fix.

3. Check for OOM killer intervention

journalctl -k -g 'oom|out of memory|killed process'
dmesg -T | grep -i -E 'oom|out of memory|killed process'

Record the killed PID, process name, cgroup or container, memory totals, and timestamp. If the host has free memory but a container is killed, inspect the workload's cgroup limit rather than assuming the entire server ran out of RAM.

4. Mitigate memory pressure safely

If you are a fresher or do not own the production service, collect the evidence and involve the service owner before changing limits, stopping processes, or adjusting OOM settings.

1. Stop the growth: pause the leaking or non-critical workload, reduce concurrency, reject optional work, or scale capacity.
2. Restart only with evidence: if an approved restart is the recovery action, capture diagnostics first and watch memory after recovery so a leak does not silently return.
3. Protect critical services carefully: a temporary adjustment is echo -500 | sudo tee /proc/<PID>/oom_score_adj. For systemd services, use a reviewed OOMScoreAdjust= setting. Avoid blanket -1000 protection: making one process unkillable can force the kernel to kill another essential service.
4. Fix the capacity or limit: tune heap and worker counts, correct cgroup limits, add memory, or repair the leak after service is stable.

A production incident sequence you can reuse

1. Declare impact: what is slow or unavailable, when it started, and which users or services are affected?
2. Capture a baseline: timestamp, CPU count, load, CPU fields, available memory, swap activity, PSI, top processes, and kernel events.
3. Classify the pressure: CPU queue, I/O wait, active memory reclaim, OOM, or a mixture.
4. Identify the owner: process, thread, service, container, dependency, recent deployment, or workload change.
5. Mitigate reversibly: shed work, lower priority, scale, or stop gracefully before considering forceful actions.
6. Validate: repeat the same measurements and confirm both system signals and user experience improved.
7. Preserve follow-up evidence: commands, timestamps, graphs, process IDs, logs, action taken, result, rollback path, and prevention item.

Quick reference for the incident channel

The key lesson

Do not optimize the loudest metric. Diagnose the resource that is making useful work wait. CPU utilization, load average, free memory, swap, and I/O wait become meaningful only when they agree with process trends, pressure data, logs, and the user-visible symptom. That evidence-first habit is what makes a Linux response fast, safe, and credible.