哪个 php5-fpm 设置适合高并发连接数 + nginx

Question 1

我认为您可能运行了太多并发 php 进程，但如果没有更多有关资源瓶颈的信息，很难知道。我猜想您可能受到磁盘 IO 和/或 CPU 的限制，并且所有并行 PHP 进程都在争夺这些资源并相互拖慢速度。在某些时候，进程切换的开销成为一个重要因素，并且通过运行大量进程，您获得的吞吐量会减少而不是增加。您还可能会陷入或冒着耗尽 RAM 并开始交换的风险，这非常糟糕。相信 nginx 能够排队请求并保持更快请求的更高吞吐量，同时减少同时执行的请求数量。

我通常会选择 5 到 50 个 PHP 进程，这个范围的两端都有点特殊。通常为 10-15。非常高性能磁盘系统，以及超过通常的 16 个左右的核心，拥有更多进程可能是有意义的，但与拥有大量更便宜的服务器相比，这通常是一种虚假的经济。根据我的经验，除非你有很多写得很差的代码，否则在单个服务器上并行运行超过 15 个 php 进程通常没有什么好处，如果有好处，那很可能是稳定性而不是吞吐量，因为病态的长时间运行的请求堆积起来，没有多余的进程可用。

如果您拥有多个带有独立进程池的代码库，您可能需要大量进程，但可能不希望每个池有超过 3 到 5 个进程。

您确实需要大量 nginx 工作连接来处理静态文件。超过 4096 就不太可能有任何改进，只有在特殊情况下您才会看到 1000 和 4000 之间的差异。（除非您主要提供静态文件 - 这是一个完全不同的场景，但由于您谈论的是此框中的 php 进程，我不认为这里的情况是这样的）。

我怀疑你的超时时间太长了。如果没有发生任何事情，请断开连接并继续下一个。

Answer

我认为您可能运行了太多并发 php 进程，但如果没有更多有关资源瓶颈的信息，很难知道。我猜想您可能受到磁盘 IO 和/或 CPU 的限制，并且所有并行 PHP 进程都在争夺这些资源并相互拖慢速度。在某些时候，进程切换的开销成为一个重要因素，并且通过运行大量进程，您获得的吞吐量会减少而不是增加。您还可能会陷入或冒着耗尽 RAM 并开始交换的风险，这非常糟糕。相信 nginx 能够排队请求并保持更快请求的更高吞吐量，同时减少同时执行的请求数量。

我通常会选择 5 到 50 个 PHP 进程，这个范围的两端都有点特殊。通常为 10-15。非常高性能磁盘系统，以及超过通常的 16 个左右的核心，拥有更多进程可能是有意义的，但与拥有大量更便宜的服务器相比，这通常是一种虚假的经济。根据我的经验，除非你有很多写得很差的代码，否则在单个服务器上并行运行超过 15 个 php 进程通常没有什么好处，如果有好处，那很可能是稳定性而不是吞吐量，因为病态的长时间运行的请求堆积起来，没有多余的进程可用。

如果您拥有多个带有独立进程池的代码库，您可能需要大量进程，但可能不希望每个池有超过 3 到 5 个进程。

您确实需要大量 nginx 工作连接来处理静态文件。超过 4096 就不太可能有任何改进，只有在特殊情况下您才会看到 1000 和 4000 之间的差异。（除非您主要提供静态文件 - 这是一个完全不同的场景，但由于您谈论的是此框中的 php 进程，我不认为这里的情况是这样的）。

我怀疑你的超时时间太长了。如果没有发生任何事情，请断开连接并继续下一个。

Question 2

1）内存——我首先要考虑的是，如果您的脚本所做的只是一个简单的搜索，为什么它们需要 50MB 的内存——我假设如果您每秒处理数百个请求，您实际上并没有为每个用户返回数兆字节的数据。

有一个MySQL 连接器库中的错误这使得 PHP 为任何 TEXT 或 BLOB 分配最大可能大小，而不仅仅是实际需要的内存量。可以通过移至 MySQLND 库来修复此问题，无需更改代码。

2) 您的 pm.max_requests = 10000 设置可能不是一个很好的选择。如果每个请求需要 2 秒，那么您就是在告诉进程管理器在 20,000 秒或近 6 小时后重新启动每个进程。这似乎是一个非常长的时间，足以让任何内存泄漏导致进程停止。将其恢复到 500 仍然只是每 15 分钟重新启动一次，这对性能没有影响，但可能会更稳定。

3) 正如 Michael 所说，即使您能够允许与用户连接数量一样多的进程，您仍然需要找出瓶颈实际上在哪里。即使您同时拥有数百个 PHP 进程，如果它们都在等待 SQL 服务器可用，那么它们将始终排队等待并最终开始超时。

除非您可以消除瓶颈，否则您将需要实施速率限制机制，以仅允许服务器设置可以处理的查询数量，或者优雅降级以拒绝服务器当前无法处理的请求。

Answer

1）内存——我首先要考虑的是，如果您的脚本所做的只是一个简单的搜索，为什么它们需要 50MB 的内存——我假设如果您每秒处理数百个请求，您实际上并没有为每个用户返回数兆字节的数据。

有一个MySQL 连接器库中的错误这使得 PHP 为任何 TEXT 或 BLOB 分配最大可能大小，而不仅仅是实际需要的内存量。可以通过移至 MySQLND 库来修复此问题，无需更改代码。

2) 您的 pm.max_requests = 10000 设置可能不是一个很好的选择。如果每个请求需要 2 秒，那么您就是在告诉进程管理器在 20,000 秒或近 6 小时后重新启动每个进程。这似乎是一个非常长的时间，足以让任何内存泄漏导致进程停止。将其恢复到 500 仍然只是每 15 分钟重新启动一次，这对性能没有影响，但可能会更稳定。

3) 正如 Michael 所说，即使您能够允许与用户连接数量一样多的进程，您仍然需要找出瓶颈实际上在哪里。即使您同时拥有数百个 PHP 进程，如果它们都在等待 SQL 服务器可用，那么它们将始终排队等待并最终开始超时。

除非您可以消除瓶颈，否则您将需要实施速率限制机制，以仅允许服务器设置可以处理的查询数量，或者优雅降级以拒绝服务器当前无法处理的请求。

Question 3

我暂时还不能发表评论（代表人数不足），因此我将发布一个答案：如果有您的 nginx 日志就更好了。

关于您的 pool.d/www 配置：如果您将 pm 置于静态，则大多数变量都不会产生任何影响，max_children 将主要影响您的设置。（http://php.net/manual/en/install.fpm.configuration.php）或许可以尝试使用 PM“ondemand”。

您不应该从那么高的 pm.start_servers 开始。您还应该降低 min_spare_servers。

关于你的 nginx 配置： http://wiki.nginx.org/CoreModule#worker_processes “最大客户端数 = 工作进程数 * 工作连接数”

您的值“worker_rlimit_nofile”在我看来不正确。

看着http://wiki.nginx.org/CoreModule#worker_cpu_affinity使用所有的核心。

Answer