内容简介:Nginx以高性能负载均衡、缓存和web服务器出名,支撑着世界上繁忙网站中的40%。大多数使用场景下,Nginx和Linux系统的默认配置表现较好,但是仍有必要做一些调优以期达到最佳性能。这篇文章讨论当调优系统时需要考虑的一些Nginx和Linux配置。这些配置有很多,但是在本文里我们只涉及适合大多数用户的配置。那些没有涉及到的配置,只有那些对Nginx和Linux有深入理解的人,或者Nginx专家服务团队推荐,才会考虑到。Nginx专家服务,已经和世界上一些繁忙网站合作来调优Nginx以达到最大限度的性能
Nginx以高性能负载均衡、缓存和web服务器出名,支撑着世界上繁忙网站中的40%。大多数使用场景下,Nginx和 Linux 系统的默认配置表现较好,但是仍有必要做一些调优以期达到最佳性能。
这篇文章讨论当调优系统时需要考虑的一些Nginx和Linux配置。这些配置有很多,但是在本文里我们只涉及适合大多数用户的配置。那些没有涉及到的配置,只有那些对Nginx和Linux有深入理解的人,或者Nginx专家服务团队推荐,才会考虑到。
Nginx专家服务,已经和世界上一些繁忙网站合作来调优Nginx以达到最大限度的性能,并且可以对任何需要充分发挥系统能力的客户提供支持。
简介
这里假定读者对Nginx架构和配置概念有个基本了解。本文不会重复Nginx文档的内容,而是概述各种配置选项并提供相关文档链接。
调优时,有一条较好的准则是,一次只改一个配置项,如果改后没有性能上的提升,就退回为原先的值。
我们先讨论Linux调优,因为有些值会影响在Nginx配置中可以用的值。
Linux配置
现代Linux内核(2.6+)能够很好的调节各种配置,有些配置您可能想更改。如果操作系统配置太低,那么会在内核日志中看到错误信息,因此需要调节这些配置。Linux配置项很多,本文只提及那些在普通工作负载下最可能需要调优的配置项。如果需要这些配置的详细信息,请参考Linux文档。
Backlog队列
以下设置与连接及其如何排队直接相关。如果传入的连接率很高而性能水平参差不齐,比如一些连接似乎被暂停了,那么更改这些配置可能会有用。
- net.core.somaxconn 该项设置等待被Nginx接受的连接的排队大小。由于Nginx接受连接速度非常快,这个值通常不需要非常大,但是默认值是非常低的,所以如果你有一个高流量网站,增加这个值是个好主意。如果设置过低,那么你能在内核日志中看到错误信息,这时你应该增加这个值直到没有错误信息。注意:如果你将其设置为大于512的值,你应该同时用listen指令的backlog参数匹配这个值来更改Nginx的配置。
- net.core.netdev_max_backlog 该项设置在交由CPU处理之前网卡缓冲数据包的速率。对于拥有高带宽的机器,这个值可能需要增加。查看网卡文档寻求相关建议,或者检查内核日志相关错误信息。
文件描述符
文件描述符是一种操作系统资源,用来处理诸如连接和打开文件的事情。对每一个连接,Nginx可以用上多达两个文件描述符。例如,如果Nginx用作代理,则其中一个用于客户端连接,另一个用于连接到被代理的服务器。如果使用了HTTP keepalive,则连接描述符的使用会少得多。对于有大量连接的系统,如下设置可能需要进行调整:
- sys.fs.file_max 这是系统范围内的文件描述符限制。
- nofile 这是用户级别的文件描述符限制,在/etc/security/limits.conf文件中配置
临时端口
当Nginx被当作代理使用时,每一个到upstream服务器的连接都使用一个临时端口。
- net.ipv4.ip_local_port_range 这个用来指定可以使用的起止端口号。如果你看到端口耗尽,你可以增加这个范围。常见的设置为1024到65000。
- net.ipv4.tcp_fin_timeout 这个用于指定一个不再被使用的端口多久之后可以被另一连接再次使用。通常,这个值默认为60秒,但是可以安全地减少到30甚至15秒。
Nginx配置
下面是一些可能影响性能的Nginx指令。如前所述,我们仅讨论那些推荐大多数用户调整的指令。这里未提及到的任何指令,如果没有Nginx团队的指导,不推荐更改。
工作进程
Nginx可以运行多个工作进程,每个都能处理大量连接。你可以用如下指令控制工作进程个数以及连接如何被处理:
- worker_processes 这个控制Nginx运行的工作进程个数。大多数情况下,一个CPU核心跑一个工作进程能够工作得很好。可以将该指令设为auto来达到与CPU核心数匹配的工作进程数。有时候,可以增加这个值,比如工作进程需要处理大量磁盘IO操作的时候。这个值默认为1。
- worker_connections 这个表示每个工作进程同时能够处理的最大连接数。默认值是512,但是大多数系统能处理更大的值。这个值该设为多少取决于服务器硬件配置以及流量的特性,可以通过测试来发现。
Keepalives
持久连接可以减少打开和关闭连接所需要的CPU和网络开销,因而对性能有重大影响。Nginx终止所有客户端连接,并具有到upstream服务器的单独连接。Nginx支持客户端和upstream服务器的持久连接。如下指令涉及客户端持久连接:
- keepalive_requests 这表示客户端能在单个持久连接上发送多少请求。默认值是100,可以设置成更高的值,这在负载生成器从单个客户端发送大量请求的测试场景中非常有用。
- keepalive_timeout 表示一个空闲持久连接保持打开状态多长时间。
如下指令涉及upstream持久连接:
- keepalive 这个指定每个工作进程连接到upstream服务器的空闲持久连接数量。这个指令没有默认值。
为了启用到upstream的持久连接,需要增加如下指令:
proxy_http_version 1.1; proxy_set_header Connection "";
Access日志
记录每个请求需要花费CPU和IO周期,减少这种影响的一种方法是启用access日志缓冲。这将导致Nginx缓冲一系列日志条目,然后一次性写入文件而不是单个单个写入。
通过指定access_log指令的"buffer=size"选项可以打开access日志缓冲,该设置指定要使用的缓冲区的大小。你还可以使用"flush=time"选项告诉Nginx多长时间后把缓冲区中的条目写入文件。
定义了这两个选项后,当缓冲区放不下下一条日志,或者缓冲区中的条目超过了flush参数指定的时间,Nginx会将缓冲区中的条目写入日志文件。当工作进程重新打开日志文件或者关闭时,缓冲区中的条目也会被写入文件。也可以完全禁用access日志记录。
Sendfile
Sendfile是一个操作系统特性,可以在Nginx上启用。它通过在内核中从一个文件描述符向另一个文件描述符复制数据,往往能达到零拷贝,因而可以提供更快的TCP数据传输。Nginx可以使用该机制将缓存或者磁盘上的内容写到socket,无需从内核空间到用户空间的上下文切换,因而非常快并且使用较少的CPU开销。由于数据永远不会触及用户空间,所以不可能把需要访问数据的过滤器插入到处理链中,不能使用任何需要改变内容的Nginx过滤器,比如gzip过滤器。Nginx默认没有启用该机制。
限制
Nginx和Nginx Plus允许设置各种限制,用来控制客户端资源消耗,以防影响系统性能以及用户体验和安全。以下是一些相关指令:
- limit_conn / limit_conn_zone 这些指令可以用来限制Nginx允许的连接数,比如来自单个客户端IP地址的连接数。这可以防止单个客户端打开太多连接而消耗太多资源。
- limit_rate 这个用来限制客户端在单个连接上允许使用的带宽。这可以防止某些客户端导致系统超载,因而有利于为所有客户端提供QoS保证。
- limit_req / limit_req_zone 这些指令可以用来限制Nginx的请求处理速率。与limit_rate一起,可以防止某些客户端导致系统超载,因而有利于为所有客户端提供QoS保证。这些指令也可以用来增强安全性,尤其是对登录页面,通过限制请求速率,使得其对人类用户是合适的,而会减慢试图访问你的应用的程序。
- max_conns 这个用来限制同时连接到upstream组中单个服务器的最大连接数。这可以防止upstream服务器超载。默认值是0,表示没有限制。
- queue 如果设置了max_conns,那么queue指令用来决定当一个请求由于upstream组中没有可用服务器或者这些服务器达到max_conns限制而不能得到处理时会发生什么。这个指令用来设定有多少请求将会排队以及排多久。如果没有设置这个指令,就不会有排队行为。
其它考虑
Nginx还有一些特性可以用来提高web应用的性能。这些特性不常出现在调优讨论中,但是有必要一提,因为它们的影响也可能比较可观。我们将讨论这些特性中的两个。
缓存
对于一个为一组web服务器或者应用服务器作负载均衡的Nginx实例来说,启用缓存可以显著地降低响应时间,同时能显著减轻后端服务器的负载。缓存本身就是一个主题,这里不会讨论。
压缩
压缩响应可以大大减小响应的大小,减少带宽占用。不过,这需要CPU资源来处理压缩,所以最好在值得减少带宽占用的情况下使用。需要注意的是,不能对已经压缩的东西(比如jpeg图片)再次启用压缩。Nginx压缩配置的更多信息请参考:Nginx管理指南 - 压缩和解压缩
以上所述就是小编给大家介绍的《大流量、高负载场景 Nginx+Linux 性能调优》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!
猜你喜欢:- 流量引导:网络世界的负载均衡解密
- 阿里七层流量入口负载均衡算法演变之路
- 如何搭建应对亿级流量的高可用负载均衡?
- Algolia 借助 NGINX 和 OpenResty 实现搜索流量负载均衡
- 谷歌云网络深度解析:流量指挥官如何为服务网格提供全局负载均衡
- Proxy-Go v9.0 来袭,新增流量上报/统计/限制,内网穿透真实 IP,TCP 负载均衡!
本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。