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

时间:2024-01-14 08:41:20

随着访问量的不断增加,需要对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连接在传送完最后一个响应后,还需要等待多少秒后,才关闭这个连接。