NGINX 是著名的高性能负载均衡器、缓存和Web 服务器,为全球40% 以上的最繁忙网站提供支持。 对于大多数用例,默认的 NGINX 和 Linux 设置运行良好,但实现最佳性能有时需要进行一些调整。 这篇博文讨论了在调整系统时需要考虑的一些 NGINX 和 Linux 设置。
您可以调整几乎任何设置,但这篇文章主要集中介绍那些可以通过调整使大多数用户受益的几个设置。 仅当您对 NGINX 和 Linux 有深入了解时,或者按照我们的支持或专业服务团队的指示,我们才建议您更改某些设置,我们在此不介绍这些设置。 专业服务团队与世界上一些最繁忙的网站合作,对 NGINX 进行调整以实现最高性能,并可与您合作,充分利用 NGINX 或 NGINX Plus 部署。
假设您对 NGINX 架构和配置概念有基本的了解。 这篇文章并非试图重复 NGINX 文档,而是概述了各种选项并提供了相关文档的链接。
调整时应遵循的一个好规则是一次更改一个设置,如果更改不能提高性能,则将其设置回默认值。
我们首先讨论 Linux 调优,因为某些操作系统设置的值决定了如何调整 NGINX 配置。
现代 Linux 内核(2.6+)中的设置适合大多数目的,但更改其中一些设置可能会有益。 检查内核日志中是否存在表明设置太低的错误消息,并根据建议进行调整。 这里我们仅介绍在正常工作负载下最有可能从调整中受益的那些设置。 有关调整这些设置的详细信息,请参阅 Linux 文档。
以下设置与连接及其排队方式有关。 如果您的传入连接率很高,但性能水平却参差不齐(例如,某些连接似乎停滞了),那么更改这些设置可能会有所帮助。
net.core.somaxconn
– NGINX 可以排队等待接受的最大连接数。默认值通常非常低,这通常是可以接受的,因为 NGINX 接受连接的速度非常快,但如果您的网站流量很大,则值得增加它。 如果内核日志中的错误消息表明该值太小,请增加该值直到错误停止。
笔记: 如果将其设置为大于 512 的值,请将backlog
参数更改为 NGINX listen
指令以匹配。
net.core.netdev_max_backlog
– 数据包在交给 CPU 之前被网卡缓冲的速率。 增加该值可以提高具有高带宽的机器的性能。 检查内核日志中是否存在与此设置相关的错误,并查阅网卡文档以获取有关更改它的建议。文件描述符是用于表示连接和打开文件等的操作系统资源。 NGINX 每个连接最多可使用两个文件描述符。 例如,如果 NGINX 正在代理,它通常使用一个文件描述符进行客户端连接,使用另一个文件描述符进行与代理服务器的连接,但如果使用 HTTP keepalives,这个比例会低得多。 对于服务大量连接的系统,可能需要调整以下设置:
sys.fs.file -max
– 文件描述符的系统范围限制nofile
– 用户文件描述符限制,在/etc/security/limits.conf文件中设置当 NGINX 充当代理时,与上游服务器的每个连接都使用临时或短暂的端口。 您可能想要更改此设置:
net.ipv4. ip_local_port_range
– 端口值范围的开始和结束。 如果您发现端口不足,请增加范围。 常见的设置是端口 1024 到 65000。以下是一些可能影响性能的 NGINX 指令。 如上所述,我们仅讨论您可以安全自行调整的指令。 我们建议您不要在没有得到 NGINX 团队指导的情况下更改其他指令的设置。
NGINX 可以运行多个工作进程,每个进程能够处理大量同时的连接。 您可以使用以下指令控制工作进程的数量以及它们如何处理连接:
worker_processes
– NGINX 工作进程的数量(默认为 1)。 在大多数情况下,每个 CPU 核心运行一个工作进程效果很好,我们建议将此指令设置为自动
以实现这一点。 有时您可能需要增加这个数字,例如当工作进程必须执行大量磁盘 I/O 时。worker_connections
– 每个工作进程可以同时处理的最大连接数。 默认值为 512,但大多数系统有足够的资源来支持更大的数字。 适当的设置取决于服务器的大小和流量的性质,可以通过测试发现。保持连接可以减少打开和关闭连接所需的 CPU 和网络开销,对性能产生重大影响。 NGINX 终止所有客户端连接并与上游服务器创建单独的、独立的连接。 NGINX 支持客户端和上游服务器的保持连接。 以下指令与客户端保活相关:
keepalive_requests
– 客户端可以通过单个保持连接发出的请求数。 默认值为 100,但更高的值对于使用负载生成工具进行测试尤其有用,因为负载生成工具通常会从单个客户端发送大量请求。keepalive_timeout
– 空闲保持连接保持打开的时间。以下指令与上游保活相关:
keepalive
– 每个工作进程保持打开的与上游服务器的空闲保持连接的数量。 没有默认值。要启用与上游服务器的保持连接,您还必须在配置中包含以下指令:
proxy_http_version 1.1; proxy_set_header连接“”;
记录每个请求都会消耗 CPU 和 I/O 周期,减少影响的一种方法是启用访问日志缓冲。 通过缓冲,NGINX 不会为每个日志条目执行单独的写入操作,而是缓冲一系列条目并在单个操作中将它们一起写入文件。
要启用访问日志缓冲,请将buffer= size
参数包含在access_log
指令中;当缓冲区达到大小
值时,NGINX 会将缓冲区内容写入日志。 要让 NGINX 在指定的时间后写入缓冲区,请包含flush= time
参数。 当两个参数都设置时,当下一个日志条目无法容纳缓冲区或缓冲区中的条目超过指定时间时,NGINX 会将条目写入日志文件。 当工作进程重新打开其日志文件或关闭时,也会写入日志条目。 要完全禁用访问日志记录,请将off
参数包含在access_log
指令中。
操作系统的sendfile()
系统调用将数据从一个文件描述符复制到另一个文件描述符,通常实现零拷贝,这可以加快 TCP 数据传输。 为了使 NGINX 能够使用它,请在http
上下文或服务器
或位置
上下文中包含sendfile
指令。 然后,NGINX 可以将缓存或磁盘上的内容写入套接字,而无需任何上下文切换到用户空间,从而使写入速度极快且消耗更少的 CPU 周期。 但请注意,由于使用sendfile()
复制的数据绕过了用户空间,因此它不受常规 NGINX 处理链和更改内容的过滤器(例如gzip
)的影响。 当配置上下文同时包含sendfile
指令和激活内容更改过滤器的指令时,NGINX 会自动禁用该上下文的sendfile
。
您可以设置各种限制,以帮助防止客户端消耗过多资源,这可能会对系统性能、安全性和用户体验产生不利影响。 以下是一些相关指令:
limit_conn
和limit_conn_zone
– 限制 NGINX 接受的客户端连接数,例如来自单个 IP 地址的连接数。 设置它们可以帮助防止单个客户端打开过多的连接并消耗超过其份额的资源。limit_rate
– 限制每个连接向客户端传输响应的速率(因此打开多个连接的客户端可以为每个连接消耗这么多的带宽)。 设置限制可以防止系统因某些客户端而超载,从而确保所有客户端的服务质量更加均匀。limit_req
和limit_req_zone
– 限制 NGINX 处理的请求速率,与设置limit_rate
具有相同的好处。 它们还可以提高安全性,特别是对于登录页面,通过将请求率限制为对于人类用户来说合理但对于试图用请求压垮您的应用的程序(例如DDoS 攻击中的机器人)来说太慢的值。上游
配置块中服务器
指令的max_conns
参数 - 设置上游组中服务器接受的最大同时连接数。 施加限制可以帮助防止上游服务器过载。 将值设置为 0(零,默认值)表示没有限制。队列
(NGINX Plus)——当上游组中的所有可用服务器都达到其max_conns
限制时,创建一个队列,请求将被放置在该队列中。 该指令设置队列中请求的最大数量,以及返回错误之前请求等待的最长时间(默认为 60 秒)。 如果省略此指令,请求将不会排队。NGINX 的一些附加功能可用于提高 Web应用的性能,实际上并不属于调优的范畴,但值得一提,因为它们的影响可能很大。 它们包括缓存和压缩。
通过在对一组 Web 或应用服务器进行负载均衡的 NGINX 实例上启用缓存,您可以显著改善客户端的响应时间,同时显著减少后端服务器上的负载。 缓存本身是一个主题,我们不会在这里讨论它。 请参阅NGINX Plus 管理指南。
压缩发送给客户端的响应可以大大减少其大小,从而减少它们占用的网络带宽。 但是,由于压缩数据会消耗 CPU 资源,因此在真正值得减少带宽使用量时,它最有用。 需要注意的是,您不应该对已压缩的对象(例如 JPEG 文件)启用压缩。 有关更多信息,请参阅NGINX Plus 管理指南。
有关详细信息,请参阅:For more information, see:
“这篇博文可能引用了不再可用和/或不再支持的产品。 有关 F5 NGINX 产品和解决方案的最新信息,请探索我们的NGINX 产品系列。 NGINX 现在是 F5 的一部分。 所有之前的 NGINX.com 链接都将重定向至 F5.com 上的类似 NGINX 内容。”