我一直在进行压力测试PHP-FPM设置为静止的使用工作量， 和NGINX正在运行Ubuntu 服务器 22.04在过去的几天里，我记录了每种情况的结果。当我看到它们时，我觉得 max_children 的数量似乎并不重要。这让我很困惑，因为网络上的所有文章都建议使用各种方法来计算适当的数量以最大限度地提高性能。但似乎没有一个真正适用于我的情况。
我运行这个4 核和4 GB 内存。我有一个测试 php 脚本，用于拉取和打印11千来自的行MySQL桌子，1 兆字节大文件。
平均进程大小为12.5 兆 对于 max_children 来说，结果是相同的10，50，100。 和200，服务器超载。
这让我想到，也许这与核心数量有关，但不，只有4 最大子项，结果比前面提到的要低，尽管不是很多。8 max_children 已经几乎相同。
在超时和掉线开始发生之前，max_children 的所有场景（4、8、10、50、100）都可以处理最多 500 个连接。
有人能向我解释一下，这是怎么可能的吗？我遗漏了什么？
编辑：
根据 Rick 的建议，我尝试将 MySQL max_connections 从默认的 151 增加到 351，这是在计算可用 RAM 的最大数量之后实现的。这完全没有影响结果，所以我从头开始，从1 最大子项和1 个工作线程向上，在此过程中，遇到了更多我无法解释的行为。
唯一有意义的 max_children 似乎是6。超过该限制就不会带来任何额外请求。
虽然仅测试单线程工作请求CPU 负载不断上升php-fpm 子项添加后保持不变，无论从 wrk 向其抛出多少连接。
平均总请求数的上限30秒长压力测试即将到来11371请求。这可以达到6 最大子项 似乎与 CPU 负载有关，在峰值期间达到 90%。无论 max_children 的数量是多少，都无法满足更多请求。
在测试时发生了相当奇怪的行为4 个线程。相同连接数的结果低于单线程压力测试，但延迟较低，我想这是有道理的。但说到CPU 负载，以下任何内容8 个连接有大约70% 负载，无论最大子节点数，但一旦连接数量超过一个，9，CPU 负载急剧增加，超过20％max_children 的数量更高。我唯一想到的是，这一定与 CPU 核心数量有关，在本例中是 4 个，每个核心只能处理 2 个同时连接。除此之外，我一无所知。
我的假设是，至少就我的情况而言，瓶颈是中央处理器。我从未耗尽内存。我为NGINX和 MySQL联系。如果可以确认这一点并进一步解释，我将不胜感激。此致。
答案1
重要的指标是“每小时连接数”。这是系统的“容量”。压力测试测量“同时连接数”，这几乎无关紧要。
核心数量很少是您描述的设置中的限制因素。另一方面，如果您的 CPU 确实用完了，我们应该查看慢速查询，看看可以优化哪些方面。
如果一个连接只需要 20 毫秒就能处理一个页面，那么你调整的任何旋钮都无关紧要。连接来去得足够快。如果你能将 20 缩短到 15，你就能处理 20/15 倍的“每小时连接数”。也就是说，通过改进代码，每个“活动”连接都可以更快地完成。
压力测试通常测试在系统过载并出现“崩溃”之前可以多快创建新连接。这种“崩溃”实际上是许多进程相互碰撞，试图共享相同的资源（CPU、锁、内存、缓存、网络、I/O 等等）。
MySQL 旨在共享均匀地。这意味着连接彼此交错。真正的解决办法是推动问题向上堆栈。即限制连接数，最好是在 webserver 层。
MySQL 只能处理几十个积极的同时连接。
max_connections包括“休眠”连接（不运行 SQL）。您的数字显示 100 没有“崩溃”，但我怀疑响应时间已经受到影响。如果将 Web 服务器的“max children”设置为大于 MySQL 的“max_connections”，压力测试可能会发现 Web 服务器有时会“无法连接”。
在实际系统中（不仅仅是压力测试），将“max children”保持在“max_connections”以下可能会更好，因为浏览器知道如何处理该错误。
（更多的）
- “计算最大 RAM 容量”——这是徒劳的。MySQL 没有合适的公式。
- 什么是“工作线程”？在 MySQL 中，请注意
Threads_running；如果线程数超过 12 个，则 MySQL 已经非常繁忙。如果该数字更高，线程之间就会相互干扰，实际上减速。 top、htop等是查看正在使用的核心数的方法。即使在非常繁忙的服务器上，我也几乎从未看到过所有核心都处于繁忙状态。其他资源通常首先受到影响。- 如果 CPU 是瓶颈，我们需要查看查询和模式。
- 用户想要“低延迟”。添加太多线程会导致延迟不佳。