Raspberry Pi Performance Tuning: Proven Under-Load Fixes

Q: How do I check the CPU governor on Raspberry Pi?

Run cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor. The default is usually ondemand. To change it, run echo performance | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor. Only do this after power and cooling are solid, or you will increase throttling rather than reduce it.

Raspberry Pi performance tuning for real workloads starts where most guides stop, right when the system stays busy for hours. Things feel fast at boot, then slow down once services stack up. CPU clocks drop. Storage stalls. Network latency spikes. That is not bad luck. That is sustained load exposing limits in power, cooling, memory, and disk behavior that a five-minute benchmark will never reveal.

Real workloads include home servers, media streaming, databases, and containers running side by side. These stress the board in mixed ways, not one at a time. Heat builds. Writes become random. RAM pressure grows. Small delays compound into visible lag. This guide is about keeping performance steady under that kind of load, not just winning a synthetic test.

Key Takeaways

Real workloads expose limits that benchmarks hide entirely
Fix power and cooling before touching any software setting
Storage latency causes most perceived slowdowns on a Pi
Memory pressure creates sudden stalls, not gradual slowdown
Predictability under load matters more than peak speed numbers
Tuning in the wrong order wastes time and creates false wins

Why Performance Breaks Under Sustained Load

A Raspberry Pi feels quick right after boot because the CPU runs at peak frequency, caches are warm, and storage queues are empty. That is burst performance. Web servers, databases, media scanners, and containers do not live there. As time passes, heat builds and the system shifts into a lower, safer operating state without telling you.

When the SoC temperature rises, firmware reduces CPU frequency automatically. This is not a crash or a warning most users notice. It is a silent slowdown. Requests take longer. Background jobs pile up. Latency increases even though CPU usage looks normal. On top of that, storage turns random under load. Logs, databases, and metadata writes compete with reads. The CPU sits idle waiting on disk, showing as I/O wait, while the system feels slow even though plenty of CPU capacity remains.

One service alone may run fine. Add a second and a third and shared limits appear. Power, heat, memory, and storage all interact. Performance breaks not because of one bad setting, but because multiple limits are hit at the same moment.

Define the Workload Before Touching Settings

Performance tuning without knowing what you are tuning for usually makes things worse. A Pi running a media server behaves very differently from one hosting a database or compiling code. Each stresses the system in a different way and needs different fixes.

CPU-bound workloads push the processor hard for long periods. Code compilation, encryption, and data processing fall here. When these slow down, thermal throttling and frequency scaling are almost always involved. I/O-bound workloads wait on storage more than CPU. Databases, backups, and logging-heavy services show up as pauses and timeouts even when CPU usage stays low. Most real homelab systems land in the mixed category, hitting CPU, disk, and network at the same time, which is where tuning matters most because small bottlenecks stack quickly.

Before changing any setting, run this and look at the output for thirty seconds under real load:

# Watch CPU, memory, and I/O wait in real time
vmstat 2

# See which processes are using CPU and causing I/O wait
top

# More detailed view with per-core stats
htop

The wa column in vmstat is I/O wait. If it is consistently above 10 percent, storage is your bottleneck, not CPU. If CPU is pegged and I/O wait is low, you have a compute problem. Knowing this before you start saves a lot of time chasing the wrong thing.

Step 1: Power Delivery

Fix power first. No software tuning can overcome unstable voltage. On a Raspberry Pi, power problems rarely cause a clean failure. The board protects itself. When voltage drops, firmware reduces CPU speed and I/O performance. The system keeps running, just slower, and you may never see a warning.

Many setups idle comfortably then fail under load. USB SSDs, Wi-Fi radios, and Ethernet controllers all pull extra power during activity. If the supply or cable cannot deliver clean voltage at that moment, throttling kicks in immediately. Thin or long cables introduce voltage drop. A supply rated for enough current can still underperform if the cable is poor.

Check whether the firmware has already flagged power issues:

# Check for undervoltage and throttling events since last boot
vcgencmd get_throttled

# 0x0 means nothing flagged
# 0x50000 means undervoltage and throttling have occurred

Run this after a session under real load, not at idle. The register clears on reboot, so timing matters. If you see anything other than 0x0, fix power before doing anything else. For the Pi 5 specifically, use a supply that supports the 5V 5A USB-C PD profile. Standard USB-C chargers that cannot negotiate this profile will limit USB output current under load.

Step 2: Thermal Stability

Once power is solid, heat becomes the next limiter. A Raspberry Pi does not fail when it gets hot. It slows down. As temperature rises, firmware lowers CPU frequency to protect the silicon. This happens gradually and repeatedly during long workloads. The result is performance that fades over time even though nothing appears broken.

Short tests do not reveal this. After thirty minutes or a few hours, heat builds inside the board, the case, and the surrounding air. Once everything is warm, cooling efficiency drops. The CPU spends more time below its maximum clock, which stretches response times and extends job completion.

# Current CPU temperature
vcgencmd measure_temp

# Watch temperature under load (updates every second)
watch -n 1 vcgencmd measure_temp

# Check current clock speed (drops when throttled)
watch -n 1 vcgencmd measure_clock arm

The Pi 4 begins soft throttling at 80 degrees Celsius and hard throttling at 85. The Pi 5 targets 85 degrees with active cooling. If you see the clock speed dropping while load is applied, thermal throttling is active. A modest fan changes behavior completely. By moving warm air away, the CPU holds higher clocks for longer. A metal case is not automatically cooling. Sometimes it traps heat. Airflow matters more than material.

Step 3: Storage Behavior

Storage is the biggest hidden bottleneck on a Raspberry Pi and fixing it usually delivers the largest real-world improvement. Most slowdowns that get blamed on the CPU are actually storage stalls. MicroSD cards struggle with random reads and writes, which real workloads generate constantly. Databases, logs, package updates, and metadata access all hit storage in small, scattered chunks.

Check what storage is actually doing

# Real-time disk I/O statistics
iostat -x 2

# Watch which processes are hitting disk hardest
iotop

# Check current read/write speeds and response times
iostat -d -x mmcblk0 2   # for SD card
iostat -d -x sda 2        # for USB SSD

Watch the await column in iostat. That is average I/O response time in milliseconds. On a healthy SD card under light load this should be under 5ms. Under real workloads it can spike to 50ms or more, which is when everything else starts feeling slow. A USB SSD will typically stay under 2ms.

Reduce write pressure with mount options

The single most effective software change for storage performance on a Pi is reducing unnecessary writes. Open fstab and add these options to your root partition:

sudo nano /etc/fstab

# Add noatime and commit=300 to your root partition line:
PARTUUID=xxxxxxxx-02  /  ext4  defaults,noatime,commit=300  0  1

noatime stops the filesystem writing an access timestamp every time a file is read. commit=300 extends the journal commit interval from 5 seconds to 5 minutes, reducing how often metadata is flushed to flash. Neither change affects data safety in any meaningful way for typical homelab workloads. Both reduce write amplification significantly. For a full breakdown of what is hitting your SD card and why, see Preventing SD Card Corruption on Raspberry Pi.

Move off SD card

For databases, containers, and anything with heavy write patterns, the SD card is not a viable long-term storage medium for performance. Booting from a USB SSD removes the most common bottleneck in a single step. The process is straightforward and covered in full at Booting Raspberry Pi from USB SSD.

Step 4: Memory Pressure

Memory pressure builds quietly. Databases cache data. Containers duplicate libraries. Logs and page cache grow over time. When RAM runs low, the system does not slow evenly. It stalls in bursts. Commands hang. Services pause then recover. If swap lives on a slow SD card, every page move blocks progress elsewhere. This looks like random freezes even though nothing crashed.

# Check current memory and swap usage
free -h

# Watch memory pressure in real time
watch -n 2 free -h

# See what is using memory
ps aux --sort=-%mem | head -20

If you see swap consistently in use and the system feeling sluggish, the fix is moving swap off flash entirely. zram creates a compressed swap device in RAM, eliminating the SD card write penalty during memory pressure. The setup takes five minutes and makes a noticeable difference on any Pi with 1GB or 2GB RAM. Full setup at Setting Up zram on Raspberry Pi.

After enabling zram, tune these kernel parameters to tell the system to use compressed RAM swap aggressively rather than hitting disk:

sudo nano /etc/sysctl.d/99-performance.conf

# Add these lines:
vm.swappiness=100
vm.vfs_cache_pressure=500
vm.dirty_background_ratio=1
vm.dirty_ratio=50
vm.page-cluster=0

# Apply immediately without reboot:
sudo sysctl --system

Step 5: CPU Governor and Scheduling

Only tune CPU behavior after power, heat, storage, and memory are no longer fighting the system. CPU governor tuning before that point just hides problems rather than fixing them.

Out of the box, the Pi uses a governor that prioritizes power savings. CPU frequency ramps up only when load spikes, then drops again quickly. This works for short tasks. Under sustained workloads it creates uneven performance. Requests complete at different speeds even when demand stays constant, because every time the CPU scales up or down there is a latency cost.

# Check current governor
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

# See available governors
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors

# Set performance governor for consistent clocks (survives until reboot)
echo performance | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

# To make it permanent, add to /etc/rc.local before exit 0:
echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

The performance governor locks the CPU at maximum frequency. This reduces latency variance and keeps queues short but increases power draw and heat. Only use it if your cooling is solid and power delivery is clean, because if either is marginal, locking to maximum frequency will make throttling more frequent, not less. The ondemand governor is a reasonable middle ground if you want responsiveness without the full power cost.

Step 6: Workload-Specific Tuning

Databases

Database software ships with settings designed for servers with fast disks and plenty of RAM. Those assumptions break on Pi hardware. Frequent syncs and aggressive durability guarantees create constant write pressure on storage that already struggles with random I/O.

For SQLite (used by Home Assistant and many lightweight services), the most impactful change is WAL mode and a larger cache:

-- Run in sqlite3 or via your application:
PRAGMA journal_mode=WAL;
PRAGMA cache_size=-32000;  -- 32MB cache
PRAGMA synchronous=NORMAL; -- Less aggressive than FULL, safer than OFF

For PostgreSQL, reduce checkpoint frequency and increase shared buffers to reduce write storms:

# In postgresql.conf:
shared_buffers = 128MB          # Adjust based on available RAM
checkpoint_completion_target = 0.9
wal_buffers = 16MB
synchronous_commit = off        # Safe for non-critical data, fast

Containers

Containers add overhead through isolation layers, duplicated libraries, and filesystem indirection. One container is cheap. Several running together change system behavior in ways that are not obvious until everything slows down at once.

Set memory limits on containers to prevent one service from consuming all available RAM and pushing everything else into swap:

# In docker-compose.yml, set limits per service:
services:
  myservice:
    mem_limit: 512m
    memswap_limit: 512m  # Equal to mem_limit disables swap for this container

Use docker stats to watch what each container is actually consuming under real load before setting limits. Guessing at limits without data creates new problems.

Media servers

Direct playback places minimal load on the system. Real-time transcoding pushes CPU, memory, and storage at the same time. On a Pi, this shift is dramatic. The key is forcing your media server to direct play as much as possible and restricting transcoding to formats the GPU can handle in hardware.

Schedule library scans and thumbnail generation during off-peak hours rather than letting them trigger during playback. In Jellyfin or Plex, set scheduled tasks to run between 2am and 6am. Background scans are the most common cause of buffering that users blame on their network.

I/O Contention and USB Behavior

On a Raspberry Pi, USB ports, network interfaces, and storage often share internal buses. When multiple devices become active at the same time, they compete for the same bandwidth and controller time. This shows up as uneven performance rather than a clean speed cap.

Some USB storage enclosures fall back to slower transfer modes when errors occur. Throughput may stay acceptable but latency increases sharply. Check what mode your USB storage is actually using:

# Check if USB storage is using UAS (fast) or usb-storage (slow)
lsusb -t

# Check dmesg for UAS or usb-storage messages
dmesg | grep -i "uas\|usb-storage"

# Check current read speed on USB SSD
sudo hdparm -tT /dev/sda

If your enclosure has a known UAS compatibility issue, add a quirks flag to cmdline.txt to force the slower but more reliable usb-storage driver. Replace the vendor and product ID with your device’s actual IDs from lsusb:

# Add to /boot/firmware/cmdline.txt (all on one line, no line breaks)
usb-storage.quirks=XXXX:XXXX:u

Network Performance Under Load

On a Raspberry Pi, network performance depends heavily on what else the system is doing. When storage or CPU load increases, packet handling can fall behind. Throughput drops. Latency rises. Connections feel unreliable even though signal strength and link speed look fine.

# Check network throughput in real time
iftop -i eth0

# Check for packet errors and drops
ip -s link show eth0

# Test actual throughput between Pi and another machine
# On the receiving machine:
iperf3 -s
# On the Pi:
iperf3 -c RECEIVER_IP

Wired Ethernet is always preferable to Wi-Fi for anything running as a server. Wi-Fi links fluctuate by nature, and under CPU pressure, packet processing delays stack with retransmissions. Dropped connections, slow page loads, and stalled streams often trace back to system load rather than the network itself. Fix the system load first before chasing network problems.

Measure Before and After Every Change

Performance tuning without measurement usually chases the wrong problem. A Pi can feel slow for many reasons and symptoms often mislead. High CPU usage might not be the cause. Low CPU usage does not mean the system is fine. The only way to know is to watch what the system does under real load.

# Comprehensive snapshot of system state
vmstat 2 10

# Check for throttling events after a load session
vcgencmd get_throttled

# Current temperature and clock speed together
echo "Temp: $(vcgencmd measure_temp) | Clock: $(vcgencmd measure_clock arm)"

# Check logs from the current session for thermal or power events
journalctl -b 0 -k | grep -i "thermal\|throttl\|voltage"

Run these before applying any change to establish a baseline. Run them again under the same load after the change. If the numbers do not improve, the change did not help and may have made something else worse. This is how you tune instead of guess.

The Tuning Order That Actually Works

Tuning in the wrong order wastes time and creates false wins. Follow this sequence. Each step removes a hard cap before you move to the next one.

Power stability. Unstable voltage undermines every other change. Validate with vcgencmd get_throttled. Fix cable, supply, or shared loads before moving on.
Cooling and airflow. Stable temperatures allow clocks to stay consistent. Add a fan if temperatures exceed 75 degrees under sustained load. Check with watch -n 1 vcgencmd measure_temp.
Storage behavior. Add noatime,commit=300 to fstab. Move critical workloads to USB SSD. This step usually delivers the largest improvement for databases and containers.
Memory pressure. Enable zram. Apply sysctl tuning. Monitor with free -h under load. If swap is still being used heavily, reduce service density before tuning further.
CPU governor. Only now does governor tuning matter. Set performance if power and cooling are solid. Otherwise leave ondemand alone.
Workload-specific changes. Database pragma settings, container memory limits, media server scheduling. These only help once the foundation is stable.

Stability vs Speed Tradeoffs

Pushing clocks higher can improve short tasks but narrows thermal and power margins. Under real workloads this usually causes oscillation. The system runs fast, heats up, throttles, then repeats. The result feels slower than a stable, slightly lower speed. Raising frequency increases heat and power draw at the same time, making undervoltage events more likely and shortening the time before throttling begins.

Unstable settings do not always crash the system either. They cause subtle corruption, USB resets, or stalled I/O that surfaces later as unexplained slowdowns and service failures that are hard to trace back to the tuning change that caused them.

Good performance tuning feels uneventful. No spikes. No drops. Consistent behavior hour after hour. If you find yourself constantly tweaking things to chase stability, that is a sign the foundation is still not right.

When a Raspberry Pi Is the Wrong Tool

There is a point where tuning stops helping. When a workload consistently maxes CPU, memory, and I/O even after cleanup, the hardware is the constraint. Warning signs include constant load averages above the core count, persistent swapping despite reduced services, thermal throttling even with active cooling, and storage latency spikes during normal operation.

Some workloads need faster storage, more memory, or more cores. Sometimes spreading services across multiple boards works better than forcing one system to do everything. If predictability still means “too slow” after working through this guide, the answer is not more tuning. It is different hardware. That is not failure. That is knowing what the platform is built for.

FAQ

Why does my Raspberry Pi feel fast at first then slow down later?

Heat, storage pressure, and memory usage all build over time. Sustained load exposes limits that short tests and benchmarks miss entirely. The system is not degrading — it is hitting thermal and power ceilings that only show up after the board has been warm for a while.

How do I check the CPU governor on Raspberry Pi?

Run cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor. The default is usually ondemand. To change it, run echo performance | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor. Only do this after power and cooling are solid, or you will increase throttling rather than reduce it.

How do I speed up Raspberry Pi without overclocking?

Fix power delivery, add active cooling, move to USB SSD storage, enable zram, add noatime to fstab, and tune the CPU governor. In that order. Most users see the biggest improvement from moving off SD card and enabling zram, neither of which requires touching clock speeds.

Is overclocking worth it for server workloads?

Rarely. It often reduces stability and increases throttling under long workloads. The system runs faster briefly then throttles harder, which averages out to worse performance than stable lower clocks. Fix the bottlenecks first and overclocking usually stops looking necessary.

Do I need an SSD for good Raspberry Pi performance?

For databases, containers, and servers, yes. Random I/O overwhelms most microSD cards under real workloads. A USB SSD reduces storage latency dramatically and removes the most common bottleneck. It also eliminates the corruption risk that comes with constant SD card writes.

Why does network speed drop during disk activity?

Shared internal buses and interrupt pressure cause contention between storage and networking on a Raspberry Pi. They are not fully independent. Heavy disk activity, particularly writes, can reduce network throughput and increase latency even when the network link itself is fine.

How many Docker containers can a Raspberry Pi handle?

It depends on what each container is doing, but on a Pi 4 with 4GB RAM, three to five lightly loaded containers is a reasonable limit before memory pressure and I/O contention start causing visible slowdowns. Set memory limits on each container with mem_limit in docker-compose.yml and monitor with docker stats under real load.

References

Was this helpful?

Yes

Thanks for your feedback!