Optimizing Ubuntu Droplet CPU spikes for a high-traffic download site?

Hi there,

Good that you are optimizing before scaling, that is the right order.

For PHP-FPM, the key setting is pm.max_children which should be based on how much RAM each PHP process uses. Check your average process size first:

ps --no-headers -o "rss,cmd" -C php-fpm8.x | awk '{ sum+=$1 } END { print sum/NR/1024 " MB average" }'

Then divide your available RAM by that number. A rough starting point for a 2GB Droplet with Redis already handling object cache:

pm = dynamic
pm.max_children = 20
pm.start_servers = 5
pm.min_spare_servers = 3
pm.max_spare_servers = 8
pm.max_requests = 500

For downloads specifically, the CPU spike is often not PHP at all but Nginx serving large files. Make sure you are using X-Accel-Redirect to let Nginx handle file delivery directly rather than routing downloads through PHP/WordPress:

location /protected-downloads/ {
    internal;
    alias /var/www/your-files/;
}

For DigitalOcean monitoring alerts, CPU above 80% for 5 minutes is a useful threshold that avoids false alarms from short spikes. Memory above 85% is worth watching too since WordPress with Redis can creep up. You can set these under Manage > Monitoring in the control panel.

On Redis, make sure you are also using a page cache plugin like WP Rocket or W3 Total Cache with full page caching enabled, not just object caching. Object caching alone still runs PHP for every request, full page caching serves cached HTML directly from Nginx and bypasses PHP entirely for repeat visitors.

Heya,

innodb_buffer_pool_size defaults to 128M, which is too small for anything beyond a toy install. On a shared box running Nginx, PHP-FPM, Redis, and MariaDB together, a reasonable starting point is around 50% of total RAM, leaving enough headroom for the other services rather than the 60-70% you’d give a dedicated database server:

[mysqld]
innodb_buffer_pool_size = 1G

Adjust that number to your actual Droplet size. Also worth turning on the slow query log temporarily during a traffic spike to check whether any queries, especially anything counting or logging downloads, are missing an index and getting slower under load rather than just busier.

Cloudflare. Since it’s already in front of the site, confirm your Cache Rules are actually caching full HTML responses, not just static assets like images and CSS. If Googlebot’s recrawl is hitting uncached PHP-rendered pages every time, that’s PHP-FPM and MariaDB load you could be avoiding entirely at the edge, this is the same problem Bobby’s full-page-cache recommendation solves at the origin, but catching it at Cloudflare means the origin never sees the request at all. Separately, for the simultaneous-download-traffic spikes, Bot Fight Mode (or Super Bot Fight Mode on a paid plan) is worth turning on if you haven’t, it targets scrapers and disguised bot traffic specifically, not legitimate crawlers like Googlebot, so it won’t hurt your indexing.

Hope that this helps!