Nginxworker_connections“设置工作进程可以打开的最大同时连接数。此数字包括所有连接（例如与代理服务器的连接等），而不仅仅是与客户端的连接。另一个考虑因素是实际同时连接数不能超过当前最大打开文件数的限制”。我对此有几个疑问：
- 这个的最佳值或推荐值应该是多少？
- 使用大量工作连接有哪些缺点？
答案1
让我们采取务实的方法。
所有这些限制都是在上个世纪硬件速度慢且昂贵时硬编码和设计的。现在是 2016 年，普通的沃尔玛烤面包机可以处理的请求比默认值要多。
默认设置其实很危险。一个网站有几百个用户并不是什么了不起的事。
worker_process
相关的设定，讲到正题就解释一下吧。
nginx 作为负载均衡器：
- 1 个用于 HTTP 负载平衡的工作程序。
- 每个核心 1 个工作器用于 HTTPS 负载平衡。
nginx 作为网络服务器：
这个问题很棘手。
一些应用程序/框架/中间件（例如 php-fpm）在 nginx 之外运行。在这种情况下，1 个 nginx worker 就足够了，因为通常是外部应用程序在执行繁重的处理并消耗资源。
此外，一些应用程序/框架/中间件一次只能处理一个请求，而使它们超载会产生适得其反的效果。
一般来说，1 名工人总是安全的选择。
否则，如果您知道自己在做什么，您可以为每个核心放置一个工人。我认为这是一种优化，并建议进行适当的基准测试和测试。
worker_connections
连接总数为worker_process * worker_connections。负载均衡器模式下的一半。
现在我们来看一下烤面包机的部分。有许多被严重低估的系统限制：
- ulimits 在 Linux 上每个进程最多打开 1k 个文件（在某些发行版上为 1k 个软限制，4k 个硬限制）
- systemd limits 与 ulimits 大致相同。
- nginx 默认每个 worker 有 512 个连接。
- 可能还有更多：SELinux、sysctl、supervisord（每个发行版+版本略有不同）
1k 个 worker_connections
安全的默认值是到处都放置 1k。
它足够高，超出了大多数内部和未知站点所能承受的范围。它足够低，不会达到任何其他系统限制。
10k 个 worker_connections
拥有数千个客户端是很常见的，尤其是对于公共网站而言。我已经数不清有多少网站因为默认值太低而宕机了。
生产可接受的最小值为 10k。必须增加相关系统限制才能允许此值。
不存在过高的限制（如果没有用户，限制根本不起作用）。但是过低的限制是真实存在的，会导致用户被拒绝和网站瘫痪。
超过 10,000
10k 既简单又好。
我们可以任意设置 1000kk 的限制（毕竟这只是一个限制），但这没有太多实际意义，我们永远不会得到那么多流量，而且无论如何也无法接收它。
让我们坚持使用 10k 作为合理设置。那些需要（并且确实可以）更多资源的服务将需要进行特殊调整和基准测试。
特殊场景：高级用法
有时，我们知道服务器资源不足，并且我们预计会出现无法控制的峰值。我们宁愿拒绝用户也不愿尝试。在这种情况下，设置合理的连接限制并配置良好的错误消息和处理。
有时，后端服务器运行良好，但最多一些负载，任何更多的事情都会很快变糟。我们宁愿放慢速度，也不愿让服务器崩溃。在这种情况下，配置具有严格限制的队列，让 nginx 缓冲所有热量，同时以限制的速度处理请求。
答案2
ulimit -a将告诉您系统允许进程使用多少个打开的文件。
另外，net.ipv4.ip_local_port_range设置每个 IP 启用的套接字总范围。
因此，您的数量worker_connections不能超过其中任何一个，否则您的客户端连接将排队直到达到net.core.netdev_max_backlogTCP 队列的总大小。
请记住，如果您使用 nginx 作为反向代理，则每个连接将使用两个套接字。您可能想尝试一下和net.ipv4.tcp_fin_timeout其他内核 tcp 相关超时，以尝试快速切换套接字状态。另一件需要注意的事情是，每个套接字都会分配 TCP 内存堆栈的内存，您还可以使用设置 TCP 内存堆栈的一些限制sysctl，只要您有 CPU 和足够的文件处理程序，您就可以在 RAM 中施加更大的压力。
仅供参考，如果有足够的计算资源，一台服务器配备大约 32GB 内存和一些虚拟网络接口，使用 sysctl 进行一些内核调整，即可处理 1MM 个同时连接。在我处理超过 1MM 连接并发送大约 700 字节的有效负载的测试期间，服务器需要大约 10 秒才能更新大约 120 万个同时客户端。接下来是通过绑定一些额外的 NIC 并放弃虚拟 NIC 来增加网络带宽。如果有足够的有效负载、带宽和更新所有客户端的合理时间，就可以与超过 120 万个客户端实现伪近实时通信。
祝调音愉快！
答案3
可以通过测试找到合适的大小，因为它会根据 Nginx 处理的流量类型而变化。
理论上，nginx 可以处理：max clients = worker_processes * worker_connections (* =multiply) 和 worker_processes = 处理器数量
要查找处理器，请使用：grep process /proc/cpuinfo | wc -l
答案4
当资源受限时，设置较低的限制可能会很有用。某些连接，例如保持活动连接（不仅与客户端，而且与上游服务器，也是如此），实际上是在浪费您的资源（即使 nginx 非常高效），并且对于通用服务器的正确操作不是必需的，这意味着可以安全地删除它们，以便为其余操作提供更多资源。
因此，较低的资源限制将向 nginx 表明您可能物理资源不足，并且可用资源应分配给新连接，而不是为空闲的保持活动连接提供服务，而以牺牲较新的连接为代价来建立更紧迫的连接来满足更紧迫的需求。
建议值是多少？它是默认值。
所有默认值均记录在文档中：
默认值：worker_connections 512；
并且可以在源代码级别确认event/ngx_event.c， 也
13#定义默认连接 512