Core functionality.md

核心功能

在Nginx配置文件总能够把配置文件的结构以下:html

main配置段
            event {
                ...
            }
            http {
                ...
                server {
                    server_name
                    root 
                    location /uri/ {
                        ...
                    }
                }
                server {
                    ...
                }
            }

在Nginx中每一个参数都会有本身所在的Context,有的只能在指定的Context使用,而有的配置能够在多个Context中使用。下面介绍的是main 段的和event端的相关配置。nginx

main配置段

daemon

Syntax: daemon on | off;
Default:    daemon on;
Context:    main

肯定nginx是否应该成为守护进程。 主要用于开发过程当中。web

env

Syntax: env variable[=value];
Default:    env TZ;
Context:    main

默认状况下,nginx删除从其父进程继承的全部环境变量,除了TZ变量。 此指令容许保留一些继承的变量,更改其值或建立新的环境变量。 详细参考正则表达式

events

Syntax: events { ... }
Default:    —
Context:    main

提供配置文件上下文,其中指定了影响链接处理的指令。服务器

load_module

Syntax: load_module file;
Default:    —
Context:    main
This directive appeared in version 1.9.11.

加载动态模块。此伪指令出如今1.9.11版本中。多线程

lock_file

Syntax: lock_file file;
Default:    lock_file logs/nginx.lock;
Context:    main

nginx使用锁定机制来实现accept_mutex和序列化对共享内存的访问。 在大多数系统上,锁是使用原子操做实现的,而且此伪指令被忽略。并发

master_process

Syntax: master_process on | off;
Default:    master_process on;
Context:    main

是否以master/worker模型运行nginx;app

pcre_jit

Syntax: pcre_jit on | off;
Default:    
pcre_jit off;
Context:    main
This directive appeared in version 1.1.12.

启用或禁用对配置解析时间已知的正则表达式使用“即时编译”(PCRE JIT)。
PCRE JIT能够加速正则表达式的处理。
JIT在PCRE库中可用,从使用--enable-jit配置参数构建的8.20版本开始。 当PCRE库使用nginx(--with-pcre =)构建时,经过--with-pcre-jit配置参数启用JIT支持。负载均衡

pid

Syntax: pid file;
Default:    pid nginx.pid;
Context:    main

指定nginx进程的pid文件路径;异步

ssl_engine

Syntax: ssl_engine device;
Default:    —
Context:    main

定义硬件SSL加速器的名称。

thread_pool

Syntax: thread_pool name threads=number [max_queue=number];
Default:    thread_pool default threads=32 max_queue=65536;
Context:    main
This directive appeared in version 1.7.11.

定义用于多线程读取和发送文件的命名线程池,而不阻塞worker进程。

timer_resolution

Syntax: timer_resolution interval;
Default:    —
Context:    main

该配置指令容许用户减小调用gettimeofday()的次数。默认状况下,该函数在每次I/O端口监听(好比epoll_wait)返回后都将被调用,而经过timer_resolution配置选项能够直接指定调用gettimeofday()函数的间隔时间。

user

Syntax: user user [group];
Default:    user nobody nobody;
Context:    main

定义worker进程使用的用户和组凭证。 若是省略group,则使用名称等于user的组。

worker_cpu_affinity

Syntax: worker_cpu_affinity cpumask ...;
worker_cpu_affinity auto [cpumask];
Default:    —
Context:    main

将worker进程绑定到CPU核心。 每一个CPU核心由容许的CPU的位掩码表示。 应该为每一个worker进程定义一个单独的核心。 默认状况下,worker进程不绑定到任何特定的CPU。
一个四核CPU能够作以下配置:

worker_processes    4;
worker_cpu_affinity 0001 0010 0100 1000;

上面是绑定每一个worker 进程到指定的CPU上,而下面的:

worker_processes    2;
worker_cpu_affinity 0101 1010;

将第一个worker进程绑定到CPU0 / CPU2,将第二个worker进程绑定到CPU1 / CPU3。 第二个例子适用于超线程。
特殊值auto(1.9.10)容许将worker进程自动绑定到可用的CPU:

worker_processes auto;
worker_cpu_affinity auto;

worker_priority

Syntax: worker_processes number | auto;
Default:    worker_processes 1;
Context:    main

定义worker进程的调度优先级,就像由nice命令完成的:负数意味着更高的优先级。 容许范围一般在-20到20之间变化。

worker_processes

Syntax: worker_processes number | auto;
Default:    worker_processes 1;
Context:    main

worker进程的个数;一般应该为物理CPU核心数量减1;能够为"auto",实现自动设定;

worker_rlimit_core

Syntax: worker_rlimit_core size;
Default:    —
Context:    main

更改worker进程最大核心文件大小(RLIMIT_CORE)的限制。用于在不从新启动主进程的状况下增长限制。

worker_rlimit_nofile

Syntax: worker_rlimit_nofile number;
Default:    —
Context:    main

更改worker进程最大打开文件数(RLIMIT_NOFILE)的限制。用于在不从新启动主进程的状况下增长限制。

working_directory

Syntax: working_directory directory;
Default:    —
Context:    main

定义worker进程的当前工做目录。 它主要用于编写核心文件,在这种状况下,worker进程应该具备指定目录的写入权限。

event 配置段

accept_mutex

Syntax: accept_mutex on | off;
Default:    accept_mutex off;
Context:    events

各worker接收用户的请求的负载均衡锁;启用时,表示用于让多个worker轮流地、序列化地响应新请求; 不然,将向全部worker进程通知有关新链接的信息,若是新链接数量较少,则某些worker进程可能只会浪费系统资源。
在版本1.11.3以前,默认值为on。

accept_mutex_delay

Syntax: accept_mutex_delay time;
Default:    accept_mutex_delay 500ms;
Context:    events

若是启用accept_mutex,则指定若是另外一个worker进程当前正在接受新链接,worker进程将尝试从新启动接受新链接的最长时间。

multi_accept

Syntax: multi_accept on | off;
Default:    multi_accept off;
Context:    events

若是禁用multi_accept,worker进程将一次接受一个新链接。 不然,worker进程将一次接受全部新链接。

use

Syntax: use method;
Default:    —
Context:    events

指定要使用的链接处理方法。 一般不须要明确指定它,由于nginx将默认使用最有效的方法。

worker_aio_requests

Syntax: worker_aio_requests number;
Default:    worker_aio_requests 32;
Context:    events
This directive appeared in versions 1.1.4 and 1.0.7.

当使用带有epoll链接处理方法的aio时,为单个worker进程设置未完成的异步I / O操做的最大数量。

worker_connections

Syntax: worker_connections number;
Default:    worker_connections 512;
Context:    events

每一个worker进程所可以响应的最大并发请求数量;应该记住,这个数字包括全部链接(例如与代理服务器的链接等),而不单单是与客户端的链接。 另外一个考虑是同时链接的实际数量不能超过打开文件的最大数量的当前限制,能够经过worker_rlimit_nofile更改。
在nginx中设置的最大链接数为:
worker_proceses * worker_connections

其余

include

Syntax: include file | mask;
Default:    —
Context:    any

将另外一个文件或匹配指定掩码的文件包含到配置中。 包含的文件应包含语法正确的指令和块。

error_log

Syntax: error_log file [level];
Default:    error_log logs/error.log error;
Context:    main, http, mail, stream, server, location

配置日志记录。 第一个参数定义将存储日志的文件。 第二个参数肯定日志记录的级别,能够是如下之一:debug,info,notice,warn,error,crit,alert或emerg。 以上的日志级别按严重性递增的顺序列出。 设置特定日志级别将致使记录指定日志级别和更严重日志级别的全部消息。 例如,默认级别error将致使记录错误,crit,alert和emerg消息。 若是省略此参数,则使用error。 出于调试的须要,能够设定为debug;但debug仅在编译时使用了“--with-debug”选项时才有效;

相关文章
相关标签/搜索