MaxClients是Apache性能调优中最常被提及也最容易设错的参数之一。它直接决定了Apache在同一时刻能够处理的最大并发请求数，一旦触及上限，后续请求只能排队等待，用户端的表现就是页面加载变慢、请求超时，甚至出现连接被拒绝的情况。而如果盲目调大，又会把服务器内存吃光，触发swap交换后整个系统性能断崖式下跌。想把MaxClients调对，需要先弄清楚Apache的工作模式和每个进程的内存消耗。
一、先搞清楚Apache的工作模式
调整MaxClients之前，必须先确认Apache运行的是哪种MPM（多处理模块）。不同的MPM下，这个参数的含义和影响完全不同。可以通过命令查看当前模式：
httpd -V | grep -i mpm # 或者 apachectl -V | grep SERVER_MPM
在CentOS或RedHat系统上，配置文件通常位于/etc/httpd/conf.modules.d/目录下，找到类似00-mpm.conf的文件，看哪一行LoadModule没有被注释即可。Debian系则是在/etc/apache2/mods-enabled/目录下查看已启用的mpm模块软链接。
prefork模式是最传统的模式，每个请求由一个独立的进程处理。进程之间完全隔离，稳定性好，兼容那些不支持线程安全的旧模块（比如非线程安全的PHP扩展），但内存开销大。在这个模式下，MaxClients就是最大进程数。
worker模式则采用多进程多线程的架构，每个进程下再派生多个线程，每个线程处理一个请求。内存占用明显更低，同样的硬件可以支撑更多的并发。在这个模式下，MaxClients指的是最大线程数，而控制进程数的参数是ServerLimit乘以ThreadsPerChild。换句话说，worker模式下的真实连接上限由这两个值共同决定。
需要注意版本差异。在Apache 2.4中，MaxClients这个名字被改成了MaxRequestWorkers，功能完全一样。老配置里写MaxClients依然兼容，但日志里会有提示，建议迁移到新名称，避免日后维护时产生困惑。
二、用内存公式估算MaxClients的合理值
MaxClients不是拍脑袋定的，有一个被广泛验证的计算公式：MaxClients =（服务器总内存 - 系统和其他进程预留内存）/ 单个Apache进程的平均内存占用。这个公式的核心思想是：在最坏情况下，所有Apache进程同时达到峰值内存时，服务器不能进入swap状态。
先看怎么测量单个进程的内存。对于prefork模式，可以用下面的命令统计所有httpd进程的常驻内存：
ps -ylC httpd --sort:rss
# 重点关注RSS列，单位是KB
# 也可以用下面的方式求平均值
ps -o rss -C httpd | awk 'NR>1{sum+=$1;n++}END{print sum/n/1024 " MB"}'举个例子：一台8GB内存的服务器，系统、数据库、缓存服务等预留2GB，剩余6GB可用。实测每个Apache进程平均占用50MB（跑PHP应用的进程通常在30MB到80MB之间，取决于加载的模块和业务复杂度），那么MaxClients = 6144MB / 50MB ≈ 122，向下取整设为120比较稳妥。千万别照搬网上教程里的256或512，那些数字往往是基于特定内存配置得出的，直接复制到小内存机器上就是灾难。
对于worker模式，计算的对象变成线程。单个线程的内存开销远小于进程，一般在几MB级别，所以同样的硬件能支撑的MaxClients会大得多。但要注意PHP等应用在worker模式下必须使用线程安全的版本，否则容易出现莫名其妙的崩溃，这也是很多生产环境仍然坚持用prefork的原因。
三、实际配置修改与验证方法
找到配置位置。prefork模式下，相关参数通常在一个<IfModule mpm_prefork_module>块中，示例配置如下：
<IfModule mpm_prefork_module>
StartServers 8
MinSpareServers 5
MaxSpareServers 20
ServerLimit 150
MaxRequestWorkers 150
MaxConnectionsPerChild 4000
</IfModule>这里有一个非常关键的坑：在prefork模式下，MaxRequestWorkers的值不能超过ServerLimit，否则Apache会直接拒绝启动并在错误日志中提示。ServerLimit是硬上限，平时设置成和MaxRequestWorkers相等即可；只有需要动态调大并发时才把ServerLimit设得略高一些。修改完配置后先测试语法再平滑重启：
httpd -t # 输出 Syntax OK 后执行 apachectl graceful
验证效果要看两个地方。一是用top或htop观察负载高峰期的内存使用和swap占用，如果si、so列长期不为零，说明MaxClients还是偏大，应该下调。二是看状态页，启用mod_status后在/server-status页面可以实时观察当前正在处理的请求数和排队情况。如果发现处理数长时间贴着MaxClients上限，同时日志里出现server reached MaxRequestWorkers setting的字样，说明并发需求确实超过了当前配置，这时可以考虑加大内存或者优化应用本身。
还有一种常见情况是配置明明合理却频繁报503错误。这往往不是MaxClients的问题，而是后端的PHP-FPM进程池不够用，Apache的代理连接池排队超时导致。排查时要把Apache层和FastCGI层分开看，两边的能力要匹配，任何一端成为瓶颈都会拖垮整体吞吐。
四、调优之外的整体思路
MaxClients调优只是Apache性能体系中的一环。如果应用层每个请求要跑500毫秒，把并发上限调得再高也只是让更多的慢请求同时堆积，内存压力线性上升而吞吐没有明显改善。降低单请求耗时才是根本，常见手段包括给静态资源启用缓存、把PHP升级到更高版本、给数据库慢查询建索引等。
另外可以考虑在Apache前面加一层Nginx做反向代理，让Nginx处理静态文件和长连接，Apache只专注动态请求，这样能大幅降低Apache的进程占用时间。配合KeepAlive超时的合理设置（比如KeepAliveTimeout设为2到5秒），进程释放速度会快很多，同样的MaxClients能支撑更大的实际流量。
总结一下操作步骤：确认MPM模式，实测进程内存，用公式算出上限，修改ServerLimit和MaxRequestWorkers并保持两者匹配，重启后观察内存与状态页，最后结合应用优化形成闭环。调优没有一劳永逸的数值，流量增长后要定期回顾这些参数，让配置始终和硬件、业务相匹配。
Apache性能优化MaxClients并发连接数修改时间：2026-09-14 23:28:37