nginx 配置优化指令

共计 3224 个字符，预计需要花费 9 分钟才能阅读完成。

worker_processes

      worker_processes 指令是用来设计 Nginx 进程数，官方默认设为 1，赋值太多了，将会对系统 IO 影响效率，降低 Nginx 服务器性能。但是为了让多核 CPU 能够更好的处理并行任务，我们可以讲该值设置大一些，最好这个值是机器 CPU 的倍数，并不是越大越好。
  worker_cpu_affinity

worker_cpu_affinity 指令用来分配每个进程的 CPU 的工作内核 

  worker_processes 4 ; 四核开启了四个进程 worker_cpu_affinity 0001 0010 0100 1000; // 我们 CPU 就是四核 就是四组值，0 是不使用，1 是使用。这样每一个进程都有一个 cpu 内核了。{解析 四组二进制值分别对应着四个进程，第一个进程对应的是 0001 第二个进程对应的是 0010，表示第二个进程计算器内核，第三个进程对应的是 0100，表示第三个计算机内核，第四个进程对应 1000}

send_timeout

send_timeout  120s;

用于设置 nginx 服务器响应客户端的超时时间，这个超时时间仅针对两个客户端和服务器之间建立连接后，某次活动之间的时间。如果这个时间后客户端没有任何活动，nginx 服务器将会关闭连接

  keepalive_timeout

keepalive_timeout  160s

指定客户端连接保持的超时时间，该设置表示 nginx 服务器与客户端保持活动时间是 60s，60s 后服务器与客户端断开连接

client_header_buffer_size

client_header_buffer_size  4k;

设置 nginx 服务器允许的客户端请求头部的缓冲区大小，默认为 1KB。此指令的赋值可以根据系统分页大小来设置。分页大小也可以用 “# getconf PAGESIZE” 命令取得

有过 nginx 服务器工作经验的朋友可能会遇到 nginx 服务器返回 400 错误的情况，查找 nginx 服务器的 400 错误原因比较困难，因为此错误并不是每次都会出现，出现错误的时候，通常在浏览器和日志里也看不到任何有关提示信息。

根据实际经验来看，有很大一部分情况是客户端的请求头部过大造成的。请求头部过大，通常是客户端 cookie 中写入了较大的值引起的。于是适当增大此指令的赋值，允许 nginx 服务器接收较大的请求头部，可以改善服务器对客户端

的支持能力。一般将此指令设置为 4KB.

client_header_timeout

client_header_timeout  20s;

设置读取客户端请求头数据的超时时间。此处值是 15s, 为经验参考值，默认是 60s。

如果超过这个时间，客户端还没有发送完整的 header 数据，服务端将返回 ”Request timeout(408)” 错误，

multi_accept

配置 nginx 服务器时候经可能多的接受客户端的网络连接请求, 默认 off

驱动相关指定

use

参数详解：use 指令用于指定 Nginx 服务器使用的事件驱动模型

worker_connections

该指令用于设置 Nginx 服务器的每个工作进程允许同时连接客户端的最大数量，语法为

worker_connections number;

结合 worker_processes 指令，我们可以计算出 Nginx 服务器允许同时练级的客户端最大数量 Client=worker_processes * worker_connections / 2。

在看一本书的过程中看到作者 在使用 Nginx 服务器的过程中遇到无法访问 Nginx 服务器的情况。查看日志信息发现一直报如下错误

他是怎么分析解决的呢：

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

worker_connections 65535;

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

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

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

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

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

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

worker_rlimit_sigpending 

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

worker_rlimit_sigpending  limit;

注：limit 为 linux 平台事件信号队列的长度上限值。

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

worker_rlimit_sifpending 1024;

devpoll_changes 和 devpoll_events 

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

devpoll_changes number;

devpoll_events number;

注：number 为要设置的数量，默认值为 32.

kqueue_changes 和 kqueue_events 

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

kqueue_changes number;

kqueue_events number;

注：number 为要设置的数量，默认值均为 512。

epoll_events 

参数详解：该指令用于设置在 epoll 事件驱动模式下 Nginx 服务器可以与内核之间传递事件的数量，与其他事件驱动模型不同，在 epoll 事件驱动模式下 Nginx 服务器向内核传递事件的数量和从内核传递事件数量是相等得。因此没有类似 epoll_changes 这样的指令, 默认值为 512.

 epoll_events 512;

  rtsig_signo

该指令用于设置 rtsig 模式使用两个信号中的第一个,

rtsig_signo signo

rtsig_overfloe_* number

用于代表三个具体的指令 分别是:rtsig_overflow_events  rtsig_overflow_test

rtsig_over_thresold

rtsig_overflow_events: 指定对垒米处时使用 poll 库处理的事件数

rtsig_overflow_test: 指定 poll 库处理地几件事见后将清空 rtsig 模型使用的信号队列, 默认 32

rtsig_over_thresold: 指定 rtsig 模式使用的信号队列中的时间超过多少时就清空队列

：