ChsHttpMainModule
Nginx Main Module
杩欓噷鏄帶鍒 Nginx 鐨勫熀鏈姛鑳界殑鎸囦护.
鎸囦护
- [#daemon daemon]
- [#debug_points debug_points]
- [#error_log error_log]
- [#include include]
- [#lock_file lock_file]
- [#master_process master_process]
- [#pid pid]
- [#ssl_engine ssl_engine]
- [#timer_resolution timer_resolution]
- [#user user group]
- [#worker_cpu_affinity worker_cpu_affinity]
- [#worker_priority worker_priority]
- [#worker_processes worker_processes]
- [#worker_rlimit_core worker_rlimit_core]
- [#worker_rlimit_nofile worker_rlimit_nofile]
- [#worker_rlimit_sigpending worker_rlimit_sigpending]
- [#working_directory working_directory]
daemon
璇硶: daemon on | off
缂虹渷鍊: on
daemon off;
Do not use the "daemon" and "master_process" directives in a production mode, these options are mainly used for development only. You can use daemon off
safely in production mode with runit / daemontools however you can't do a graceful upgrade. master_process off
should never be used in production.
鐢熶骇鐜涓笉瑕佷娇鐢"daemon"鍜"master_process"鎸囦护锛岃繖浜涢夐」浠呯敤浜庡紑鍙戣皟璇曘
debug_points
璇硶: debug_points [stop | abort]
缂虹渷鍊: none
debug_points stop;
There are some assertion points inside nginx that allow to stop nginx to attach the debugger, or to abort and to create the core file.
搴旇閫傜敤浜庤皟璇曪紝鍦ㄨ皟璇曞櫒鍐呰缃柇鐐逛箣绫荤殑銆
error_log
璇硶: error_log file [ debug | info | notice | warn | error | crit ]
缂虹渷鍊: ${prefix}/logs/error.log
Nginx 娣诲姞 --with-debug 缂栬瘧鍙傛暟
, 浣犺繕鑳藉浣跨敤浠ヤ笅閰嶇疆:
error_log LOGFILE [ debug_core | debug_alloc | debug_mutex | debug_event ]: | debug_http | debug_imap ;
include
璇硶: include file | *
缂虹渷鍊: none
浣犲彲浠ュ湪浠绘剰鍦版柟浣跨敤include鎸囦护瀹炵幇閰嶇疆鏂囦欢鐨勫寘鍚紝绫讳技浜巃pache涓殑include鏂规硶锛屽彲鍑忓皯涓婚厤缃枃浠禿銆
include
鎸囦护杩樻敮鎸佸儚涓嬮潰閰嶇疆涓鏍风殑鍏ㄥ眬鍖呭惈鐨勬柟娉曪紝渚嬪鍖呭惈涓涓洰褰曚笅鎵鏈変互".conf"缁撳熬鐨勬枃浠:
include vhosts/*.conf;
娉ㄦ剰璺緞鍙楀埌configure缂栬瘧鍙傛暟--prefix=<璺緞>鎸囦护鐨勫奖鍝嶏紝濡傛灉娌℃湁鎸囧畾锛孨ginx榛樿鏄缂栬瘧鍦/usr/local/nginx銆
璇硶: lock_file file
缂虹渷鍊: compile-time option
lock_file /var/log/lock_file;
nginx uses accept mutex to serialize accept() syscalls. If nginx is built by gcc, Intel C++, or SunPro C++ compilers on i386, amd64, sparc64, and ppc64, then nginx uses the atomic instructions to implement the mutex. In other cases the lock file would be used.
master_process
璇硶: master_process on | off
缂虹渷鍊: on
master_process off;
Do not use the "daemon" and "master_process" directives in a production mode, these options are mainly used for development only.
鐢熶骇鐜涓笉瑕佷娇鐢"daemon"鍜"master_process"鎸囦护锛岃繖浜涢夐」浠呯敤浜庡紑鍙戣皟璇曘
pid
璇硶: pid file
缂虹渷鍊: compile-time option Example:
pid /var/log/nginx.pid;
杩涚▼id瀛樺偍鏂囦欢銆傚彲浠ヤ娇鐢 kill -HUP cat /var/log/nginx.pid\
瀵筃ginx杩涜閰嶇疆鏂囦欢閲嶆柊鍔犺浇銆
ssl_engine
璇硶: ssl_engine engine
缂虹渷鍊: system dependent
Here you can set your preferred openssl engine if any available. You can figure out which one do you have with the commandline tool:
璇ユ寚浠ょ敤浜庢寚瀹歰penssl浣跨敤鐨勫紩鎿庛備綘鍙互閫氳繃涓嬮潰鐨勫懡浠よ鑾风煡绯荤粺鐩墠鏀寔鐨刼penssl寮曟搸
openssl engine -t
渚嬪:
$ openssl engine -t (cryptodev) BSD cryptodev engine : [ available ] (dynamic) Dynamic engine loading support : [ unavailable ]
timer_resolution
璇硶: timer_resolution t
缂虹渷鍊: none
Example:
timer_resolution 100ms;
The directive allows to decrease number gettimeofday() syscalls. By default gettimeofday() is called after each return from kevent(), epoll, /dev/poll, select(), poll().
But if you need an exact time in logs when logging $upstream_response_time, or $msec variables, then you should use timer_resolution
.
user
璇硶: user user [group]
缂虹渷鍊: nobody nobody
鎸囧畾Nginx Worker杩涚▼杩愯鐢ㄦ埛锛岄粯璁ゆ槸nobody甯愬彿銆
渚嬪:
user www users;
worker_cpu_affinity
璇硶: worker_cpu_affinity cpumask [cpumask...]
缂虹渷鍊: none
Linux only.
With this option you can bind the worker process to a CPU, it calls sched_setaffinity().
浠呴傜敤浜巐inux锛屼娇鐢ㄨ閫夐」鍙互缁戝畾worker杩涚▼鍜孋PU.
For example,
worker_proceses 4; worker_cpu_affinity 0001 0010 0100 1000;
Bind each worker process to one CPU only.
鍒嗗埆缁欐瘡涓獁orker杩涚▼缁戝畾涓涓狢PU.
worker_proceses 2; worker_cpu_affinity 0101 1010;
Bind the first worker to CPU0/CPU2, bind the second worker to CPU1/CPU3. This is suitable for HTT.
灏咰PU0/CPU2缁戝畾缁欑涓涓獁orker杩涚▼锛屽皢CPU1/CPU3缁戝畾缁欑浜屼釜worker杩涚▼銆
worker_priority
璇硶: worker_priority [-] number
缂虹渷鍊: on
With this option you can give to all worker processes the priority (nice) you need/wish, it calls setpriority().
浣跨敤璇ラ夐」鍙互缁欐墍鏈夌殑worker杩涚▼鍒嗛厤浼樺厛鍊笺
worker_processes
璇硶: worker_processes number
缂虹渷鍊: 1
e.g.:
worker_processes 5;
nginx has the ability to use more than one worker process for several reasons:
nginx鍙互浣跨敤澶氫釜worker杩涚▼锛屽師鍥犲涓嬶細
- to use SMP
- to decrease latency when workers blockend on disk I/O
- to limit number of connections per process when select()/poll() is used
The worker_processes
and worker_connections
from the event sections allows you to calculate maxclients
value: k
max_clients = worker_processes * worker_connections
worker_rlimit_core
璇硶: worker_rlimit_core size
缂虹渷鍊: '
Maximum size of core file per worker;
worker_rlimit_nofile
璇硶: worker_rlimit_nofile limit 缂虹渷鍊: '
Specifies the value for maximum file descriptors that can be opened by this process.
鎸囧畾
worker_rlimit_sigpending
璇硶: worker_rlimit_sigpending limit 缂虹渷鍊: '
(Since Linux 2.6.8) Specifies the limit on the number of signals that may be queued for the real user ID of the calling process.
working_directory
璇硶: working_directory path 缂虹渷鍊: --prefix
This is the working directory for the workers. It's used for core files only. nginx uses absolute paths only, all relative paths in configuration files are relative to --prefix==PATH
.