nginx 安装优化指令

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;
 
ASP站长网用于设置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模式使用的信号队列中的时间超过多少时就清空队列