MaxRequestWorkers 设置过低会导致请求排队、响应延迟陡增、503 错误突增、Timeout 错误增多及 server-status 中 Waiting for connection 连接堆积。
Apache Superset Dashboard and SQL Exploration Skill
下载
Apache Superset 是一个广泛采用的开源 BI 平台，用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时，此技能非常有用。
MaxRequestWorkers 设置过低会导致什么现象
Apache 在 prefork MPM 模式下，MaxRequestWorkers 是并发处理请求的硬上限。设得太低，用户请求会排队等待，表现为响应延迟陡增、Timeout 错误增多、server-status 中 Waiting for connection 状态连接堆积。常见于压测时 503 错误突增，或日志里反复出现 [mpm_prefork:notice] [pid XXXX] AH00169: caught SIGTERM, shutting down（其实是子进程因无法及时 fork 而被主进程误判）。
判断是否是该参数瓶颈：用 curl -s "http://localhost/server-status?auto" | grep 'BusyWorkers\|IdleWorkers' 查看实时负载；再对比 MaxRequestWorkers 值——若 BusyWorkers 长期接近甚至等于该值，就是瓶颈。
怎么算出合理的 MaxRequestWorkers 值
不能只看 CPU 核数或并发请求数，核心约束是内存。每个 httpd 进程（prefork 下）平均占用 20–50 MB 内存（取决于模块加载情况，如 mod_php、mod_ssl 会显著拉高）。计算公式：
- 先用
ps aux --sort=-%mem | grep httpd | head -n 5 看几个典型 worker 的 %MEM 和 RSS 值，取中位数作为单进程内存估算
- 可用内存 = 总物理内存 × 0.7（预留系统和其他服务空间）
-
MaxRequestWorkers ≈ 可用内存 ÷ 单进程 RSS（单位 KB）
例如：16 GB 机器，实测单 worker RSS ≈ 32 MB → 可用内存约 11 GB → MaxRequestWorkers ≈ 11 × 1024 ÷ 32 ≈ 350。建议向下取整到 320 或 300，留余量。
修改后必须同步调优的关联参数
MaxRequestWorkers 不是孤立参数。在 prefork MPM 下，它和以下三项强耦合：
-
StartServers：应设为 MaxRequestWorkers × 0.1～0.2，避免冷启动后瞬间扩容不及
-
MinSpareServers 和 MaxSpareServers：分别设为 MaxRequestWorkers × 0.05 和 × 0.3，防止空闲进程过多吃内存，又保证突发流量有缓冲
-
ServerLimit：必须 ≥ MaxRequestWorkers，且只能在主配置文件（非 .htaccess）中设置；若已超默认 256，不改它会导致重启时 Apache 报错 MaxRequestWorkers of 512 is not allowed
改完要执行 apachectl configtest，再 systemctl reload apache2（Debian/Ubuntu）或 systemctl reload httpd（RHEL/CentOS）。
为什么改了还是不稳定？常见踩坑点
很多团队调高 MaxRequestWorkers 后反而更频繁崩溃，问题往往不在 Apache 本身：
- 没检查 ulimit：Linux 默认
nofile（打开文件数）常为 1024，而每个 worker 至少需 2–3 个文件描述符（监听套接字 + 日志 + CGI 等），300 个 worker 至少需要 1000+，建议设为 65536，并在 /etc/security/limits.conf 和 systemd service 文件中双处配置
- MySQL 连接数超限：PHP-FPM 或 mod_php 常用持久连接，
max_connections 必须 ≥ MaxRequestWorkers × 平均每进程 DB 连接数，否则卡在 Connecting to MySQL
- 没切 MPM 模式：CentOS 8+/Debian 10+ 默认用 event MPM，但
MaxRequestWorkers 是 prefork 专属；若用 event，对应参数是 MaxRequestWorkers（仍可用）但实际生效的是 ThreadsPerChild 和 MaxConnectionsPerChild，混用会失效
真正稳定的高负载 Apache，靠的不是堆参数，而是让每个 worker 更轻（禁用不用模块、关掉 KeepAlive 或缩短 KeepAliveTimeout）、配合反向代理做连接收敛，以及把耗时操作（如图片缩放、报表生成）剥离到异步队列。参数只是最后一道闸门，不是万能解药。
ps aux --sort=-%mem | grep httpd | head -n 5 看几个典型 worker 的 %MEM 和 RSS 值，取中位数作为单进程内存估算MaxRequestWorkers ≈ 可用内存 ÷ 单进程 RSS（单位 KB）MaxRequestWorkers 不是孤立参数。在 prefork MPM 下，它和以下三项强耦合：
-
StartServers：应设为MaxRequestWorkers × 0.1～0.2，避免冷启动后瞬间扩容不及 -
MinSpareServers和MaxSpareServers：分别设为MaxRequestWorkers × 0.05和× 0.3，防止空闲进程过多吃内存，又保证突发流量有缓冲 -
ServerLimit：必须 ≥MaxRequestWorkers，且只能在主配置文件（非 .htaccess）中设置；若已超默认 256，不改它会导致重启时 Apache 报错MaxRequestWorkers of 512 is not allowed
apachectl configtest，再 systemctl reload apache2（Debian/Ubuntu）或 systemctl reload httpd（RHEL/CentOS）。
为什么改了还是不稳定？常见踩坑点
很多团队调高 MaxRequestWorkers 后反而更频繁崩溃，问题往往不在 Apache 本身：
- 没检查 ulimit：Linux 默认
nofile（打开文件数）常为 1024，而每个 worker 至少需 2–3 个文件描述符（监听套接字 + 日志 + CGI 等），300 个 worker 至少需要 1000+，建议设为 65536，并在 /etc/security/limits.conf 和 systemd service 文件中双处配置
- MySQL 连接数超限：PHP-FPM 或 mod_php 常用持久连接，
max_connections 必须 ≥ MaxRequestWorkers × 平均每进程 DB 连接数，否则卡在 Connecting to MySQL
- 没切 MPM 模式：CentOS 8+/Debian 10+ 默认用 event MPM，但
MaxRequestWorkers 是 prefork 专属；若用 event，对应参数是 MaxRequestWorkers（仍可用）但实际生效的是 ThreadsPerChild 和 MaxConnectionsPerChild，混用会失效
真正稳定的高负载 Apache，靠的不是堆参数，而是让每个 worker 更轻（禁用不用模块、关掉 KeepAlive 或缩短 KeepAliveTimeout）、配合反向代理做连接收敛，以及把耗时操作（如图片缩放、报表生成）剥离到异步队列。参数只是最后一道闸门，不是万能解药。
nofile（打开文件数）常为 1024，而每个 worker 至少需 2–3 个文件描述符（监听套接字 + 日志 + CGI 等），300 个 worker 至少需要 1000+，建议设为 65536，并在 /etc/security/limits.conf 和 systemd service 文件中双处配置max_connections 必须 ≥ MaxRequestWorkers × 平均每进程 DB 连接数，否则卡在 Connecting to MySQL
MaxRequestWorkers 是 prefork 专属；若用 event，对应参数是 MaxRequestWorkers（仍可用）但实际生效的是 ThreadsPerChild 和 MaxConnectionsPerChild，混用会失效
