Challenge 2: Setting MaxRequestWorkers to 2000 on a 4GB Server —
Solution Walkthrough

The math:

2000 processes x 50MB per process = 100,000MB = ~100GB of RAM needed
to actually run 2000 simultaneous PHP processes.

The server only has 4GB. 4GB / 50MB per process is only about 80
processes' worth of real memory -- nowhere close to 2000.

What will actually happen:

Setting MaxRequestWorkers to 2000 does not create 100GB of memory out
of nothing -- it just tells Prefork it's allowed to spawn up to 2000
processes if demand calls for it. Under real heavy load, as more and
more processes spawn to handle incoming requests, the server will run
out of physical RAM long before reaching anywhere near 2000 -- almost
certainly somewhere around the ~80-process mark this server's real
RAM can support. Past that point, per this chapter's own warning box,
the server either starts swapping heavily (each swap read/write is
orders of magnitude slower than RAM, so response times collapse) or
the Linux OOM killer starts forcibly terminating processes to
reclaim memory, potentially including Apache's own worker processes
or other services on the same machine. The configured number in
MaxRequestWorkers was never the real constraint -- available RAM
always was.

WHY THIS WORKS AS AN ANSWER
------------------------------
This exercise checks that the reader can apply the chapter's warning
box to a concrete case with real numbers, and correctly identifies
that a directive's configured value is not the same thing as a
server's actual physical capacity to honor it.