Nginx高性能Web服务器详解
上QQ阅读APP看本书，新人免费读10天
设备和账号都新为新人
上一章目录下一章

第4章 Nginx服务器的高级配置

Nginx服务器的配置远不仅是我们在之前提到的那些内容。Nginx服务器运行的实际环境和提供的功能千差万别，如何根据自己的工作经验和具体的使用环境为Nginx服务器配置恰当的指令，才是Nginx配置的核心内容。本章根据Nginx的官方文档和笔者的实际工作经验，为大家展示了一些与实际运行环境相关联的Nginx服务器高级配置，希望大家能够熟练掌握。这些配置和服务器运行的操作系统及硬件环境有关，大家在实际操作过程中请自行做出调整。

我们将在本章学习到以下知识：

■ 针对IPv4的内核参数优化

■ 针对处理器的指令配置

■ 针对网络连接的指令配置

■ 与事件驱动相关的指令配置

4.1 针对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参数

该参数用于记录尚未收到客户端确认信息的连接请求的最大值。对于拥有128 MB内存的系统而言，此参数的默认值是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

4.2 针对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的工作内核。这个指令的设置方法有些麻烦。我们先来看一张笔者根据官方文档画的示意图。如图4.1所示，worker_cpu_affinity指令的值是由几组二进制值表示的。其中，每一组代表一个进程，每组中的每一位表示该进程使用CPU的情况，1代表使用，0代表不使用。注意，二进制位排列顺序和CPU的顺序是相反的。建议将不同的进程平均分配到不同的CPU运行内核上。

图4.1 worker_cpu_affinity指令示意图

笔者设置Nginx服务的进程数为4，CPU是四核，因此会有四组值，并且每组有四位，所以，此指令的设置为：

    worker_cpu_affinity 0001 0100 1000 0010;

四组二进制数值分别对应4个进程，第一个进程对应0001，表示使用第一个CPU内核；第二个进程对应0010，表示使用第二个CPU内核，以此类推。

如果笔者将worker_processes指令的值赋值为8，即赋值为CPU内核个数的两倍，则worker_cpu_affinity指令的设置可以是：

    worker_cpu_affinity 0001 0010 0100 1000 0001 0010 0100 1000;

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

    worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000 01000000 10000000;

以上两例的具体含义不再赘述，相信大家通过前面的介绍能够明白。

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

1. keepalive_timeout指令

该指令用于设置Nginx服务器与客户端保持连接的超时时间。

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

    keepalive_timeout 60 50;

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

2.send_timeout指令

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

    send_timeout 10s;

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

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。

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

本节涉及的指令与第3章介绍的Nginx服务器的事件驱动模型密切相关，建议大家在充分学习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.0:81

根据报错信息，推测可能是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就没问题了。

3. worker_rlimit_sigpending指令

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

    worker_rlimit_sigpending limit

其中，limit为Linux平台事件信号队列的长度上限值。

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

    worker_rlimit_sigpending 1024;

4. devpoll_changes和devpoll_events指令

这两个指令用于设置在/dev/poll事件驱动模式下Nginx服务器可以与内核之间传递事件的数量，前者设置传递给内核的事件数量，后者设置从内核获取的事件数量，语法结构为：

    devpoll_changes number
    devpoll_events number

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

5. kqueue_changes和kqueue_events指令

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

    kqueue_changes number
    kqueue_events number

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

使用kequeue_changes方式，可以设置与内核之间传递事件的数量。

6. 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
    29) SIGIO       30) SIGPWR      31) SIGSYS      34) SIGRTMIN
    35) SIGRTMIN+1  36) SIGRTMIN+2  37) SIGRTMIN+3  38) SIGRTMIN+4
    39) SIGRTMIN+5  40) SIGRTMIN+6  41) SIGRTMIN+7  42) SIGRTMIN+8
    43) SIGRTMIN+9  44) SIGRTMIN+10 45) SIGRTMIN+11 46) SIGRTMIN+12
    47) SIGRTMIN+13 48) SIGRTMIN+14 49) SIGRTMIN+15 50) SIGRTMAX-14

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模式使用的信号队列中的事件超过多少时就需要清空队列了。该指令只对Linux 2.4.x及以下版本有效。在这些版本中包含两个参数：分别是proc/sys/kernel/ rtsig-nr和/proc/sys/kernel/rtsig-max/rtsig_overflow_threshold，后者就是该指令设定的值。当Nginx服务器检测到前者大于后者时，将清空队列。该指令默认值为10，代表rtsig-max的1/10。

4.5 本章小结

本章内容不多，主要是对第2章的补充和延伸。我们在第3章中学习了Nginx服务器架构相关的基础知识，尤其对Nginx服务器在处理Web请求、事件驱动方面的内容有了了解。本章基于这些知识，为大家展示了Nginx服务器与运行软硬件环境相关的高级配置。这些配置对于Nginx服务器高效和充分利用系统资源是非常有帮助的，当然也需要用户能够充分掌握服务器的运行环境。

同时，我们也体会到Nginx服务器为用户提供的配置接口是相当丰富和全面的，这增强了自身系统的灵活性和可定制能力，以及对实际生产环境的适应能力。这也是Nginx服务器能够受到广大用户喜欢的另一个重要原因。

上一章目录下一章