从零开始的Linux运维屌丝之路,资源免费分享平台   运维人员首选:简单、易用、高效、安全、稳定、社区活跃的开源软件

Nginx配置文件优化详细说明

发布:蔺要红04-01分类: Nginx


主要是Nginx.conf配置的优化:其中配置文件分为main、http、server

官方链接:     nginx官方链接配置文件使用说明

一:main全局优化和规范:


优化work进程-运行用户-进程最大打开文件数-定义pid-定义日志路径
user www www;     #运行用户,默认即是nginx,可不设置
worker_processes auto;   #nginx进程,一般设置为和cpu核数一样
error_log /data/logs/error/error_nginx.log crit;  #定义错误日志文件位置和错误级别
pid /var/run/nginx.pid;  #定义pid文件存放位置
worker_rlimit_nofile 65535;   #最大文件打开数(连接),可设置为系统优化后的ulimit -n的结果

查看cpu总核数

[[email protected] ~]#  grep processor /proc/cpuinfo |wc -l
4

查看cpu总个数

[[email protected] ~]# grep 'physical id' /proc/cpuinfo|sort|uniq|wc -l
2
或使用lscpu命令
[[email protected] ~]# lscpu 
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                4
On-line CPU(s) list:   0-3
Thread(s) per core:    1
Core(s) per socket:    2
Socket(s):             2
 
worker_processes 了解一下,免得以后看到不知道什么鬼,
测压结果:直接写4和把进程分别绑定到不同的CPU  CPU的使用率区别不大
也可以将进程绑定到不同的CPU,
worker_processes 4;
cpu亲和力配置,让不同的进程使用不同的cpu
worker_cpu_affinity  0001 0010 0100 1000;

八个线程CPU的配置:
worker_processes  8; 
worker_cpu_affinity  00000001 00000010 00000100 00001000 00010000 00100000 01000000 10000000;
worker_cpu_affinity  0001 0010 0100 1000 0001 0010 0100 1000;

二:events优化
events {
    use epoll;  #用来指定nginx的工作模式
    worker_connections 51200;  #单个后台worker process进程的最大并发链接数
    multi_accept on;   #打开同时接受多个新网络连接请求的功能
    #accept_mutex on;  #该指令1.113版本之前默认为on状态,表示会对多个Nginx进程接收连接进行序列化,防止多个进程对连接的争抢
}
events详细说明
use epoll用来指定nginx的工作模式,
nginx工作模式有select epoll poll kqueue rtsig和/dev/null
select和poll都是标准的工作模式
kqueue和epoll是高效的工作模式 epoll用在Linux平台 kqueue用在BSD系统 ,异步网络I/O模型
对于Linux系统2.6+内核推荐epoll,高性能高并发的设置
官方文档:也可以不指定事件处理模型,nginx会自动选择最佳的事件处理模型服务
 

worker_connections 51200;
单个后台worker process进程的最大并发链接数
说明:
设置单个工作进程最大连接数51200、 Nginx的总并发连接=worker数量* worker_connections

[[email protected] nginx]# netstat -antp | grep nginx | wc -l
554
 
multi_accept on;  #打开同时接受多个新网络连接请求的功能
只能在events模块设置,
Nginx服务器的每个工作进程可以同时接受多个新的网络连接,
但是需要在配置文件中配置,此指令默认为关闭,
即默认为一个工作进程只能一次接受一个新的网络连接,
打开后几个同时接受多个,配置语法如下:
 

指令格式:accept_mutex on | off;
官方说明:If accept_mutex is enabled, worker processes will accept new connections by turn. Otherwise, all worker processes will be notified about new connections, and if volume of new connections is low, some of the worker processes may just waste system resources
如果accept_mutex启用,则工作进程将依次接受新连接。否则,将通知所有工作进程有关新连接的信息,如果新连接的数量很少,则某些工作进程可能只会浪费系统资源

该指令1.113版本之前默认为on、之后的版本默认为off状态,表示会对多个Nginx进程接收连接进行序列化,防止多个进程对连接的争抢。
用于防止在同一一个时刻只有一个请求的情况下,出现多个睡眠进程会被唤醒但只能有一个进程可获得请求的尴尬,如果不优化,在多进程的nginx会影响以部分性能

惊群问题
就Nginx的场景来解释的话大致的意思就是:当一个新网络连接来到时,多个worker进程会被同时唤醒,但仅仅只有一个进程可以真正获得连接并处理之。如果每次唤醒的进程数目过多的话,其实是会影响一部分性能的。
所以在这里,如果accept_mutex on,那么多个worker将是以串行方式来处理,其中有一个worker会被唤醒;
反之若accept_mutex off,那么所有的worker都会被唤醒,不过只有一个worker能获取新连接,其它的worker会重新进入休眠状态
这个值的开关与否其实是要和具体场景挂钩的。

举例说明:假如有100只小鸡
accept_mutex off;
你把这粒粮食直接扔到小鸡中间,一百只小鸡一起上来抢,最终只有一只小鸡能得手,其它九十九只小鸡只能铩羽而归。
accept_mutex on ;
你主动抓一只小鸡过来,把这粒粮食塞到它嘴里,其它九十九只小鸡对此浑然不知,该睡觉睡觉。
同开启 accept_mutex 相比,关闭 accept_mutex 的时候,请求在多个 worker 间的分配更均衡了,和我们意淫的结论基本一致


三:events优化

http {
    include mime.types;
    default_type application/octet-stream;

    server_names_hash_bucket_size 128;
    client_header_buffer_size 32k;
    large_client_header_buffers 4 32k;

    server_tokens off;         #隐藏版本号nginx
    sendfile on;               #开启文件的高效传输模式,同时将  tcp_nopush on; tcp_nodelay on; 可以防止网络及磁盘I/O阻塞,
    tcp_nopush on;             #准许把 http  response header 和文件的开始部分放在一个文件里发布,其积极的作用是减少网络报文的数量
    tcp_nodelay on;            #提高I/O性能

    keepalive_timeout 60 ;     #客户端 与服务端(nginx)服务端     建立连接超时时间
    client_header_timeout 15;  #服务端(nginx) 读取 客户端请求头数据 的超时时间
    client_body_timeout 15;    #服务端(nginx)读取 客户端请求主体数据 的超时时间
    send_timeout 25;           #服务端(nginx) 传送 http响应信息 到 客户端 的超时时间


    client_max_body_size 16m;  #上传文件大小限制!!!设置最大准许 客户端请求主体大小,一般情况下http的post方法在提交数据时才会携带请求主体
}
   
官方链接说明: server_names_hash_bucket_size     分别搜 三个指令即可搜到详细作用
Syntax : server_names_hash_bucket_size size;
Default: server_names_hash_bucket_size 32|64|128;
Context: http

Syntax : client_header_buffer_size size;
Default: client_header_buffer_size 1k;
Context: http, server
设置读取客户端请求标头的缓冲区大小。对于大多数请求,1K字节的缓冲区就足够了。但是,如果请求包含长cookie或来自WAP客户端,则可能不适合1K。如果请求行或请求头字段不适合此缓冲区,则会分配由large_client_header_buffers指令配置的较大缓冲区

Syntax : large_client_header_buffers number size;
Default: large_client_header_buffers 4 8k;
Context: http, server
设置用于读取大客户机请求标头的最大值number和size缓冲区。请求行不能超过一个缓冲区的大小,否则会将414(Request-URITooLarge)错误返回给客户端。请求头字段也不能超过一个缓冲区的大小,或者400(错误请求)错误返回给客户端。缓冲区仅按需分配。默认情况下,缓冲区大小等于8K字节。如果在请求处理结束后连接转换为保持活动状态,则释放这些缓冲区。
 

超时设置说明:
把无用的连接尽快超时,可以保护服务器的资源(cpu 内存 磁盘)

恶意用户攻击网站,会不断与服务器建立连接,消耗连接数等,应该及时断掉恶意连接
当Nginx与Fastcgi服务建立请求php时,如果因一些原因(负载高,停止响应),fastcgi无法给Nginx返回数据,nginx会死等,设置nginx设置超时时间,如果在规定时间内不返回数据,那么nginx中断本次请求,向前面的用户汇报获取不到数据
及时断掉那些已经建立连接,又不做事情的连接,减少服务器资源使用,服务器维护连接也消耗资源
简单的说:连接超时是服务的一种自我管理,自我保护的重要机制
其他说明:
1、php站点会希望设置成短连接,php程序在建立连接时消耗的资源和时间相对少一些
2、java一般建议设置长连接,java程序在建立连接的时候,消耗的资源和时间更多,这是由语言机制决定的

 
Syntax : client_body_buffer_size size;
Default: client_body_buffer_size 8k|16k;
Context: http, server, location
设置读取客户端请求主体的缓冲区大小。如果请求主体大于缓冲区,则整个主体或仅其部分被写入 临时文件。默认情况下,缓冲区大小等于两个内存页。这在x86,其他32位平台和x86-64上是8K。在其他64位平台上通常为16K。

官方说明  client_body_temp_path  本文中没有设置

Syntax : client_max_body_size size;
Default: client_max_body_size 1m;
Context: http, server, location
设置客户端请求正文的最大允许大小,在“Content-Length”请求标头字段中指定。如果请求中的大小超过配置的值,则会将413(请求实体太大)错误返回给客户端。请注意,浏览器无法正确显示此错误。设置size为0将禁用检查客户端请求正文大小。
温馨提示如有转载或引用以上内容之必要,敬请将本文链接作为出处标注,如有侵权我会在24小时之内删除!

欢迎使用手机扫描访问本站