详解nginx的基本配置及nginx.conf文件配置示例

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/lijinqi1987/article/details/53189258

Nginx在运行时,至少必须加载几个核心模块和一个事件类模块。这些模块运行时所支持的配置项称为基本配置—所有其他模块执行时都依赖的配置项。

下面详述基本配置项的用法。由于配置项较多,所以把它们按照用户使用时的预期功能分成了以下4类:

1、用于调试进程和定位问题的配置项

(1)是否以守护进程方式运行Nginx

语法:daemon on | off;

默认:daemon on;


守护进程(daemon)是脱离终端并且在后台运行的进程。它脱离终端是为了避免进程执行过程中的信息在任何终端上显示,这样一来,进程也不会被任何终端所产生的信息所打断。Nginx毫无疑问是一个需要以守护进程方式运行的服务,因此,默认都是以这种方式运行的。

 

不过Nginx还是提供了关闭守护进程的模式,之所以提供这种模式,是为了方便跟踪调试Nginx,毕竟用gdb调试进程时最烦琐的就是如何继续跟进fork出的子进程了。

 

(2)是否以master/worker方式工作

语法:master_process on | off;

默认:master_process on;

 

几乎所有的产品环境下,Nginx都以“一个master进程管理多个worker进程的方式运行的”这种方式工作。

与daemon配置相同,提供master_process配置也是为了方便跟踪调试Nginx。如果用off关闭了master_process方式,就不会fork出worker子进程来处理请求,而是用master进程自身来处理请求。

 

(3)error日志的设置

语法:error_log  /path/file level;

默认:error_log logs/error.log error;

 

error日志是定位Nginx问题的最佳工具,我们可以根据自己的需求妥善设置error日志的路径和级别。

/path/file参数可以是一个具体的文件,例如,默认情况下是logs/error.log文件,最好将它放到一个磁盘空间足够大的位置;/path/file也可以是/dev/null,这样就不会输出任何日志了,这也是关闭error日志的唯一手段;/path/file也可以是stderr,这样日志会输出到标准错误文件中。

 

level是日志的输出级别,取值范围是debug、info、notice、warn、error、crit、alert、emerg,从左至右级别依次增大。当设定为一个级别时,大于或等于该级别的日志都会被输出到/path/file文件中,小于该级别的日志则不会输出。例如,当设定为error级别时,error、crit、alert、emerg级别的日志都会输出。

 

如果设定的日志级别是debug,则会输出所有的日志,这样数据量会很大,需要预先确保/path/file所在磁盘有足够的磁盘空间。

注意 如果日志级别设定到debug,必须在configure时加入--with-debug配置项。

 

(4)仅对指定的客户端输出debug级别的日志

语法:debug_connection [IP | CIDR]

 

这个配置项实际上属于事件类配置,因此,它必须放在events {...}中才有效。它的值可以是IP地址或CIDR地址,例如:

events{ 

    debug_connection 10.224.66.14;  

    debug_connection 10.224.57.0/24; 

}

这样,仅仅来自以上IP地址的请求才会输出debug级别的日志,其他请求仍然沿用error_log中配置的日志级别。

 

上面这个配置对修复Bug很有用,特别是定位高并发请求下才会发生的问题。

 

注意 使用debug_connection前,需确保在执行configure时已经加入了--with-debug参数,否则不会生效。

 

(5)限制coredump核心转储文件的大小

语法:worker_rlimit_core size;

 

在Linux系统中,当进程发生错误或收到信号而终止时,系统会将进程执行时的内存内容(核心映像)写入一个文件(core文件),以作为调试之用,这就是所谓的核心转储(core dumps)。当Nginx进程出现一些非法操作(如内存越界)导致进程直接被操作系统强制结束时,会生成核心转储core文件,可以从core文件获取当时的堆栈、寄存器等信息,从而帮助我们定位问题。但这种core文件中的许多信息不一定是用户需要的,如果不加以限制,那么可能一个core文件会达到几GB,这样随便coredumps几次就会把磁盘占满,引发严重问题。通过worker_rlimit_core配置可以限制core文件的大小,从而有效帮助用户定位问题。

 

(6)指定coredump文件生成目录

语法:working_directory path;

 

worker进程的工作目录。这个配置项的唯一用途就是设置coredump文件所放置的目录,协助定位问题。因此,需确保worker进程有权限向working_directory指定的目录中写入文件。


2.3.2 正常运行的配置项

下面是正常运行的配置项的相关介绍。

(1)定义环境变量

语法:env VAR|VAR=VALUE

这个配置项可以让用户直接设置操作系统上的环境变量。例如:

1.     env TESTPATH=/tmp/;

(2)嵌入其他配置文件

语法:include /path/file;

include配置项可以将其他配置文件嵌入到当前的nginx.conf文件中,它的参数既可以是绝对路径,也可以是相对路径(相对于Nginx的配置目录,即nginx.conf所在的目录),例如:

 

1.     include mime.types; 

2.     include vhost/*.conf;

可以看到,参数的值可以是一个明确的文件名,也可以是含有通配符*的文件名,同时可以一次嵌入多个配置文件。

(3)pid文件的路径

语法:pid path/file;

默认:pid logs/nginx.pid;

保存master进程ID的pid文件存放路径。默认与configure执行时的参数“--pid-path”所指定的路径是相同的,也可以随时修改,但应确保Nginx有权在相应的目标中创建pid文件,该文件直接影响Nginx是否可以运行。

(4)Nginx worker进程运行的用户及用户组

语法:user username [groupname];

默认:user nobody nobody;

user用于设置master进程启动后,fork出的worker进程运行在哪个用户和用户组下。当按照“user username;”设置时,用户组名与用户名相同。

若用户在configure命令执行时使用了参数--user=username和--group=groupname,此时nginx.conf将使用参数中指定的用户和用户组。

(5)指定Nginx worker进程可以打开的最大句柄描述符个数

语法:worker_rlimit_nofile limit;

设置一个worker进程可以打开的最大文件句柄数。

(6)限制信号队列

语法:worker_rlimit_sigpending limit;

设置每个用户发往Nginx的信号队列的大小。也就是说,当某个用户的信号队列满了,这个用户再发送的信号量会被丢掉。


2.3.3 优化性能的配置项

下面是优化性能的配置项的相关介绍。

(1)Nginx worker进程个数

语法:worker_processes number;

默认:worker_processes 1;

在master/worker运行方式下,定义worker进程的个数。

worker进程的数量会直接影响性能。那么,用户配置多少个worker进程才好呢?这实际上与业务需求有关。

每个worker进程都是单线程的进程,它们会调用各个模块以实现多种多样的功能。如果这些模块确认不会出现阻塞式的调用,那么,有多少CPU内核就应该配置多少个进程;反之,如果有可能出现阻塞式调用,那么需要配置稍多一些的worker进程。

例如,如果业务方面会致使用户请求大量读取本地磁盘上的静态资源文件,而且服务器上的内存较小,以至于大部分的请求访问静态资源文件时都必须读取磁盘(磁头的寻址是缓慢的),而不是内存中的磁盘缓存,那么磁盘I/O调用可能会阻塞住worker进程少量时间,进而导致服务整体性能下降。

多worker进程可以充分利用多核系统架构,但若worker进程的数量多于CPU内核数,那么会增大进程间切换带来的消耗(Linux是抢占式内核)。一般情况下,用户要配置与CPU内核数相等的worker进程,并且使用下面的worker_cpu_affinity配置来绑定CPU内核。

(2)绑定Nginx worker进程到指定的CPU内核

语法:worker_cpu_affinity cpumask [cpumask...]

为什么要绑定worker进程到指定的CPU内核呢?假定每一个worker进程都是非常繁忙的,如果多个worker进程都在抢同一个CPU,那么这就会出现同步问题。反之,如果每一个worker进程都独享一个CPU,就在内核的调度策略上实现了完全的并发。

例如,如果有4颗CPU内核,就可以进行如下配置:

1.     worker_processes 4; 

2.     worker_cpu_affinity 1000 0100 0010 0001;

注意 worker_cpu_affinity配置仅对Linux操作系统有效。Linux操作系统使用sched_setaffinity()系统调用实现这个功能。

(3)Nginx worker进程优先级设置

语法:worker_priority nice;

默认:worker_priority 0;

该配置项用于设置Nginx worker进程的nice优先级。

在Linux或其他类UNIX操作系统中,当许多进程都处于可执行状态时,将按照所有进程的优先级来决定本次内核选择哪一个进程执行。进程所分配的CPU时间片大小也与进程优先级相关,优先级越高,进程分配到的时间片也就越大(例如,在默认配置下,最小的时间片只有5ms,最大的时间片则有800ms)。这样,优先级高的进程会占有更多的系统资源。

优先级由静态优先级和内核根据进程执行情况所做的动态调整(目前只有±5的调整)共同决定。nice值是进程的静态优先级,它的取值范围是–20~+19,–20是最高优先级,+19是最低优先级。因此,如果用户希望Nginx占有更多的系统资源,那么可以把nice值配置得更小一些,但不建议比内核进程的nice值(通常为–5)还要小。

 

2.3.4 事件类配置项

下面是事件类配置项的相关介绍。

(1)是否打开accept锁

语法:accept_mutex [on | off]

默认:accept_mutext on;

accept_mutex是Nginx的负载均衡锁,accept_mutex这把锁可以让多个worker进程轮流地、序列化地与新的客户端建立TCP连接。当某一个worker进程建立的连接数量达到worker_connections配置的最大连接数的7/8时,会大大地减小该worker进程试图建立新TCP连接的机会,以此实现所有worker进程之上处理的客户端请求数尽量接近。

accept锁默认是打开的,如果关闭它,那么建立TCP连接的耗时会更短,但worker进程之间的负载会非常不均衡,因此不建议关闭它。

(2)lock文件的路径

语法:lock_file path/file;

默认:lock_file logs/nginx.lock;

accept锁可能需要这个lock文件,如果accept锁关闭,lock_file配置完全不生效。如果打开了accept锁,并且由于编译程序、操作系统架构等因素导致Nginx不支持原子锁,这时才会用文件锁实现accept锁,这样lock_file指定的lock文件才会生效。

注意 在基于i386、AMD64、Sparc64、PPC64体系架构的操作系统上,若使用GCC、Intel C++ 、SunPro C++编译器来编译Nginx,则可以肯定这时的Nginx是支持原子锁的,因为Nginx会利用CPU的特性并用汇编语言来实现它。这时的lock_file配置是没有意义的。

(3)使用accept锁后到真正建立连接之间的延迟时间

语法:accept_mutex_delay Nms;

默认:accept_mutex_delay 500ms;

在使用accept锁后,同一时间只有一个worker进程能够取到accept锁。这个accept锁不是阻塞锁,如果取不到会立刻返回。如果有一个worker进程试图取accept锁而没有取到,它至少要等accept_mutex_delay定义的时间间隔后才能再次试图取锁。

(4)批量建立新连接

语法:multi_accept [ on | off ];

默认:multi_accept off;

当事件模型通知有新连接时,尽可能地对本次调度中客户端发起的所有TCP请求都建立连接。

(5)选择事件模型

语法:use [ kqueue | rtsig | epoll | /dev/poll | select | poll | eventport];

默认:Nginx会自动使用最适合的事件模型。

对于Linux操作系统来说,可供选择的事件驱动模型有poll、select、epoll三种。epoll当然是性能最高的一种。

(6)每个worker的最大连接数

语法:worker_connections number;

定义每个worker进程可以同时处理的最大连接数。

 

附上cnblog上一份nginx.conf文件的配置项注释:

#$开头是变量
#定义Nginx运行的用户和用户组
user work work;
#nginx进程数,建议设置为等于CPU总核心数
worker_processes  auto;
#指当一个nginx进程打开的最多文件描述符数目
worker_rlimit_nofile 204800;
#全局错误日志定义类型,[ debug | info | notice | warn | error | crit ]
error_log  /opt/log/nginx/error.log error;
#工作模式及连接数上限
events {
        #参考事件模型,use [ kqueue | rtsig | epoll | /dev/poll | select | poll ]; 
        #epoll模型是Linux 2.6以上版本内核中的高性能网络I/O模型,如果跑在FreeBSD上面,就用kqueue模型
        use epoll;
        #单个后台worker process进程的最大并发链接数
        worker_connections  102400;
}
#设定http服务器,利用它的反向代理功能提供负载均衡支持
http {
        #文件扩展名与文件类型映射表
        include       mime.types;
        #默认文件类型
        default_type  application/octet-stream;
        #默认编码
        charset utf-8;
        #设定日志格式
        #log_format  main  '$idXXXX\t$remote_addr\t$remote_user\t$time_local\t$http_host\t$request\t'
        #             '$status\t$body_bytes_sent\t$http_referer\t'
        #             '$http_user_agent\t$http_x_forwarded_for\t$request_time\t$upstream_response_time\t$userid';
        log_format main "$cookie_idXXXX\t$remote_addr\t$remote_user\t[$time_local]\t$request_method\t$host\t$request_uri\t"
                        "$request_time\t$status\t$body_bytes_sent\t'$http_referer'\t"
                        "'$http_user_agent'\t'$http_x_forwarded_for'\t$upstream_addr\t$upstream_response_time\t$upstream_status\t";
                 
    #不可见字符分隔日志格式
    #include other_log_format.conf;
    #实时日志收集json格式日志
    #include json_log_format.conf;

        #日志流格式
        log_format stream_log "$cookie_idXXXX\t$remote_addr\t$remote_user\t[$time_local]\t$request_method\t$host\t$request_uri\t"
                      "$request_time\t$status\t$body_bytes_sent\t'$http_referer'\t"
                      "'$http_user_agent'\t'$http_x_forwarded_for'\t$upstream_addr\t$upstream_response_time\t3";
        
        #成功日志
        access_log  /opt/log/nginx/access.log main;
        #access_log syslog:local6:notice:log1.op.XXXXdns.org:514:nginx-main-log main;
        
        #指定 nginx 是否调用 sendfile 函数(zero copy 方式)来输出文件,对于普通应用,
        #必须设为 on,如果用来进行下载等应用磁盘IO重负载应用,可设置为 off,以平衡磁盘与网络I/O处理速度,降低系统的uptime.
        sendfile        on;
        #长连接超时时间,单位是秒
        keepalive_timeout  60;
        #服务器名称哈希表的最大值(默认512)[hash%size]
        server_names_hash_max_size 1024;
        #服务器名字的hash表大小
        server_names_hash_bucket_size 256;
        #客户请求头缓冲大小 
        client_header_buffer_size 4k;
        #如果header过大,它会使用large_client_header_buffers来读取
        large_client_header_buffers 4 256k;
        client_header_timeout  1m;
        client_body_timeout    1m;
        send_timeout           1m;
        #防止网络阻塞
        tcp_nopush     on;
        tcp_nodelay    on;
        #允许客户端请求的最大单文件字节数
        client_max_body_size 50m;
        
        #缓冲区代理缓冲用户端请求的最大字节数
        client_body_buffer_size 50m;
        
        #nginx跟后端服务器连接超时时间(代理连接超时)
        proxy_connect_timeout 5;
        
        #后端服务器数据回传时间(代理发送超时)
        proxy_send_timeout 15;
        
        #连接成功后,后端服务器响应时间(代理接收超时)
        proxy_read_timeout 15;
        
        #设置代理服务器(nginx)保存用户头信息的缓冲区大小
        proxy_buffer_size 4k;
        
        #proxy_buffers缓冲区,网页平均在32k以下的话,这样设置
        proxy_buffers 8 32k;
        
        #高负荷下缓冲大小(proxy_buffers*2)
        proxy_busy_buffers_size 64k;
        
        #设定缓存文件夹大小,大于这个值,将从upstream服务器传
        proxy_temp_file_write_size 64k;
        proxy_intercept_errors  on;
        #客户端放弃请求,nginx也放弃对后端的请求
        #proxy_ignore_client_abort on;

    #代理缓存头信息最大长度[设置头部哈希表的最大值,不能小于你后端服务器设置的头部总数]
    proxy_headers_hash_max_size 512;
    #设置头部哈希表大小(默认64)[这将限制头部字段名称的长度大小,如果你使用超过64个字符的头部名可以加大这个值。]
    proxy_headers_hash_bucket_size 256;

    #变量哈希表的最大值(默认值)
    variables_hash_max_size 512;
    #为变量哈希表制定关键字栏的大小(默认64)
    variables_hash_bucket_size 128;
        
        #开启gzip压缩输出
        gzip on;
        #最小压缩文件大小
        gzip_min_length 1k;
        #压缩缓冲区
        gzip_buffers     4 16k;
        #压缩等级
        gzip_comp_level 9;
        #压缩版本(默认1.1,前端如果是squid2.5请使用1.0)
        gzip_http_version 1.0;
        #压缩类型,默认就已经包含textml
        gzip_types text/plain application/x-javascript application/json application/javascript text/css application/xml text/javascript image/gif image/png;
        gzip_vary on;

        #map模块使用
        map_hash_max_size 102400;
        map_hash_bucket_size  256;

        #Tengine Config
        #concat on;
        #trim on;
        #trim_css off;
        #trim_js off;
        server_tokens off;
        #footer "<!-- $remote_addr $server_addr $upstream_addr -->";

        #rewrite_log on;
        fastcgi_intercept_errors on;
    #include other config file
        include ../conf.d/*.conf;
    #包含一些特殊站点的配置文件,此目录下文件暂时不包含在git自动管理过程中
    include ../special/*.conf;

    #屏蔽不加主机域名的默认请求
    #server {
        #   listen *:80 default;
        #   server_name _ "";
        #   return 444;
    #}
    
    #ceshi by dongange 2016-01-07

    #Nginx状态监测模块配置
    req_status_zone server "$server_name,$server_addr:$server_port" 10M;
    req_status server;
    server {
        listen 127.0.0.1:80;
        server_name 127.0.0.1;
        access_log /opt/log/nginx/nginx_status/status_access.log main;
            location /status {
                req_status_show;
                access_log /opt/log/nginx/nginx_status/status_access.log main;
                allow 127.0.0.1;
                deny all;
                }
            location /stub_status {
                stub_status on;
                access_log /opt/log/nginx/nginx_status_stub/status_stub_access.log main;
                allow 127.0.0.1;
                deny all;
            }
            location /check_status {
                check_status;
                access_log /opt/log/nginx/nginx_status_check/status_access_check.log main;
                allow 127.0.0.1;
                deny all;
            }
    }
}











展开阅读全文

没有更多推荐了,返回首页