为什么静态与动态进程管理对 php-fpm 的内存使用影响如此之大？

Question

我最近将一个客户端迁移到运行 Nginx + PHP-FPM 的 EC2 实例。当我第一次设置服务器时，我设置pm=static了 40 个工作进程。一周左右后，我决定尝试pm=dynamic最多 200 名工人和最少 30 名工人。

我注意到在静态设置下，40 个进程占用了大约 2.3GB 的内存，而在动态设置下，我看到 60 个进程仅使用 1.2GB 内存的峰值。

请参阅下面来自 New Relic 的图表，我的注释为红色。

可以看到，在 11/25 白天，我从静态更改为动态并重新启动了 php-fpm。之后我们可以看到48个进程只占用了990MB，60个进程只占用了1.2GB内存。

什么可能导致静态和动态管理之间的这种差异？难道是动态的，我将最大请求数设置为 50？也许静态内存使用更多是由于内存泄漏而不是 php-fpm 的内部问题？

Answer 1

pm.max_requests不特定于任何进程管理器 ( pm) 模式。它的好处是在它们单独处理指定数量的请求后重新生成工作进程。

它可以避免极端情况下的内存泄漏，但通常它只会释放执行内存饥渴的脚本时累积的内存分配。内存分配堆积，分配的内存总量增加，但仅在退出时释放（因此在重生时）。

正如你所说，你pm.max_requests在使用pm static. 您应该已经看到了差异，当然不仅仅是一条平坦的线。

pm dynamic具有根据其中的空闲进程数 ( pm.min_spare_servers, pm.max_spare_servers)停止工作程序的额外好处，这是一种测量即时负载的度量标准。停止无用的进程会以进程处理 (CPU) 为代价释放相关的分配内存，这会pm.min_spare_servers抵消确保在出现峰值时的安全缓冲，保持空闲的工作人员准备好处理请求。

现在，如果你真的在照顾你的记忆，pm ondemand更积极，（de）产生（不再）需要的进程。这种模式最接近边缘，因为它不会像 那样吸收尖峰信号pm dynamic，但它对内存消耗的影响最小（与使用更多 CPU 进行进程管理目的相对）。

TL; 博士

任何工作进程的内存分配都会堆积起来。如果一个特定的请求是内存饥渴的，它将在处理工作内存分配中占据首位，并且在进程停止之前不会被释放。

使用pm.max_requests到回收处理，无论您使用的模式。

pm.dynamic将根据另一个标准回收进程，即负载，并在进程过多空闲时终止进程。更高的进程周转率更有可能防止它们过多地占用内存，代价是用于进程管理的 CPU 周期更多。