17.9 How Nginx and Apache use CPU and RAM

By Ravindra Bagale Last updated: 3 October 2026

Why the web server is the reason the size matters

Chapter 6 installed Nginx or Apache. Scaling gives that process enough CPU and RAM for the next connection. A request to example.com arrives on port 80, often from the load balancer.

Nginx uses a few worker processes. Each worker runs an event loop and watches many connections. It does not start a heavy process per visitor. Each connection still uses memory for buffers and CPU to read, to do TLS if you enabled it, and to pass the page to PHP-FPM or Node.

Apache with the prefork MPM uses one process per connection, and that process stays in RAM while it waits. The worker and event MPMs use threads, closer to Nginx. The service is httpd on Amazon Linux and apache2 on Ubuntu. Check with sudo service nginx status or sudo service httpd status. Restart with sudo service nginx restart or sudo service httpd restart. Do not run both on port 80.

PHP usually sits in PHP-FPM, a pool of workers. Each worker is RAM. When every worker is busy, Nginx is still up and returns 502 because the upstream did not answer. If the listen queue fills, the visitor waits and then times out. If you start too many workers for 1 GiB, the box swaps and every page is slow even though you "added capacity" inside the config.

So a slow site with the service still running is normal at the start of a rush. The fix is more CPU or RAM for those workers, or a second instance that takes half the connections. It is not a second copy of the same exhausted config with no extra machine.

Lab

Chala, on the lab instance only.

Run sudo service nginx status, or sudo service httpd status if this box is Apache.
You should see the service running.
Run nproc.
Start one yes > /dev/null & for each CPU.
Reload example.com in the browser.
You should see the page get slow while the service still says running. That is a queue, not a stopped web server.
Run pkill yes.
Reload the page. You should see it answer again.