Detaillierte Erläuterung der Beispiele für Nginx-Konfigurationsdateien

Struktur der Nginx-Konfigurationsdatei

Die Nginx-Konfigurationsdatei besteht aus Anweisungen . Die Anweisungen sind in zwei Formen unterteilt: einfache Anweisungen und Blockanweisungen.

Ein einfacher Befehl besteht aus dem Befehlsnamen, Parametern und einem abschließenden Semikolon (;), zum Beispiel: listen 80 backlog 4096;, wobei „listen“ der Befehlsname ist, „80“, „backlog“ und „4096“ Parameter sind und „;“ das Ende des Befehls angibt.

Blockanweisung besteht aus dem Anweisungsnamen, Parametern und geschweiften Klammern ({}), zum Beispiel: location /imag {}, wobei „location“ das ist Anweisungsname, „/imag“ ist ein Parameter, „{}“ wird verwendet, um andere Anweisungen einzuschließen und das Ende anzuzeigen. Wenn die geschweiften Klammern in einer Blockanweisung andere einfache Anweisungen oder Blockanweisungen enthalten können, dann heißt diese Blockanweisung „Kontext (Kontext) “, und die am häufigsten verwendeten Blockanweisungen sind „Kontext".

Anweisungen, die nicht in anderen Blockanweisungen enthalten sind, gelten als im Hauptkontext, d. h. der Hauptkontext ist der äußerste Kontext in der Nginx-Konfigurationsdatei. Jede Anweisung befindet sich im Hauptkontext oder Hauptkontext im untergeordneten Kontext von . Schauen Sie sich bitte das folgende Beispiel einer Konfigurationsdatei an:

 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 }

Im obigen Beispiel befinden sich die Anweisungen „worker_processes“, „event“ und „http“ im Hauptkontext, die Anweisungen „use“ und „worker_connections“ befinden sich in der Ereigniskontext und include Die Anweisungen , Upstream und Server befinden sich im http-Kontext und die beiden Serveranweisungen befinden sich im Upstream-Kontext...

nginx-Software besteht aus Modulen mit verschiedenen Funktionen, Daher folgt auch die Konfigurationsdatei dieser Modularisierung. Das Nginx-Kernmodul stellt einige globale Konfigurationsanweisungen bereit, und die funktionalen Konfigurationsanweisungen werden von anderen Funktionsmodulen bereitgestellt. Die worker_processes- und event-Anweisungen im obigen Beispiel werden vom Kernmodul von nginx bereitgestellt, während die http-Anweisung vom http-Funktionsmodul bereitgestellt wird und die Proxy_pass-Anweisung von einem Submodul des http-Moduls bereitgestellt wird.

Bei der Installation von Nginx sind einige häufig verwendete Funktionsmodule standardmäßig enthalten. Benutzer können auch frei wählen, ob sie andere Funktionsmodule durch Kompilierung und Installation des Quellcodes installieren möchten. Bei der Konfiguration von Nginx finden Sie die Dokumentation für die Funktionsmodule In der Dokumentation wird erklärt, welche Anweisungen dieses Funktionsmodul enthält und in welchem ​​Kontext diese Anweisungen konfiguriert werden sollten. Es ist jedoch unzuverlässig, aus dem Kontext (Anweisungen) herauszufinden, welche konfigurierbaren Anweisungen es enthält, da die installierten Module unterschiedlich sind Es gibt auch unterschiedliche Anweisungen, daher erfordert die Konfiguration von Nginx zunächst etwas Erfahrung, indem man sich auf die Beispiele anderer Leute bezieht.

Zu den Funktionsmodulen gehören neben http auch Mail (Mail-Proxy) und Stream (TCP, UDP-Proxy, v1.9.0 und höher)

Diese beiden Funktionsmodule .

Globale Konfigurationsanweisungen

• Syntax:

  include Datei | Maske;

• Standardwert: keiner

• Kontext: beliebig

kann in jedem Kontext verwendet werden, um Anweisungen in anderen Konfigurationsdateien in den Kontext der Verwendung der Include-Direktive einzuführen. Die importierten Anweisungen müssen den Syntax- und Kontextanforderungen der Einführung entsprechen. Beispiel:

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:;
}

Die Protokollebene nicht spezifizierter Verbindungen wird weiterhin durch die Anweisung error_log bestimmt.

• Syntax: multi_accept on |.

• Standardwert: multi_accept off;

• Kontext: Ereignisse

Wenn diese Option deaktiviert ist, verarbeitet ein Arbeitsprozess jeweils nur eine neue Verbindung, wenn er den Mutex If erhält set Wenn es aktiviert ist, werden alle neuen Verbindungen sofort dem Arbeitsprozess zugewiesen, der die aktuelle Mutex-Sperre erhält. Bei Verwendung der kqueue-Verbindungsverarbeitungsmethode (verwenden Sie kqueue) ist diese Anweisung ungültig.

• Syntax: use method;

• Standardwert: Keine

• Kontext: Ereignisse

Geben Sie die Verbindungsverarbeitungsmethode an. Normalerweise ist keine Angabe erforderlich. Nginx verwendet automatisch die effektivste Methode .

Die Verbindungsverarbeitungsmethode wird verwendet, um die Methode zu bestimmen, mit der ermittelt werden soll, welche Verbindungen zum Senden/Empfangen von Daten aus dem aktuellen Verbindungspool bereit sind. Gängige Verbindungsverarbeitungsmethoden sind:

select (erfordert Auswahlmodul), poll (erfordert Poll-Modul), 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+ und Tru64 UNIX 5.1A+), Eventport (Solaris 10+)

• Syntax: worker_aio_requests Nummer;

• Standardwert: worker_aio_requests 32;

• Kontext: Ereignisse

erschien in v1.1.4 und 1.0.7. Wenn AIO (asynchrone E/A) und Epoll-Verbindungsverarbeitung aktiviert sind, die maximale Anzahl ausstehender asynchroner E/A-Vorgänge für einen einzelnen Arbeitsprozess.

• Syntax: worker_connections number;

• Standardwert: worker_connections 512;

• Kontext: Ereignisse

Die maximale Anzahl gleichzeitiger Verbindungen, die ein einzelner Arbeitsprozess verarbeiten kann.

Diese Anzahl an Verbindungen umfasst alle Verbindungen zum Backend-Server, nicht nur Verbindungen zu Clients. Die Gesamtzahl der Verbindungen aller Worker-Prozesse (dh worker_connections × worker_processes) darf den Grenzwert der maximalen Anzahl offener Handles (nofile) des Betriebssystems nicht überschreiten. Der nofile-Grenzwert kann über die Anweisung worker_rlimit_nofile geändert werden.

Das obige ist der detaillierte Inhalt vonDetaillierte Erläuterung der Beispiele für Nginx-Konfigurationsdateien. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!