Why My AWS Server Was Slow — And How Swap Saved the Day

Recently I was troubleshooting a sluggish AWS EC2 instance running Ubuntu and Apache. Pages felt slow, SSH lagged, and the system didn’t seem busy — yet the load average was high.

To understand what was going on, I first looked at the system resource usage.

Checking Load & Memory

Running the following command helped reveal the issue:

free -h

The output looked roughly like this:

Mem:   1.9Gi total
       1.6Gi used
       69Mi  free
       219Mi buff/cache
       30Mi available
Swap:  0B  0B  0B

This confirmed three important things:

• The server had very little RAM free
• There was no swap space configured
• Only about 30MB of memory was still available

Why This Causes Slowness

Linux reports load based not only on CPU usage, but also on processes that are waiting on memory or disk. That means you can see high load averages even when CPU usage is low — which is exactly what was happening here.

Without swap, the kernel has no fallback once RAM fills up. It begins aggressively reclaiming memory, which slows the system dramatically and causes stalls.

Step 1 — Add Swap (Quick Fix)

To stabilize the server, I created a 2GB swap file:

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

After enabling swap, I verified it with:

free -h

Swap is slower than RAM, but having no swap at all makes the system unstable once memory fills. Giving the kernel somewhere to move unused memory makes a huge difference in system responsiveness.

Step 2 — Reduce Apache Memory Pressure

Small EC2 instances can easily run out of memory if Apache spawns too many workers. I checked which multiprocessing mode Apache was using:

apache2ctl -V | grep -i mpm

Then I tuned the worker limits to something more reasonable for a low-memory server:

MaxRequestWorkers 25
ServerLimit 25

Step 3 — Consider the Instance Size

A server with only 2GB of RAM can work fine for light websites — but once you add services, it is easy to run out of memory. For many workloads, a t3.small or t3.medium is a safer starting point.

If you are using a burstable instance, keep in mind that CPU credits can also throttle performance if they run out.

Root Cause Recap

The slowdown ultimately came from:

• Limited RAM
• No swap configured
• Apache and OS memory pressure
• Kernel constantly reclaiming memory

That combination results in high load averages with low CPU usage — a classic sign of memory starvation.

Final Thoughts

Swap doesn’t replace RAM, but it provides a crucial safety net. When you see high load on a Linux server but low CPU usage, always check:

free -h
htop
iostat -xz 1

Chances are, memory or disk pressure — not CPU — is the real culprit.