Nginx服务器性能优化的三大方面

原创
2020/08/20 11:14
阅读数 113

Nginx服务器非常快,但是Nginx的默认设置并没有针对具体的硬件进行调优。在这篇文章中,我们要把Nginx的性能发挥到极限。Nginx的配置分为三大部分:worker进程配置、I/O配置、TCP配置。我们将分别对这三大配置展开讨论,并在最后给出综合性的配置。

1.Nginx的worker进程配置

worker_processes

worker_processes directive指定nginx worker进程的数量。它是一个全局性配置,不属于events模块,也不属于http或location模块。

worker_processes 1;

默认的值是1,意味着nignx只打开一个worker进程。最优的设置是worker进程数量要与CPU的核数相等。我们可以用lscpu命令来找出CPU的核数。

lscpu

也可以用

cat /proc/cpuinfo | grep 'processor' | wc -l

另外,我们也可以将worker_processes的值设为auto,这样nginx会自动检测CPU核数并打开相同数量的worker进程。

当nginx添加了SSL证书时,最好要打开多个worker进程。SSL握手会进行硬盘I/O操作。所以打开多个worker进程有利于性能的提升。

accept_mutex

当我们为nginx打开了多个worker进程后,我们需要配置如何选择worker进程来完成相应的请求处理。在events模块中,我们可以设置

events {
accept_mutex on;
}

accept_mutex会轮流来选择worker进程。Nginx默认开启了accept_mutex。

如果accept_mutex的值被设为off,那么当有请求需要处理时,所有的worker进程都会从waiting状态中唤醒,但是只有一个worker进程能处理请求,这造成了thundering herd现象,这个现象每一秒钟会发生多次。它使服务器的性能下降,因为所有被唤醒的worker进程在重新进入waiting状态前会占用一段CPU时间。

accept_mutex_delay

当accept_mutex功能启用后,只有一个持有mutex锁的worker进程会接受并处理请求,其他worker进程等待。accept_mutex_delay指定的时间就是这些worker进程的等待时间,过了等待时间下一个worker进程便取得mutex锁,处理请求。accept_mutex_delay在events模块中指定,默认的值为500ms。

events {
accept_mutex_delay 500ms;
}

worker_connections

worker_connections的默认值是512,它在events模块中。它指定了一个worker进程在同一时间可以处理的最大请求数。

events {
worker_connections 512;
}

将它的值增加到1024左右。

web服务器同时处理的请求数并不等于它同时服务的客户端数量。一个浏览器会打开多个并发连接来下载网页的各个部分,如图片、脚本等等。而且不同的浏览器对同一个网页打开的并发连接数量也会有所不同。

worker_rlimit_nofile

由于每一个socket都会打开一个文件描述符,所以服务器可以同时处理连接数量受到系统文件描述符数量的限制。如果nginx打开的socket数量超过了文件描述符的数量,那么在error.log文件中会出现too many opened files错误。我们可以用下面的命令来查看文件描述符的数量:

$ ulimit -n

Nginx worker进程默认的用户名是www-data,用户www-data所拥有的文件描述符的数量要大于worker进程数量与worker_connections之乘积。nginx有一个worker_rlimit_nofile directive,可以用来设置系统可用的文件描述符。这与ulimit设置可用文件描述符的作用是一样的。如果它们都设置了可用文件描述符,那么worker_rlimit_nofile会覆盖ulimit的设置。

worker_rlimit_nofile 20960;

查看操作系统对一个进程施加的限制,我们可以用命令读取/etc/$pid/limits文件,$pid是进程的pid。

multi_accept

multi_accept可以让nginx worker进程尽可能多地接受请求。它的作用是让worker进程一次性地接受监听队列里的所有请求,然后处理。如果multi_accept的值设为off,那么worker进程必须一个一个地接受监听队列里的请求。

events {
multi_accept on;
}

默认Nginx没有开启multi_accept。

如果web服务器面对的是一个持续的请求流,那么启用multi_accept可能会造成worker进程一次接受的请求大于worker_connections指定可以接受的请求数。这就是overflow,这个overflow会造成性能损失,overflow这部分的请求不会受到处理。

use

Nginx处理请求的方法有很多种,每一个方法都允许Nginx Worker进程监测多个socket文件描述符。这些方法都分别依赖于特定的平台,用于生成Nginx二进制文件的configure命令会选择适合当前平台的最有效的方法。如果要使用另外的方法,那么我们必须先启用这些方法。

我们可以用use这个directive来选择另外的处理请求的方法。use directive属于events模块。

events {
use select;
}

Nginx支持以下请求处理方法:

  • select: 这是一种标准的请求处理方法。如果一个平台上缺少相应的更加有效的方法,那么Nginx会自动使用select方法。

  • poll: 这是一种标准的请求处理方法。如果一个平台上缺少相应的更加有效的方法,那么Nginx会自动使用poll方法。

  • kqueue: 这是BSD家族操作系统上可用的一种高效的请求处理方法。可用于FreeBSD, OpenBSD, NetBSD和OS X。kqueue方法会忽略multi_accept。

  • epoll: 这是Linux系统上可用的一种高效的请求处理方法,类似于kqueue。它有一个额外的directive,那就是epoll_events。epoll_events指定了Nginx可以向内核传递的事件数量。默认的值是512。

2.Nginx的I/O配置

sendfile

本文分享自微信公众号 - 竹清助手(zhuqing_help)。
如有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。

展开阅读全文
打赏
0
0 收藏
分享
加载中
更多评论
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部