浅谈Nginx性能调优

系统 Linux
Nginx能够优化的地方非常多,本文只涉及到了其中很小的一些方面,但也足够满足我们的使用场景了。

[[354733]]

 Linux系统参数优化

下文中提到的一些配置,需要较新的Linux(2.6以上)内核才能够支持,笔者使用的CentOS 7.4,内核版本3.10,如果不满足需要的话,最好进行相应的升级,毕竟打补丁是件费力不讨好的事情。对于系统层面的调优,通常我们修改文件描述符限制、缓冲区队列长度以及临时端口数量就可以了。

文件描述符限制

由于每个TCP连接都要占用一个文件描述符,一旦文件描述符耗尽,新的连接到来就会返回“Too many open files”这样的错误,为了提高性能,我们需要对其进行修改:1.系统层级的限制 编辑文件 /etc/sysctl.conf,添加如下内容: 

  1. 1.  `fs.file-max =10000000 
  2. 2.  `fs.nr_open =10000000

2.用户层级的限制 编辑文件 /etc/security/limits.conf,添加以下内容: 

  1. 1.  `*      hard   nofile      1000000`  
  2. 2.  `*      soft   nofile      1000000` 

这里我们只要保证用户层级限制不大于系统层级限制就可以了,否则可能会出现无法通过SSH登录系统的问题。修改完毕执行如下命令: 

  1. 1.  `$ sysctl -p` 

可以通过执行命令 ulimit -a查看是否修改成功。

TCP连接队列长度

编辑文件 /etc/sysctl.conf,添加如下内容: 

  1. 1.  `# The length of the syn quene`  
  2. 2.  `net.ipv4.tcp_max_syn_backlog =65535 
  3. 3.  `# The length of the tcp accept queue`  
  4. 4.  `net.core.somaxconn =65535

其中 tcp_max_syn_backlog用于指定半连接SYN队列长度,当新连接到来时,系统会检测半连接SYN队列,如果队列已满,则无法处理该SYN请求,并在 /proc/net/netstat中的 ListenOverflows和 ListenDrops中增加统计计数somaxconn用于指定全连接ACCEPT队列长度,当该队列满了以后,客户端发送的ACK包将无法被正确处理,并返回错误"connection reset by peer"Nginx则会记录一条error日志"no live upstreams while connecting to upstreams"如果出现以上错误,我们需要考虑增大这两项的配置。

临时端口

由于Nginx用作代理,每个到上游Web服务的TCP连接都要占用一个临时端口,因此我们需要修改 ip_local_port_range参数 修改 /etc/sysctl.conf文件,添加如下内容: 

  1. 1.  `net.ipv4.ip_local_port_range =102465535 
  2. 2.  `net.ipv4.ip_local_reserved_ports =8080,8081,9000-9010`

其中,参数 ip_local_reserved_ports用于指定保留端口,这是为了防止服务端口被占用而无法启动。

Nginx参数优化

Nginx参数优化主要围绕 nginx.conf这个配置文件展开,下文不再赘述。

工作进程

Nginx性能强大的一个重要原因在于它采用多进程非阻塞I/O模型,因此我们要妥善利用这一点:

  •  worker_processes  默认的Nginx只有一个master进程一个worker进程,我们需要对其进行修改,可以设置为指定的个数,也可以设置为 auto,即系统的CPU核数。更多的worker数量将导致进程间竞争cpu资源,从而带来不必要的上下文切换。因此这里我们将它设置为cpu的核数即可:    worker_processes   auto
  •  worker_connections 每个worker可以处理的并发连接数,默认值512不是很够用,我们适当将它增大:    worker_connections 4096
  •  Nginx支持以下I/O复用方法处理连接:select、 poll、 kqueue、 epoll、 rtsig、 /dev/poll、 eventport。它们分别适用于不同的操作系统,其中 epoll是Linux系统上面效率最高的:    use epoll

KeepAlive

为了避免从Nginx到Web服务频繁的建立、断开连接,我们可以启用从HTTP 1.1开始支持的KeepAlive长连接特性,它可以大幅减少CPU和网络开销,在我们的实战中也是对性能提高最大的一环。keepalive必须和 proxy_http_version与 proxy_set_header结合使用, 参考配置如下: 

  1. 1.  `upstream BACKEND {`  
  2. 2.  `    keepalive 300;`  
  3. 3.  `    server 127.0.0.1:8081;`  
  4. 4.  `}`  
  5. 5.  `server {`  
  6. 6.  `    listen 8080;`  
  7. 7.  `    location /{`  
  8. 8.  `        proxy_pass http://BACKEND;`  
  9. 9.  `        proxy_http_version 1.1;`  
  10. 10.  `        proxy_set_header Connection"";`  
  11. 11.  `}`  
  12. 12.  `}` 

其中 keepalive既非timeout,也不是连接池数量,官方解释如下:

The connections parameter sets the maximum number of idle keepalive connections to upstream servers that are preserved in the cache of each worker process. When this number is exceeded, the least recently used connections are closed.

可以看出它的意思是“最大空闲长连接数量”,超出这个数量的空闲长连接将被回收,当请求数量稳定而平滑时,空闲长连接数量将会非常小(接近于0),而现实中请求数量是不可能一直平滑而稳定的,当请求数量有波动时,空闲长连接数量也随之波动:

  •  当空闲长连接数量大于配置值时,将会导致大于配置值的那部分长连接被回收;
  •  当长连接不够用时,将会重新建立新的长连接。

因此,如果这个值过小的话,就会导致连接池频繁的回收、分配、再回收。为了避免这种情况出现,可以根据实际情况适当调整这个值,在我们实际情况中,目标QPS为6000,Web服务响应时间约为200ms,因此需要约1200个长连接,而 keepalive值取长连接数量的10%~30%就可以了,这里我们取300,如果不想计算,直接设为1000也是可行的。

Access-Log缓存

记录日志的I/O开销比较高,好在Nginx支持日志缓存,我们可以利用这个功能,降低写日志文件的频率,从而提高性能。可以将 buffer和 flush两个参数结合使用来控制缓存行为: 

  1. 1.  `access_log /var/logs/nginx-access.log buffer=64k gzip flush=1m

其中 buffer制定了缓存大小,当缓冲区达到 buffer所指定的大小时,Nginx就会将缓存起来的日志写到文件中;flush指定了缓存超时时间,当 flush指定的时间到达时,也会触发缓存日志写入文件操作。

文件描述符限制

上一节中已经对Linux系统的文件描述符限制进行了修改,Nginx配置中同样有相应的配置项:worker_rlimit_nofile, 理论上这个值应该设置为 /etc/security/limits.conf 中的值除以 worker_processes, 但实际中不可能每个进程均匀分配,所以这里只要设置成和 /etc/security/limits.conf 一样就可以了 

  1. 1.  `worker_rlimit_nofile 1000000;` 

总结

以上就是笔者进行Nginx调优的一些经验,可以看出基本是围绕Nginx的Error日志展开的,之后又对一些比较大的性能瓶颈进行了一些改进。Nginx能够优化的地方非常多,本文只涉及到了其中很小的一些方面,但也足够满足我们的使用场景了。 

 

责任编辑:庞桂玉 来源: 运维派
相关推荐

2023-11-11 19:07:23

JVMJava

2017-07-21 08:55:13

TomcatJVM容器

2012-06-20 11:05:47

性能调优攻略

2021-03-04 08:39:21

SparkRDD调优

2021-01-27 12:40:09

NginHTTPS前端

2011-03-10 14:40:54

LAMPMysql

2011-11-14 10:28:23

2011-05-20 15:02:01

Oracle性能调优

2019-05-20 15:28:27

流量 NginxLinux

2011-03-18 11:21:48

2021-11-07 23:49:19

SQL数据库工具

2012-06-21 09:43:45

2013-02-28 10:15:14

Ubuntu性能调优故障排查

2024-12-04 15:49:29

2019-07-08 14:05:53

数据库JVMSQL

2020-11-09 07:34:49

JVM性能监控

2011-03-21 09:35:38

LAMP调优网络文件

2016-03-25 09:59:38

性能调优LinuxMySQL

2011-03-18 11:13:07

LAMP度量性能

2013-03-20 17:18:07

Linux系统性能调优
点赞
收藏

51CTO技术栈公众号