ホームページ >運用・保守 >Linuxの運用と保守 >Nginx設定ファイル例の詳しい説明
Nginx設定ファイル例の詳しい説明
- 零下一度オリジナル
- 2017-06-25 10:11:452857ブラウズ
Nginx設定ファイルの構造
nginx設定ファイルはディレクティブで構成されており、命令は単純な命令とブロック命令の2つの形式に分かれています。
単純なコマンドは、コマンド名、パラメーター、および末尾のセミコロン (;) で構成されます。例: listen 80 backlog 4096;、ここで、「listen」はコマンド名「80」、 "backlog" " と "4096" はすべてパラメータであり、";" は命令の終了を示します。
ブロックコマンドは、コマンド名、パラメータ、中括弧({})で構成されます。例: location /imag {}。ここで、「location」はコマンド名、「/imag」はパラメータ、「{ }" 他の指示を含めて終了を示すために使用されます。ブロック命令の中括弧内に他の単純な命令やブロック命令を含めることができる場合、このブロック命令は「context(コンテキスト)」と呼ばれます。最も一般的に使用されるブロック命令は「context」です。
他のブロック命令に含まれていない命令はメイン コンテキストにあるとみなされます。つまり、メイン コンテキストは nginx 設定ファイルの最も外側のコンテキストであり、すべての命令はメイン コンテキストまたはサブコンテキストに配置されます。環境内のメインコンテキストの言語。次の設定ファイルの例を見てください: 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 命令はメイン コンテキストにあり、use 命令と worker_connections 命令はイベント コンテキストにあり、include、upstream、およびサーバー命令は http コンテキストにあり、2 つのサーバー命令はアップストリーム コンテキストにあります... nginx ソフトウェアはさまざまな機能を持つモジュールで構成されているため、設定ファイルもこのモジュール構造に従います。グローバル構成命令と関数 構成命令は、他の機能モジュールによって提供されます。上記の例のworker_processesとevent命令はnginxのコアモジュールによって提供され、http命令はhttp機能モジュールによって提供され、proxy_pass命令はhttpモジュールのサブモジュールによって提供されます。 nginx をインストールするとき、いくつかの一般的に使用される機能モジュールがデフォルトで含まれており、ソース コードのコンパイルとインストールを通じて、ユーザーが自由に選択して他の機能モジュールをインストールすることもできます。この機能モジュールにはどの命令が含まれているか、およびこれらの命令をどのコンテキストで設定する必要がありますが、インストールされているモジュールごとに異なる命令が含まれているため、コンテキスト (命令) からどの構成可能な命令が含まれているかを見つけることは信頼できません。初心者は他の人の例を参照することから始めるしかありません。 機能モジュールには http に加えて、メール (メール プロキシ) とストリーム (TCP、UDP プロキシ、v1.9.0 以降) も含まれますこれら 2 つの機能モジュール。
グローバル設定ディレクティブ- 構文:
include file | mask;
- デフォルト値: なし
- コンテキスト: 中古で入手可能なあらゆる
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;
offに設定すると、ワーカープロセスが取得します。ミューテックスロック 1 つだけ新しい接続は一度に処理されます。on に設定すると、すべての新しい接続が現在のミューテックス ロックを取得するワーカー プロセスに一度に割り当てられます。kqueue 接続処理メソッドを使用する場合 (kqueue を使用)、この命令は無効になります。
- 構文:
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+ (イベントポート)、IRIX 6.5.15+、および Tru64 UNIX 5.1A+)、イベントポート (Solaris 10+)
構文:
worker_aio_requestsnumber
;
-
デフォルト:worker_aio_requests 32; コンテキスト:イベント
v1.1.4 および 1.0.7 に登場。 aio (非同期 IO) および epoll 接続処理が有効な場合、単一ワーカー プロセスの未処理の非同期 IO 操作の最大数。
- 構文:
number
;
デフォルト値: worker_connections 512;コンテキスト: events
処理される同時接続の最大数。
この接続数には、クライアントへの接続だけでなく、バックエンド サーバーへのすべての接続が含まれます。すべてのワーカー プロセスの接続の合計数 (つまり、worker_connections × worker_processes) は、オペレーティング システムのオープン ハンドルの最大数 (nofile) の制限を超えることはできません。nofile の制限は、worker_rlimit_nofile 命令によって変更できます。
以上がNginx設定ファイル例の詳しい説明の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。