[code.nginx] Nginx服务器高级配置

针对IPv4的内核7个参数的配置优化

这里提及的参数是和IPv4网络有关的Linux内核参数。我们可以将这些内核参数的值追加到Linux系统的/etc/sysctl.conf文件中,然后使用如下命令使修改生效:

#/sbin/sysctl -p

这些常用的参数包括以下这些。
** 1. net.core.netdev_max_backlog参数 **
net.core.netdev_max_backlog,表示当每个网络接口接收数据包的速率比内核处理这些包的速率快时,允许发送到队列的数据包的最大数目。一般默认值为128(可能不同的Linux系统该数值也不同)。Nginx服务器中定义的NGX_LISTEN_BACKLOG默认为511.我们可以将它调整一下:

net.core.netdev_max_backlog = 262144

** 2.net.core.somaxconn参数 **
该参数用于调节系统同时发起的TCP连接数,一般默认值为128。在客户端存在高并发请求的情况下,在默认值较小,可能导致链接超时或者重传问题,我们可以根据实际需要结合并发请求数来调节此值。

net.core.somaxconn = 262144

** 3.net.ipv4.tcp_max_orphans参数 **
该参数用于设定系统中最多允许存在多少TCP套接字不被关联到任何一个用户文件句柄上。如果超过这个数字,没有与用户文件句柄关联的TCP套接字将立即被复位,同时给出警告信息。这个限制只是为了防止简单的DoS(Denial of Service,拒绝服务)攻击。一般在系统内存比较充足的情况下,可以增大这个参数的赋值:

net.ipv4.tcp_max_orphans = 262144

** 4.net.ipv4.tcp_max_syn_backlog参数 **
该参数用于记录尚未收到客户端确认信息的连接请求的最大值。对于拥有128MB内存的系统而言,此参数的默认值是1024,对小内存的系统则是128。一般在系统内存比较充足的情况下,可以增加这个参数的赋值:

net.ipv4.tcp_max_syn_backlog = 262144

** 5.net.ipv4.tcp_timestamps参数 **
该参数用于设置时间戳,这可以避免序列号的卷绕。在一个1Gb/s的链路上,遇到以前用过的序列号的概率很大。当此值赋值为0时,禁用对于TCP时间戳的支持。在默认情况下,TCP协议会让内核接受这种“异常”的数据包。针对Nginx服务器来说,建议将其关闭:

net.ipv4.tcp_timestamps = 0

** 6.net.ipv4.tcp_synack_retries参数 **
该参数用于设置内核放弃TCP连接之前向客户端发送SYN+ACK包的数量。为了建立对端的连接服务,服务器和客户端需要进行三次握手,第二次握手期间,内核需要发送SYN并附带一个回应前一个SYN的ACK,这个参数主要影响这个进程,一般赋值为1,即内核放弃连接之前发送一次SYN+ACK包,可以设置其为:

net.ipv4.tcp_synack_retries = 1

** 7.net.ipv4.tcp_syn_retries参数 **
该参数的作用和上一个参数类似,设置内核放弃建立连接之前发送SYN包的数量,它的赋值和上个参数一样即可:

net.ipv4.tcp_syn_retries = 1

针对CPU的Nginx配置优化的2个指令

在Nginx配置文件中,有这样两个指令:worker_processes和worker_cpu_affinity,它们可以针对多核CPU进行配置优化。
** 1.worker_processes指令 **
worker_processes指令用来设置Nginx服务的进程数。官方文档建议此指令一般设置为1即可,赋值太多会影响系统的IO效率,降低Nginx服务器的性能。为了让多核CPU能够很好的并行处理任务,我们可以将worker_processes指令的赋值适当的增大一些,最好是赋值为机器CPU的倍数。当然,这个值并不是越大越好,Nginx进程太多可能增加主进程调度负担,也可能影响系统的IO效率。针对双核CPU,建议设置为2或
4。如果是四核CPU,设置为:

worker_processes 4;

设置好worker_processes指令之后,就很有必要设置worker_cpu_affinity指令。

** 2. worker_cpu_affinity指令 **
worker_cpu_affinity指令用来为每个进程分配CPU的工作内核。这个指令用来为每个进程分配CPU的工作内核。这个指令的设置方法有些麻烦。
如下图所示:


worker_cpu_affinity指令

worker_cpu_affinity指令的值是由几组二进制值表示的。其中,每一组代表一个进程,每组中的每一位表示该进程使用CPU的情况,1表示使用,0表示不使用。注意,二进制位排列顺序和CPU的顺序是相反的。建议将不同的进程平均分配到不同的CPU运行内核上。
如果设置的Nginx服务的进程数为4,CPU为4核,因此会有四组值,并且每组有四位,所以,此指令的设置为:

worker_cpu_affinity 0001 0100 1000 0010;

四组二进制数值分别对应4个进程,第一个进程对应0001,表示使用第一个CPU内核。第二个进程对应0010,表示使用第二个CPU内核,以此类推。
如果将worker_processes指令的值赋值为8,即赋值为CPU内核个数的两倍,则worker_cpu_affinity指令的设置可以是:

worker_cup_affinity 001 0010 0100 1000 0001 0010 0100 1000;

如果一台机器的CPU是八核CPU,并且worker_processes指令的值赋值为8,那么worker_cpu_affinity指令的设置可以是:

worker_cpu_affinity 0000001 00000010 00000100 00001000 00010000 00100000 01000000 10000000;

与网络连接相关的配置的4个指令

** 1.keepalive_timeout指令 **
该指令用于设置Nginx服务器与客户端保持连接的超时时间。
这个指令支持两个选项,中间用空格隔开。第一个选项指定客户端连接保持活动的超时时间,在这个时间之后,服务器会关闭此连接。第二个选项可选,其指定了使用Keep-Alive消息头保持活动的有效时间,如果不设置它,Nginx服务器不会向客户端发送Keep-Alive消息头以保持与客户端某些浏览器(如Mozilla、Konqueror等)的连接,超过设置的时间后,客户端就可以关闭连接,而不需要服务器关闭了。你可以根据自己的实际情况设置此值,建议从服务器的访问数量、处理速度以及网络状态方面考虑。下面是此指令的设置示例:

keepalive_timeout 60 50;

该设置表示Nginx服务器与客户端连接保持活动的时间是60s,60s后服务器与客户端断开连接。使用Keep-Alive消息头保持与客户端某些浏览器(如Mozilla、Konqueror等)的连接时间为50s,50s后浏览器主动与服务器断开连接。

** 2.send_timeout指令 **
该指令用于设置Nginx服务器响应客户端的超时时间,这个超时时间仅针对两个客户端和服务器之间建立连接后,某次活动之间的时间。如果这个时间后客户端没有任何活动,Nginx服务器将会关闭连接。此指令的设置需要考虑服务器访问数量和网络状况等方面。下面是此指令的设置示例:

send_timeout 10s;

该设置表示Nginx服务器与客户端建立连接后,某次会话中服务器等待客户端响应超时10s,就会自动关闭连接。

** 3.client_header_buffer_size指令 **
该指令用于设置Nginx服务器允许的客户端请求头部的缓冲区大小,默认为1KB。此指令的赋值可以根据系统分页大小来设置。分页大小可以用以下命令取得:

#getconf PAGESIZE

有过Nginx服务器工作经验的可能遇到Nginx服务器返回400错误的情况。查找Nginx服务器的400错误原因比较困难,因为此错误并不是每次都会出现,出现错误的时候,通常在浏览器和日志里也看不到任何有关提示信息。根据实际的经验来看,有很大一部分情况是客户端的请求头部过大造成的。请求头部过大,通常是客户单cookie中写入了较大的值引起的。于是适当增大此指令的赋值,允许Nginx服务器接收较大的请求头部,可以改善服务器对客户端的支持能力。一般将此指令赋值为4KB大小,即:

client_header_buffer_size 4k;

** 4.multi_accept指令 **
该指令用于配置Nginx服务器是否尽可能多的接收客户端的网络连接请求,默认值为off。

与事件驱动模型相关的配置的8个指令

本节涉及的指令与Nginx服务器的事件驱动模型密切相关。

  1. use指令
    use指令用于指定Nginx服务器使用的事件驱动模型。
  2. worker_connections指令
    该指令用于设置Nginx服务器的每个工作进程允许同时连接客户端的最大数量,语法为:
worker_connections number

其中,number为设置的最大数量。结合worker_processes指令,我们可以计算出Nginx服务器允许同时连接的客户端最大数量Client = worker_processes * worker_connections / 2;
在使用Nginx服务器的过程中,笔者曾经遇到过无法访问Nginx服务器的情况,查看日志发现一直在报如下错误:

[alert] 24082#0: 1024 worker_connections is not enough while accepting new connection on 0.0.0.:01

根据报错信息,推测可能是Nginx服务器的最大访问连接数设置小了。此指令设置的就是Nginx服务器能接受的最大访问量,其中包括前端用户连接也包括其他连接,这个值在理论上等于此指令的值与它允许开启的工作进程最大数的乘积。此指令一般设置为65535:

worker_connections 65535;

此指令的赋值与linux操作系统中进程可以打开的文件句柄数量有关系。按照以上设置修改此项赋值以后,Nginx服务器报以下错误:

[warn]: 8192 worker_connections are more than open file resource limit:1024

究其原因,Linux系统中有一个系统指令open file resource limit,它设置了进程可以打开的文件句柄数量。worker_connections指令的赋值当然不能超过open file resource limit的赋值。可以使用以下命令查看在你的Linux系统中open file resource limit的赋值。

# cat /proc/sys/fs/file-max

可以通过一下命令将open file resource limit指令的值设为2390251:

#echo "2390251" > /proc/sys/fs/file-max;sysctl -p

这样,Nginx的worker_connections指令赋值为65535就没问题了。

  1. worker_rlimit_sigpending指令
    该指令用于设置Linux 2.6.6-mm2版本之后Linux平台的事件信号队列长度上线。其语法结构为:
worker_rlimit_sigpending limit

其中,limit为Linux平台事件信号队列的长度上限值。
该指令主要影响事件驱动模型中rfsig模型可以保存的最大信号数。Nginx服务器的每一个工作进程有自己的事件信号队列用于暂存客户端请求发生信号,如果超过长度上线,Nginx服务器自动转用poll模型处理未处理器的客户端请求。为了保证Nginx服务器对客户端请求的高效处理,请大家根据实际的客户端并发请求数量和服务器运行环境的处理能力设定该值。设置示例为:

worker_rlimit_sigpending 1024;
  1. devpoll_changes和devpoll_events指令
    这两个指令用于设置在/dev/poll事件驱动模式下Nginx服务器可以与内核之间传递事件的数量,前者设置传递给内核的事件数量,后者设置从内核获取的事件数量,语法结构为:
devpoll_changes number
devpoll_events number

其中,number为要设置的数量,默认值均为32。

  1. kqueue_changes和kqueue_events指令
    这两个指令用于设置在kqueue事件驱动模式下Nginx服务器可以与内核之间传递事件的数量,前者设置传递给内核的事件数量,后者设置从内核获取的事件数量,其语法结构为:
kqueue_changes number
kqueue_events number

其中,number为要设置的数量,默认值均为512.
使用kequeue_changes方式,可以设置与内核之间传递事件的数量。

  1. epoll_events指令
    该指令用于设置在epoll事件驱动模式下Nginx服务器可以与内核之间传递事件的数量,其语法结构为:
epoll_changes number

其中,number为要设置的数量,默认值均为512。

注意
与其他事件驱动模型不同,在epoll事件驱动模式下Nginx服务器向内核传递事件的数量和从内核传递的事件数量是相等的,因此没有类似epoll_changes这样的指令。

7.rtsig_signo指令
该指令用于设置rtsig模式使用的两个信号中的第一个,第二个信号是在第一个信号的编号上加1,语法为:

rtsig_signo signo

默认的第一个信号设置为SIGRTMIN+10。

提示
在Linux中可以使用一下命令查看系统支持的SIGRTMIN有哪些。

kill -l | grep SIGRTMIN

8.rtsig_overflow_* 指令
该指令代表三个具体的指令,分别为rtsig_overflow_events指令、rtsig_overflow_test指令和rtsig_overflow_threshold指令。这些指令用来控制当rtsig模式中信号队列溢出时Nginx服务器的处理方式,语法结构为:

rtsig_overflow_* number

其中,number是要设定的值。
rtsig_overflow_events指令指定队列溢出时使用poll库处理的事件数,默认值为16。
rtsig_overflow_test指令设定poll库处理完第几件事件后将清空rtsig模型使用的信号队列,默认值为32。

rtsig_overflow_threshold指令指定rtsig模式使用的信号队列中的事件超过多少时就需要清空队列了。

推荐阅读更多精彩内容

  • 配置运行Nginx服务器用户(组) 用于配置运行Nginx服务器用户(组)的指令是user,其语法格式为: use...
    吃瓜的东阅读 3,783评论 0 40
  • 1. Nginx的模块与工作原理 Nginx由内核和模块组成,其中,内核的设计非常微小和简洁,完成的工作也非常简单...
    rosekissyou阅读 9,002评论 5 125
  • 夫学须志也,才须学也,非学无以广才,非志无以成学。——诸葛亮 这句话是我舅公送我的,当时只是崇拜诸葛亮七情孟获足智...
    钱程浩瀚阅读 116评论 2 2
  • 以前的我是一个脑袋空空,很容易相信别人,也没什么想法的人。朋友经常说我连话都说不清,跟别人争辩,经常词穷...
    小筱茶籽阅读 136评论 4 5
  • 2010年三月中旬的时候,和学校的同学一同坐上了火车,前往深圳开始我的实习生活。在老东家的实习生活是快乐,不仅学习...
    残剑阅读 142评论 0 1