MaxRequestWorkers应根据可用内存和单进程内存占用计算，公式为“可用内存×0.8÷单进程平均内存”，并确保ServerLimit≥该值，同时php-fpm的pm.max_children需与之匹配且不低于它。
Apache的MaxRequestWorkers设多少才不拖垮服务器
这个值不是越大越好，它直接决定Apache能同时处理多少PHP请求，但每开一个进程/线程就吃内存。设高了，内存爆掉，系统开始杀进程；设低了，请求排队，用户看到503或超时。
实操建议：
- 先用
free -h看可用内存，再估算单个php-fpmworker或mod_php进程平均占多少——通常在30–80MB（取决于PHP扩展和代码） -
MaxRequestWorkers = 可用内存 × 0.8 ÷ 单进程平均内存，比如16GB空闲内存、每个进程50MB → 约256 - 若用
mpm_event+php-fpm，MaxRequestWorkers可设更高（因Apache本身不解析PHP），但要同步调大php-fpm的pm.max_children - 别忘了
ServerLimit必须 ≥MaxRequestWorkers，否则重启Apache时该值会被截断
为什么mpm_prefork在高并发下容易卡死
它为每个请求 fork 一个独立进程，没有共享内存，启动慢、内存开销大，且无法复用连接。一旦并发突增，fork风暴会打满CPU，httpd响应变慢甚至假死。
常见错误现象：
立即学习“PHP免费学习笔记（深入）”；
- top里
httpd进程数飙升，%CPU接近100%，但Requests/sec不升反降 - 日志中频繁出现
server reached MaxRequestWorkers setting - strace看大量
clone()失败或ENOMEM
换成mpm_event是更现实的选择（前提是PHP走php-fpm，不嵌入Apache）：
-
mpm_event用少量线程管理连接，把实际执行交给php-fpm子进程池，连接复用率高 - 确认
ListenBacklog≥ 511（避免SYN队列溢出） - 禁用
KeepAlive Off？不一定——短连接反而加重fork压力；建议KeepAlive On+KeepAliveTimeout 2+MaxKeepAliveRequests 100
php-fpm的pm.max_children和Apache怎么对齐
Apache只是“前端代理”，真正干活的是php-fpm。如果MaxRequestWorkers设300，但pm.max_children只设50，那250个请求会卡在fpm队列里，表现就是延迟飙升、504 Gateway Timeout。
关键判断点：
- 查
php-fpm状态页（需开启pm.status_path = /status），关注active processes和max active processes是否长期接近上限 -
pm.max_children应 ≥MaxRequestWorkers，但也不能远超——否则fpm子进程空转吃内存 - 用
pm = dynamic比static更稳：pm.start_servers按CPU核心数设（如4核→设4），pm.min_spare_servers/pm.max_spare_servers控制弹性伸缩 - 务必检查
rlimit_files：每个fpm子进程都要打开文件描述符，ulimit -n至少设到65536，否则报unable to create or open stream
并发压测时503 Service Unavailable到底卡在哪
不是Apache挂了，而是请求被明确拒绝——说明MaxRequestWorkers已满，且ListenBacklog也满了，新TCP连接直接被内核丢弃。
排查路径很窄，但容易漏：
- 看
ss -s输出里的tcp:段，重点关注orphan和tw（TIME_WAIT）数量，若orphan持续 > 256，说明连接来不及accept - 检查
/proc/sys/net/core/somaxconn是否 ≥ListenBacklog（默认常为128，不够用） - Apache错误日志里搜
server reached MaxRequestWorkers，不是Segmentation fault那种崩溃，是“我主动拒单” - 别只盯着Apache：
php-fpm慢日志（slowlog）里如果有大量>1s的记录，上游再调高并发也没用——得先优化SQL或IO
最常被跳过的一步：调整完配置后，必须systemctl restart php-fpm && systemctl restart httpd，只reload Apache不会重载mpm模块参数。
