Nginx配置优化及深入讲解,大家可以听一下

随着访问量的不断增加，需要对Nginx和内核做相应的优化来满足高并发用户的访问，那下面在单台Nginx服务器来优化相关参数。

1)       Nginx.conf配置优化：

worker_processes 8;

nginx进程数，建议按照cpu数目来指定，一般为它的倍数。

worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000

00100000 01000000 10000000;

为每个进程分配cpu，上例中将8个进程分配到8个cpu，当然可以写多个，或者将一

个进程分配到多个cpu。

worker_rlimit_nofile 102400;

这个指令是指当一个nginx进程打开的最多文件描述符数目，理论值应该是最多打

开文件数（ulimit -n）与nginx进程数相除，但是nginx分配请求并不是那么均匀

，所以最好与ulimit -n的值保持一致。

use epoll;

使用epoll的I/O模型。epoll是Linux内核为处理大批量文件描述符而作了改进的

poll，它能显著提高程序在大量并发连接中只有少量活跃的情况下的系统CPU利用

率。

worker_connections 102400;

每个进程允许的最多连接数，理论上每台nginx服务器的最大连接数为

worker_processes*worker_connections。

keepalive_timeout 60;

keepalive超时时间，客户端到服务器端的连接持续有效时间,当出现对服务器的后

继请求时,keepalive-timeout功能可避免建立或重新建立连接。

client_header_buffer_size 4k;

客户端请求头部的缓冲区大小，这个可以根据你的系统分页大小来设置，一般一个

请求的头部大小不会超过1k，不过由于一般系统分页都要大于1k，所以这里设置为

分页大小。分页大小可以用命令getconf PAGESIZE取得。

open_file_cache max=102400 inactive=20s;

这个将为打开文件指定缓存，默认是没有启用的，max指定缓存数量，建议和打开

文件数一致，inactive是指经过多长时间文件没被请求后删除缓存。

open_file_cache_valid 30s;

这个是指多长时间检查一次缓存的有效信息。

open_file_cache_min_uses 1;

open_file_cache指令中的inactive参数时间内文件的最少使用次数，如果超过这

个数字，文件描述符一直是在缓存中打开的，如上例，如果有一个文件在inactive

时间内一次没被使用，它将被移除。

2)       Linux内核参数优化：

net.ipv4.tcp_max_tw_buckets = 10000

timewait的数量，默认是180000。

net.ipv4.ip_local_port_range = 1024 65000

允许系统打开的端口范围。

net.ipv4.tcp_tw_recycle = 1

启用timewait快速回收。

net.ipv4.tcp_tw_reuse = 1

开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接。

net.ipv4.tcp_syncookies = 1

开启SYN Cookies，当出现SYN等待队列溢出时，启用cookies来处理。

Nginx常用配置参数有upstream，主要用于均衡后端多个实例：

Nginx 的upstream目前支持5种算法分配方式：

1)       轮询（默认rr）

每个请求按时间顺序逐一分配到后端不同的服务器，如果后端某台服务器down掉，自动剔除，待恢复自动添加上。

2)       Weight权重

指定轮询权重，权重越高，处理的请求就越多，weight和访问比率成正比，用于后端服务器性能不均的情况。

3)       ip_hash

每个请求根据访问的IP的hash结果分配，这样每个访客固定访问一个后端服务器，可以解决session的问题，一般用于登录会话。

4)       fair（第三方）

按后端服务器的响应时间来分配请求，响应时间短的优先分配。

5)       url_hash（第三方）

upstream的 fail_timeout和max_fails参数是用来判断负载均衡upstream中的某个server是否失效。

在fail_timeout的时间内，nignx与upstream中某个server的连接尝试失败了max_fails次，则nginx会认为该server已经失效。在接下来的 fail_timeout时间内，nginx不再将请求分发给失效的server。

例如在nginx.conf里面配置如下的tdt_app均衡：

upstream tdt_app {

server   10.10.1.11:8080 weight=1 max_fails=2 fail_timeout=30s;

server   10.10.1.12:8080 weight=1 max_fails=2 fail_timeout=30s;

}

Tdt_app均衡两台后端JAVA服务，在30秒内nginx会与后端的某个server通信检测，如果检测连接失败2次，则Nginx会认为该server已经失效，然后踢出转发列表，然后在接下来的30s内，nginx不再讲请求转发给失效的server。

另外，fail_timeout设置的时间对响应时间没影响，这个响应时间是用proxy_connect_timeout和proxy_read_timeout来控制的。

proxy_connect_timeout : Nginx与后端服务器连接的超时时间，发起握手等候响应超时时间。

proxy_read_timeout：连接成功后_等候后端服务器响应时间，其实已经进入后端的排队之中等候处理（也可以说是后端服务器处理请求的时间）。

proxy_send_timeout :后端服务器数据回传时间，在规定时间之内后端服务器必须传完所有的数据。

keepalive_timout：一个http产生的tcp连接在传送完最后一个响应后，还需要等待多少秒后，才关闭这个连接。