☰

Apache2 MPM 事件：更多线程还是更多进程？

tag-icon • tag-icon apache-http-server php fastcgi
Apache2 MPM 事件：更多线程还是更多进程？

我们正在举办Apache2网络服务器MPM 事件和PHP-FPM。为了用最少的服务器资源来满足高流量的需求，我对如何最好地配置 MPM 进行了一些研究。

假设我们最多想要提供512并发连接数。因此我们要设置最大请求工作者数到512. 在其他 Apache2 默认设置下，仅此一项是行不通的，因为默认每个子线程数（二十五）与默认结合服务器限制（16）最多允许二十五X16=400并发连接。

我们现在有两种可能性：

  1. 提高每个子线程数指令（如果与线程限制) 以允许每个 Apache2 子进程有更多线程。
  2. 增加服务器限制以允许产生更多的子进程。

当然，我们也可以设定每个子线程数和线程限制都512和服务器限制到1，不是吗？

在对合理平衡进行一些研究后，我发现了以下两个主题：

两者都指出，由于共享库和缓存数据在进程的所有线程之间共享，线程消耗的静态内存更少，启动和停止所需的 CPU 周期也更少。ServerFault 上的问题讨论了在较少进程中运行更多线程的缺点，因为当进程因某种原因死亡时，所有线程都会死亡。因此，拥有更多进程将提高 Web 服务器的可靠性。PHP内存限制据我所知，如果是 PHP-FPM，它在这里不起作用，是吗？

我记得在某处读到过，每个 Apache2 子进程一次只能执行一个 PHP-FPM 请求，但我再也找不到该语句了。这当然是将 Apache2 进程的数量与 PHP-FPM 子进程的数量保持一致的原因。但这是真的吗？我不确定如何测试它，因为即使在所有 PHP-FPM 子进程都在使用的情况下，下一个空闲的子进程也会自动分配。 （请参阅下面的编辑）

由于我从未遇到过 Apache2 子进程即将死亡的情况，因此我确实会使用单个进程和系统内存允许的线程数。除了可靠性方面，有人知道这种策略的其他缺点吗？我只能猜测其中的原因16是默认的，但我找不到令人满意的解释。

编辑：使用单个 Apache2 MPM 事件子项和静态数量的 12 个 PHP-FPM 监听器，我启用了 PHP-FPM 状态页面，一晚后：

pool:                 www
process manager:      static
start time:           23/Dec/2020:00:39:06 +0100
start since:          53736
accepted conn:        42942
listen queue:         0
max listen queue:     0
listen queue len:     0
idle processes:       11
active processes:     1
total processes:      12
max active processes: 12
max children reached: 0
slow requests:        0
  • 最大活跃进程：12可以证明单个 Apache2 进程可以使用多个 PHP-FPM 进程，我想？
  • 已达到的最大子项数：0在使用时可能总是这样进程管理器：静态？
  • 自从总流程==最大活跃进程数在这种静态情况下，我是否应该增加子节点数量以加快高峰时段的 Web 服务器响应速度？虽然最大监听队列：0意味着还没有延迟的请求？所有 12 个监听器都已处于活动状态，但没有一个请求需要排队，这太巧合了吧？我会继续观察这些值并做一些研究。 编辑：这max listen queue始终表明0Linux 上存在已知的限制：https://bugs.php.net/bug.php?id=80739

相关内容