首頁  >  文章  >  運維  >  Nginx設定檔實例詳解

Nginx設定檔實例詳解

零下一度
零下一度原創
2017-06-25 10:11:452752瀏覽

Nginx設定檔結構

 nginx設定檔由指令(directive)組成,指令分為兩種形式,簡單指令和區塊指令。

一條簡單指令由指令名、參數和結尾的分號(;)組成,例如:listen 80 backlog 4096; ,其中「listen」是指令名,「80」、「backlog」、「4096」都是參數,「;」表示指令結尾。

區塊指令由指令名稱、參數和花括號(​​{})組成,例如: location /imag {} ,其中「location」是指令名,「/imag」是參數,「{}」用來包括其它指令和表示結尾。如果一個區塊指令中的大括號可以包括其它簡單指令或區塊指令,那麼這種區塊指令稱為“語境(context)”,大部分常用的區塊指令都是"情境".

不被任何其它區塊指令包含的指令被認為處於main語境中,即main語境是nginx設定檔中最外層語境,任何指令都位於main語境或main語境的子級語境中。請看下面的設定檔範例:

 1 # nginx.conf 2 worker_processes 2; 3 events { 4     use epoll; 5     worker_connections 1024; 6 } 7 http { 8     include       mime.types; 9     upstream server_group_a {   
10       server 192.168.1.1:8080;11       server 192.168.1.2:8080;12     }13     server {14         listen       80;15         server_name  www.example.com;   
16         location / {17            proxy_pass  http://server_group_a;        18         } 
19     }20 }

上例中,worker_processes、event、http指令處於main情境中,use、worker_connections指令位於event情境中,include、upstream 、server指令位於http語境中,兩個server指令位於upstream語境中…

nginx軟體是由各種不同功能的模組組成的,因此設定檔也遵照這種模組化的結構,nginx核心模組提供一些全域的設定指令,功能配置指令則由其他的功能模組提供。上例的worker_processes、event指令都由nginx的核心模組提供,而http指令由http功能模組提供,proxy_pass指令則由http模組的子模組提供。

在安裝nginx時,預設包含了一些常用功能模組,使用者也可以透過原始碼編譯安裝的方式自由選擇安裝其他功能模組,在配置nginx時可以查找功能模組的文檔,文件中會說明這個功能模組包括哪些指令,以及這些指令應該在哪些語境下配置,而從語境(指令)查找它包含哪些可以配置的指令卻是不靠譜的,因為安裝的模組不同,包含的指令也不一樣,因此配置nginx需要有一些經驗,初入門者只能先從參考他人的範例著手。

功能模組除了http外,還有mail(郵件代理)、stream(TCP、UDP代理,v1.9.0以後)這兩個功能模組

 

全域設定指令

  • 語法:include file | mask;

  • 預設值:無

  • ##語境:任意

可在任意情境中使用,將其他設定檔中的指令引入使用include指令的情境中。被引入的指令需要符合文法和引入的語境要求。範例:

http {
    include mime.types;
    include vhosts/*.conf;
}
#

将mime.types和vhosts目录下以“.conf”结尾的文件引入到http语境中。

 

  • 语法:deamon on | off;

  • 默认值:deamon on

  • 语境:main

指定nginx是否以守护进程运行。

 

  • 语法:debug_points abort | stop;

  • 默认值:无

  • 语境:main

用于debug,判断nginx内部错误,特别是判断工作中进程的socket溢出问题。nginx代码中包含了一些调试点,如果debug_points设置为abord,当运行到调试点时会产生一个核心运行信息dump文件,当设置为stop时会停止进程。

 

  • 语法:error_log file [level]

  • 默认值:error_log logs/error.log error;

  • 语境:main, http, mail(v1.9.0后), stream(v1.7.11后), server, location

指定日志文件和日志级别。

file可以是指定的文件,也可以是标准错误输出文件stderr、syslog服务器或内存。输出到syslog服务器使用“syslog:”前缀,输出到循环内存缓冲区使用“memory:”前缀和缓冲区大小。

level参数指定输出日志的级别,高于指定级别的日志将被输出。支持的级别从低到高依次有:debug、info、notice、warn、error、crit、alert、emerg。

指定debug级别需要编译时安装了debug模块。

 

  • 语法:env variable[=value];

  • 默认值:env TZ;

  • 语境:main

默认情况下,nginx只会继承TZ这个环境变量,这条指令可以将环境变量传递到nginx进程中,也可以定义新的变量传递到nginx进程中。

 

  • 语法:load_module file;

  • 默认值:无

  • 语境:main

载入动态模块。例如:

load_module module/ngx_mail_module.so;

 

  • 语法:lock_file file;

  • 默认值:lock_file logs/nginx.lock;

  • 语境:main

nginx使用锁的机制来实现accept_mutex功能和共享内存,大多数操作系统中锁都是一个原子操作,这种情况下这条指令无效,还有一些操作系统中使用“锁文件”的的机制来实现锁,此命令用来指定锁文件前缀名。

 

  • 语法:master_process on | off;

  • 默认值:master_process on;

  • 语境:main

是否启用worker进程,如果设置为off,则不启用worker进程,由master进程处理请求。

 

  • 语法:pcre_jit on | off;

  • 默认值:pcre_jit off;

  • 语境:main

在解析配置文件时对正则表达式启用或禁用实时编译(PCRE JIT)。

RCRE JIT能显著提升正则表达式的处理速度。

JIT依赖PCRE库8.20以后版本,并且在编译时需要指定--enable-jit参数。也可以将PCRE库作为nginx的模块编译安装(编译nginx指定--with-pcre=参数),并在编译时指定--with-pcre-jit参数启用JIT功能。

 

  • 语法:pid file;

  • 默认值:pid nginx.pid;

  • 语境:main

指定pid文件。pid文件存放了master进程的进程号。

 

语法:ssl_engine device;

默认值:无

语境:main

如果使用了硬件ssl加速设备,使用此指令指定。

 

  • 语法:thread_pool name threads=number [max_queue=number];

  • 默认值:thread_pool default threads=32 max_queue=65535;

  • 语境:main

在使用异步IO的情况下,定义命名线程池,并设置线程池大小和等待队列大小。当线程池中所有线程都繁忙时,新任务会放在等待队列中,如果等待队列满了,任务会报错退出。

命名线程池可以定义多个,供http模块的异步线程指令(aio)调用。

此指令在v1.7.11中出现。

 

  • 语法:timer_resolution interval;

  • 默认值:无

  • 语境:main

设置时间精度,减少worker进程调用系统时间函数的次数。默认情况下,每个核心事件都会调用gettimeofday()接口来获得系统时间,以便nginx计算连接超时等工作,此指令指定更新时间的间隔,nginx在间隔时间内只调用一次系统时间函数。

 

  • 语法:user user [group];

  • 默认值:user nobody nodoby;

  • 语境:main

指定master启动worker进程使用的linux用户和组。如果组(group)没有指定,那么会默认用一个和user同名的组名。

 

  • 语法:worker_processes number | auto

  • 默认值:worker_processes 1

  • 语境:main

指定worker进程的数量。进程数最好是CPU核心数或CPU核心数的倍数。当设置为auto时,nginx会尝试自动获取CPU核心数并设置。

auto参数从v1.3.8和v1.2.5版本以后支持。

 

  • 语法:worker_cpu_affinity cpumask ...;

  •    worker_cpu_affinity auto [cpumask];

  • 默认值:无

  • 语境:main

将worker进程绑定到CPU核心,每个worker进程对应一个二进制掩码,掩码的每一位对应一个CPU。默认情况下,worker不与cpu核心绑定。此指令只适用于Linux和FreeBSD。

举例:

worker_processes 4;
worker_cpu_affinity 0001 0010 0100 1000;

表示有4个worker进程,第一个绑定到CPU0,第二个绑定到CPU1,以此类推,4个进程分别绑定一个CPU核心。

再例:

worker_processes 2;
worker_cpu_affinity 0101 0101;

表示将第一个进程绑定到CPU0/CPU2,第二个worker进程绑定到CPU1/CPU3,这个例子适用于超线程场景,即一个核心虚拟出两个CPU线程。

值auto(v1.9.10)允许自动和可用的CPU绑定:

worker_process auto;
worker_cpu_affinity auto;

掩码(mask)可用用于限制某些CPU参加绑定。例如:

worker_cpu_affinity auto 01010101;

只有CPU0/2/4/6参与绑定,其他的CPU不分配worker进程。

 

  • 语法:worker_rlimit_core size;

  • 默认值:无

  • 语境:main

为worker进程修改系统核心转储文件(core file)的大小限制。通常提升这个值不需要重启主进程。

 

  • 语法:worker_rlimit_nofile number;

  • 默认值:无

  • 语境:main

修改worker进程最大可打开句柄数限制。通常提升这个值不需要重启主进程。

 

  • 语法:worker_shutdown_timeout time;

  • 默认值:无

  • 语境:main

此指令在v1.11.11中出现。用于设置安全地结束一个worker进程的超时时间。

当安全结束一个worker进程时,会停止对worker进程分配新连接,并等待他处理完当前的任务后再退出,如果设置了超时时间,超时后nginx会强制关闭worker进程的连接。

 

  • 语法:working_directory directory;

  • 默认值:无

  • 语境:main

指定默认工作路径。主要用于worker进程导出内存转储文件,为worker进程指定的用户需要有改文件的写入权限。

 

连接处理控制指令

  • 语法:events { ... }

  • 默认值:无

  • 语境:main

作用只是开辟一个指令区块,events语境中配置的指令用于控制连接处理行为。

 

  • 语法:accept_mutex on | off;

  • 默认值:accept_mutex off;

  • 语境:events

当启用这个参数时,会使用互斥锁交替给worker进程分配新连接,否则话所有worker进程会争抢新连接,即或造成所谓的“惊群问题”,惊群问题会使nginx的空闲worker进程无法进入休眠状态,造成系统资源占用过多。启用此参数会一定程度上导致后台服务器负载不均衡,但是在高并发的情况下,关闭此参数可以提高nginx的吞吐量。

在支持epoll的操作系统上不需要启用accept_mutex(v1.11.3后),使用了reuseport功能也不需要启用(v1.9.1后,需要操作系统支持SO_REUSEPORT socket选项,Linux 3.9+)。

在v1.11.3以前版本中,默认值为on。

 

  • 语法:accept_mutex_delay time;

  • 默认值:accept_mutex_delay 500ms;

  • 语境:events

如果accept_mutex参数启用,当一个空闲worker进程尝试获取互斥锁时发现有另一个worker进程已经获得互斥锁并处理新连接,这个空闲的worker进程等待下一次获取互斥锁尝试的时间。而获得互斥锁的进程在处理完当前连接后,会立即尝试获取互斥锁,因此此数值较大或连接压力较小时,会造成部分worker进程总是空闲,一部分进程总是繁忙的情况。

 

  • 语法:debug_connection address | network | unix:;

  • 默认值:无

  • 语境:events

需要debug模块支持,需确认安装时包括了debug模块,可以使用nginx -V命令确定包含--wih-debug参数。

对特定的客户发起的连接开启debugging级别日志,用于分析和拍错。可以指定IPv4或者IPv6地址(v1.3.0,v1.2.1)或一个无类网段或域名,或UNIX socket(v1.3.0,v1.2.1)。例如:

events {
    debug_connection 127.0.0.1;
    debug_connection localhost;
    debug_connection 192.168.2.0/24;
    debug_connection 2001:0db8::/32;
    debug_connection unix:;
}

非指定連線的日誌等級仍由error_log指令決定。

 

  • 語法:multi_accept on | off;

  • ##預設值:multi_accept off;

  • 語境:events

當設定為off時,一個worker進程獲得互斥鎖時一次只處理一個新連接,如果設定為on,則一次將所有新連線都指派給獲得目前互斥鎖的worker進程、當使用kqueue連線處理方式時(use kqueue),此項指令無效。

 

  • 語法:

    use method;

  • 預設值:無

  • 情境:events

#指定連線處理方式,通常不需要指定,nginx會自動使用最有效的方式。

連線處理方式用來決定用什麼方法從目前的連線池中找出哪些連線已經準備好傳輸/接收資料。常見的連接處理方式有:

select(需要select模組)、poll(需要poll模組)、kqueue(macOS/FreeBSD 4.1+/OpenBSD 2.9+)、epoll(Linux 2.6+)、/dev/ poll(Solaris 7 11/99+, HP/UX 11.22+ (eventport), IRIX 6.5.15+, and Tru64 UNIX 5.1A+)、eventport(Solaris 10+)

 

  • 語法:

    worker_aio_requests number;

  • 預設值:worker_aio_requests 32;

  • #語境:events

在v1.1.4和1.0.7中出現。啟用aio(非同步IO)和epoll連線處理方式後,單一worker進程最大的未完成非同步IO操作數。

 

  • 語法:

    worker_connections number;

  • ##預設值: worker_connections 512;
  • 語境:events
  • 單一worker進程可處理的最大並發連線數限制。

這個連接數包括和後台伺服器之間的連接在內的所有的連接,而不僅是與客戶的連接。所有worker進程的總連線數(即worker_connections × worker_processes )不能超過作業系統最大可開啟句柄數的限制(nofile),nofile限制可以透過worker_rlimit_nofile指令修改。

 

以上是Nginx設定檔實例詳解的詳細內容。更多資訊請關注PHP中文網其他相關文章!

陳述:
本文內容由網友自願投稿,版權歸原作者所有。本站不承擔相應的法律責任。如發現涉嫌抄襲或侵權的內容,請聯絡admin@php.cn