默认 prefork MPM 在高并发下会卡住,因其每个进程独占 10–30MB 内存,宝塔默认 MaxRequestWorkers=256 但实际并发承载远低于此,超限后请求排队导致慢、超时或 503 错误。

为什么默认的 prefork MPM 在高并发下会卡住
宝塔面板安装 Apache 后默认启用 prefork MPM,它用多进程、每个进程只处理一个请求的方式工作。当并发连接数超过 MaxRequestWorkers(旧版叫 MaxClients),新请求就会排队等待,表现为网页加载慢、超时或 503 错误。
根本原因不是 Apache 不行,而是 prefork 模式每个进程独占内存(通常 10–30MB),开太多进程会吃光内存,所以宝塔默认值保守(如 MaxRequestWorkers 256),实际能撑住的并发远低于这个数字。
如果你的应用是 PHP CGI/FastCGI(宝塔默认)、静态文件较多,或后端响应快,event MPM 更合适;如果必须用 mod_php(已不推荐),只能选 prefork,但需更精细调优。
如何安全切换到 event MPM 并验证生效
宝塔 8.x+ 支持一键切换,但前提是没启用 mod_php(即 PHP 不是以 Apache 模块方式运行)。检查方法:httpd -M | grep php 输出为空才可切。
操作步骤:
- 进入宝塔面板 → 软件商店 → 找到 Apache → 右上角「设置」→「配置修改」→ 找到
LoadModule mpm_prefork_module这行,把它整行注释掉(前面加#) - 取消注释
LoadModule mpm_event_module modules/mod_mpm_event.so - 在
<ifmodule mpm_event_module></ifmodule>块里调整关键参数(见下一条) - 保存后执行
bt 8(重载 Apache)或直接点面板上的「重载配置」 - 验证是否生效:
httpd -V | grep MPM应输出MPM: event
注意:改完不重启或重载,配置不会生效;若启动失败,看错误日志 /www/wwwlogs/apache_error.log,常见原因是模块冲突(比如残留 mod_php)。
Apache Superset 是一个广泛采用的开源 BI 平台,用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时,此技能非常有用。
event MPM 的核心参数怎么设才不崩
event 是多线程+多进程混合模型,主线程管理连接,工作线程处理请求,对内存友好。但它对 PHP 的支持依赖 FastCGI(宝塔默认就是),不能直接跑 mod_php。
关键参数建议(写在 <ifmodule mpm_event_module></ifmodule> 内):
-
ServerLimit 32:最大进程数,别设太高,超过 32 后需同步调高MaxRequestWorkers,否则无效 -
MaxRequestWorkers 1024:总并发请求数上限,=ServerLimit × ThreadsPerChild,设太高会导致 OOM -
ThreadsPerChild 32:每个子进程的线程数,32 是较稳的值;设到 64+ 需确认 PHP-FPM 的pm.max_children跟得上 -
MinSpareThreads 75和MaxSpareThreads 250:空闲线程范围,避免频繁启停线程 -
MaxConnectionsPerChild 10000:进程处理多少请求后重启,防内存泄漏,1w 是平衡值
改完务必同步调大 PHP-FPM 的 pm.max_children(至少 ≥ MaxRequestWorkers),否则 Apache 线程发出去的请求会被 PHP-FPM 拒绝,出现 502。
调完并发还是上不去?先查这三处瓶颈
并发能力不是只靠 Apache 参数,三个地方常被忽略:
- PHP-FPM 的
pm模式:宝塔默认dynamic,但pm.max_children若仍卡在 50,Apache 千并发也白搭;建议设为static+ 合理值,或确保dynamic下的pm.max_children≥ Apache 的MaxRequestWorkers - 系统级限制:
ulimit -n查看单进程最大文件描述符,默认常为 1024;需在/etc/security/limits.conf加www soft nofile 65535和www hard nofile 65535(宝塔 Apache 以www用户运行) - 内核参数:高并发下
net.core.somaxconn(默认 128)和net.ipv4.ip_local_port_range可能成为瓶颈,临时调大用sysctl -w net.core.somaxconn=65535
最易错的是:只调 Apache,忘了 PHP-FPM 和系统限制,结果压测时卡在 502 或连接拒绝,却以为是 Apache 没调好。

















