MaxRequestWorkers 是 Apache 并发处理的内存硬约束，需基于实测 worker RSS 和可用内存精准计算，并同步调整 ServerLimit、StartServers、Min/MaxSpareServers 及 php-fpm 的 pm.max_children。

MaxRequestWorkers 是 Apache 并发处理能力的“闸门”，设低了请求排队、503频发；设高了内存爆满、系统杀进程。调优不是拍脑袋定个数，而是基于内存实际占用做精准计算，并同步协调关联参数。

先确认是不是这个参数在拖后腿

别急着改配置，先看现象和数据：

• 访问 http://localhost/server-status?auto（需启用 mod_status），关注 BusyWorkers 是否长期 ≥ 90% 的 MaxRequestWorkers 值
• 日志里反复出现 "server reached MaxRequestWorkers setting" 或大量 503 Service Unavailable
• 用 curl -s "http://localhost/server-status?auto" | grep 'Waiting for connection' 发现连接堆积明显
• 压测时 Requests/sec 不升反降，top 里 httpd 进程数飙高、CPU 拉满但吞吐上不去

算出真正安全的值：只看内存，不看CPU核数

每个 Apache worker 进程（prefork 模式下）实际吃多少内存，才是硬约束。PHP 扩展、SSL、日志模块都会拉高它：

Apache Superset Dashboard and SQL Exploration Skill

Apache Superset 是一个广泛采用的开源 BI 平台，用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时，此技能非常有用。

下载

• 运行 ps aux --sort=-%mem | grep httpd | head -n 5，看 RSS 列（单位 KB），取中间值作为单进程内存估算值
• 可用内存 = 总物理内存 × 0.7（留系统、数据库等余量）
• MaxRequestWorkers ≈ 可用内存（KB） ÷ 单进程 RSS（KB），结果向下取整（比如算出 342，建议设 320）
• 举例：16 GB 机器，实测 worker RSS ≈ 32 MB（32768 KB），可用内存约 11264 MB → 11264 × 1024 ÷ 32768 ≈ 352 → 建议设 320

改完必须同步调整的四个配套参数

MaxRequestWorkers 不是独立开关，它和 prefork 的其他参数是联动的：

• ServerLimit：必须 ≥ MaxRequestWorkers，且只能写在主配置文件（如 httpd.conf），否则重启报错 “MaxRequestWorkers of XXX is not allowed”
• StartServers：设为 MaxRequestWorkers × 0.1～0.2（如 320 → 设 32～64），避免冷启动后瞬间扩容不及
• MinSpareServers / MaxSpareServers：分别设为 MaxRequestWorkers × 0.05 和 × 0.3（如 320 → 16 和 96），空闲太少扛不住突增，太多又白占内存
• 如果用 PHP + php-fpm：务必让 php-fpm 的 pm.max_children ≥ MaxRequestWorkers，否则请求卡在 fpm 队列，表现就是延迟飙升、504 Gateway Timeout

常见翻车点：调高反而更慢？

很多人改完发现更卡，问题往往不在 Apache 配置本身：

• 没调 ulimit -n：每个 worker 需要多个文件描述符，ulimit -n 至少设到 65536，否则报 “unable to create or open stream”
• 忽略 ListenBacklog：Linux SYN 队列默认太小，ListenBacklog 511 能防队列溢出丢包
• KeepAlive 关错了：Off 会加重 fork 压力；建议 KeepAlive On + KeepAliveTimeout 2 + MaxKeepAliveRequests 100
• 还在用 prefork 处理高并发 PHP：fork 开销大、内存浪费严重，换成 mpm_event + php-fpm 是更可持续的选择