Apache MPM Prefork 传统模式适用场景指南

Prefork MPM是专为非线程安全模块设计的多进程模式，成熟稳定、进程隔离性好，但内存占用高、不适用于高并发；仅当必须运行mod_php（旧版PHP+非线程安全扩展）、依赖明确仅支持prefork的遗留模块、且无法引入反向代理时才应选用。

Prefork MPM 不是“过时就该淘汰”的模块，而是一个有明确边界、依然有效的工具——它只在特定条件下才真正必要：运行非线程安全的嵌入式模块，且无法改用外部进程模型。现代部署中绝大多数场景已不适用，但理解它的适用边界，能帮你避开误配导致的内存暴涨、连接堆积或静默崩溃。

哪些情况仍必须用 Prefork

只有当同时满足以下全部条件时，Prefork 才是合理选择：

• 后端是 PHP，并且必须使用 mod_php（而非 php-fpm），且 PHP 版本较老（如 5.6 或更早），扩展含 OCI8、Sybase、某些旧 MySQL 扩展等非线程安全驱动
• 应用依赖其他明确声明仅支持 prefork 的 Apache 模块（如极少数遗留的 mod_python 1.x、自研 C 模块未做线程安全改造）
• 运行环境无法引入反向代理层（例如受限于网络策略、安全审计或老旧容器平台，不能部署 nginx + php-fpm 或 Apache + proxy_fcgi）

哪些常见场景其实不该用 Prefork

这些做法看似“稳妥”，实则违背现代架构逻辑，会人为制造瓶颈：

• 用 PHP-FPM 但还坚持启用 prefork —— 此时 Apache 只需转发请求，进程隔离毫无意义，反而因每个连接独占进程，迅速耗尽内存
• 部署 Python 应用（如 Django）用 uWSGI/Gunicorn + proxy_http，却选 prefork —— 同样属于资源错配，event 或 worker 更轻量、更高效
• 为“图省事”保留默认 prefork 配置，未评估业务并发与内存实际占用 —— 尤其在 4GB 以下内存服务器上，MaxClients 设为 256 就可能吃掉 8GB RSS 内存（按均值 30MB/进程估算）

确认和启用 Prefork 的关键操作

配置文件修改只是表象，真正生效靠的是模块加载顺序：

• 先验证当前模式：apache2ctl -V | grep MPM 或 httpd -V | grep MPM，输出必须为 prefork
• Debian/Ubuntu 系统：a2dismod mpm_event mpm_worker && a2enmod mpm_prefork && systemctl restart apache2
• RHEL/CentOS 系统：编辑 /etc/httpd/conf.modules.d/00-mpm.conf，注释 mpm_event_module 行，取消注释 mpm_prefork_module 行
• 切忌只改 mpm_prefork.conf 却未禁用冲突模块——Apache 会优先加载第一个发现的 MPM，其余配置被忽略

Prefork 参数调优要点

参数不是套模板，而是根据物理内存和真实进程开销动态计算：

• MaxRequestWorkers（旧称 MaxClients）= 可用内存（GB）× 1024 ÷ 单进程平均 RSS（MB）。用 ps aux --sort=-%mem | grep httpd | head -3 查看实际值，别用“30MB”拍脑袋
• StartServers / MinSpareServers 建议设为 3–5，避免冷启动拉起过多空闲进程；MaxSpareServers 控制上限，设为 MaxRequestWorkers 的 1.2–1.5 倍较安全
• MaxRequestsPerChild 推荐 1000–5000。设为 0 表示永不回收，易累积内存泄漏；设过小（如 100）会导致频繁 fork，CPU 负载异常升高
• 每次修改后必须执行 apachectl configtest 校验语法，再用 systemctl reload apache2 平滑生效