Nginx 服务的配置语法、基本配置项及解析

Nginx 服务基本配置

配置文件是文本文件

语法

块配置项

name{
    ...
}

块配置项可以嵌套，内层块直接继承外层块

配置项语法

name value1 value2

如果 value 中有语法符号，需使用单或双引号括住 value

注释

# ...

变量

$variable_name

并非所有模块都支持变量

基本配置项

调试配置项

deamon

deamon on|off;

默认 on

守护进程，脱离终端还能在后台运行，跟踪调试 nginx 时可以选择关闭

master_process

master_process on|off

默认 on

是否以 master/worker 方式工作，关闭后不会 fork 子进程，而是 master 处理请求

error_log

error_log /path/file level;

默认 logs/error.log error ，存放在 /usr/local/nginx/logs 中

错误日志路径和输出等级

配置项是 /dev/null 时不会输出任何日志

配置项是 stderr 时输出到标准错误文件中，在系统错误文件中查看

level

错误 level 由低到高为：

debug       # level 为 debug 时，须在执行 ./configure 时加入 --with-debug 配置项
​
info
​
notice
​
warn
​
error
​
crit
​
alert
​
emergdebug       # level 为 debug 时，须在执行 ./configure 时加入 --with-debug 配置项
​
info
​
notice
​
warn
​
error
​
crit
​
alert
​
emerg

低于设定 level 的日志不会被输出

debug_point

debug_point [stop|abort]

stop

执行到调试点时会发出 SIGSTOP 信号

abort

产生 coredump 文件， coredump 文件进程运行时在突然崩溃的那一刻的一个内存快照，操作系统在程序发生异常而异常在进程内部又没有被捕获的情况下，会把进程此刻内存、寄存器状态、运行堆栈等信息转储保存在一个文件里。该文件也是二进制文件，可以使用gdb、elfdump、objdump 分析文件，存储在 $ cat /proc/sys/kernel/core_pattern|/usr/share/apport/apport %p %s %c %P

//在终端键入下列命令
​
echo "/data/coredump/core.%e.%p" > /proc/sys/kernel/core_pattern

在这条命令中，/data/coredump是你自己指定的存放coredump文件的路径，所有产生的coredump文件将会存放在这里，%e表示程序的文件名，%p表示进程的ID（当然还有一些其他的参数可以设置，例：%t显示创建的时间）,但是前提要把目录/data/coredump创建好，不然无法生成文件

%E：程序文件的完整路径（路径中的/会被!替代） %p：进程 ID %t：进程奔溃的时间戳 %s：哪个信号让进程奔溃

~/C++/testcore$ gdb test2 core 

通常不会使用这个配置项

debug_connection

debug_connection [IP|CIDR]

仅针对指定客户端输出 debug 级别的日志

须在执行 ./configure 时加入 --with-debug 配置项

worker_rlimit_core

worker_rlimit_core size;

限制 coredump 文件大小

working_directory

working_directory path;

worker 进程工作目录，用于设置 coredump 文件存放位置

运行时配置项

env

env VAR|VAR=VALUE

设置环境变量

include

include path/file;

引入其他配置文件，path 可是绝对路径也可是相对路径

filename 可含有 通配符 * ，一次嵌入多个文件

eg. include vhost/*.conf

pid

pid path/file;

默认：logs/nginx.pid

设置 pid 文件路径

pid 文件是存放 master 进程 ID 的文件，同时需要确认 nginx 是否有权创建该文件

user

user username [groupname];

设置 fork 出的 woker 运行的用户和用户组，用户和用户组重名设置 user username 即可，configure 时设置了 --user --group 参数时则按照参数执行

worker_rlimit_noflie

worker_rlimit_noflie limit;

一个 worker 可以打开的最大文件句柄数

worker_rlimit_sigpending

worker_rlimit_sigpending limit;

设置每个用户发往 nginx 的信号队列大小，列满后在发送的信号会被丢弃

优化性能配置项

woker_processes

woker_processes number;

worker 进程个数

有可能出现阻塞式调用时，要配置比 CPU 内核稍多些 worker ，但会增大进程间切换带来的消耗（Linux 是抢占式内核）

worker_cpu_affinity

worker_cpu_affinity cpumask [cpumask..]

worker 绑定指定 CPU 内核，仅对 Linux 系统有效

每个 worker 进程都独享一个 CPU ，就在 CPU 调度上实现了完全的并发，避免多个 worker 抢占同一个 CPU 内核

eg.

woker_processes 4;
worker_cpu_affinity 1000 0100 0010 0001;

ssl_engine

ssl_engine device;

绑定ssl 硬件加速设备

可通过openssl engine -t 查询是否由 SSL 加速设备

timer_redolution

timer_redolution t;

系统调用 gettimeofday 的执行频率

每次内核事件的调用都会执行一次 gettimeofday ，早期 Linux 内核中，gettimeofday 执行代价不小，但在目前大多数内核中，gettimeofday 只是一次 vsyscall ，Linux 内核在用户空间映射一个包含一些变量及一些系统调用的实现的内存页。因此, 这些系统调用将在用户空间下执行，这意味着将不发生上下文切换，代价并不大

通常不会使用这个配置

worker_priority

worker_priority nice;

默认 0

设置 worker 进程的优先级

nice 值

nice 值是进程的静态优先级，取值范围是 -20 ~ +19，-20 是最高优先级，+19 是最低优先级

优先级由静态优先级和内核根据进程执行情况做出 (+5 / -5) 的调整

优先级越高，进程所分配的 CPU 时间片大小越大，优先级高的进程占用更多的系统资源

nice 值配置的小一些可以使 Nginx 占有更多的系统资源，但不建议比内核进程的 nice 值（通常为 -5）更小

事件类配置项

accept_mutex

accept_mutex [on|off]

默认：on

负载均衡锁，可以让多个 worker 进程轮流有序地与客户端建立 TCP 连接

mutex 互斥锁

lock_file

lock_file path/file;

默认：logs/nginx.lock

lock 文件的的路径

accpet 锁关闭，此配置不生效

accpet 锁开启时，若因为编译程序或 OS 架构原因导致 Nginx 不支持原子锁时才会用文件锁实现 accept 锁，这时 lock_file 配置指定的 lock 文件才会生效

accept_mutex_delay

accept_mutex_delay Nms;

默认： 500ms

使用 accept 锁后到真正建立连接之间的延迟时间

multi_accept

multi_accept [on|off];

默认：off

批量建立新连接

当时间模型通知有新连接时，尽可能对本次调度中发起的所有 TCP 请求都建立连接

use

use [kqueue|rtsig|epoll|/dev/poll|select|poll|eventport];

默认：Nginx 会自动选择最合适的事件模型

选择事件模型

Linux 系统可选 poll、select、epoll 三种模型，其中 epoll 性能最高

worker_connections

worker_connections numbers;

每个 worker 的可同时处理的最大连接数

参考资料：《深入理解 Nginx --模块开发与架构解析》--陶辉