How do you determine which multi-processing module a running Apache httpd 2.4 instance is using, and how would you switch it to a different one?

## Why this is a real question and not trivia Every piece of Apache concurrency tuning is MPM-specific. `ThreadsPerChild` is meaningless under prefork; `MaxRequestWorkers` counts processes under prefork and threads under worker and event; advice you read on the internet is usually written for whichever MPM the author was running. So the first step of any Apache performance conversation is establishing which MPM is actually loaded — and the answer is frequently not the one the team assumes, because installing an in-process language module can silently pull the packaging onto prefork. ## Reading the active MPM ```bash httpd -V | grep 'Server MPM' # Server MPM: event ``` On Debian and Ubuntu the binary is `apache2` and the wrapper is `apache2ctl`, so it is `apache2ctl -V`. The same information appears in `httpd -M`, which lists every loaded module: exactly one line will be `mpm_event_module`, `mpm_worker_module` or `mpm_prefork_module`. `httpd -V` prints more than the MPM — it also shows the compiled-in server root, the config file path and several `-D` defines. Reading the config file path from there is a good habit, because on a host with several installs you may be editing a file the running server never reads. ## What changed in 2.4 In httpd 2.2 the MPM was chosen at build time; you got a binary that *was* a prefork server or *was* a worker server, and distributions shipped several binaries. Since 2.4 the MPM is a dynamically loadable module, so a single binary can run any of them and the choice moved into configuration. This is why the answer to "which MPM" is a runtime question at all. ## Switching The rule is that exactly one MPM module may be loaded; loading two is a fatal startup error, and loading none is as well. Mechanically: - Red Hat family: the `LoadModule mpm_*_module` lines live together in a single MPM config file included from `conf.modules.d`. Comment out the current one, uncomment the one you want. - Debian family: `a2dismod mpm_prefork` then `a2enmod mpm_event`, which toggle symlinks in `mods-enabled`. The tooling refuses to leave you with two enabled. Then restart. A graceful reload lets existing children finish their current work and applies most configuration changes, but changing the MPM changes how children are created and what they contain, so a full stop and start is the honest way to apply it. The same is true of a small number of MPM directives — `ServerLimit` and `ThreadLimit` in particular are only re-read on a full restart. ## Verify after, not just before Two things bite people here. First, each MPM has its own tuning block, and the values that were tuned for the old MPM usually make no sense for the new one — a `MaxRequestWorkers` sized for prefork processes is a very different setting once it counts threads. Second, moving from prefork to a threaded MPM means every loaded module must be thread-safe; if an in-process interpreter module is the reason you were on prefork, switching the MPM without also moving that workload out of the server produces intermittent corruption rather than a clean failure. So confirm with `httpd -V` that the switch took effect, and confirm with `httpd -M` that the module set you are now running threaded is one you are willing to run threaded.