Nginx配置文件指令
上一篇文章说了一下Nginx配置文件的组织结构，介绍了main配置段、event配置段、http配置段、upstream配置段、server配置段等；下面针对每个配置段所常用的指令介绍说明。
一、main block配置段常用指令
对于全局配置段（main block）来说，常用的指令可以分为以下几个类别：
第一类：正常运行必备指令
1）user
|
1 2 3 |
Syntax: user user [group]; Default:user nobody nobody; Context:main |
指定用于运行worker进程的用户和组，不指定默认也会用nobody用户，如果安装nginx时指定了用户，就会默认使用编译时指定的用户。
2）pid
|
1 2 3 |
Syntax: pid file; Default:pid nginx.pid; Context:main |
指定nginx进程的pid文件路径，默认会使用编译时指定的路径，这里可以更改。
3）worker_rlimit_nofile
|
1 2 3 |
Syntax: worker_rlimit_nofile number; Default: — Context: main |
指定每一个worker进行能打开的最大文件描述符数量，worker进行以nginx用户运行，而单个用户最大能打开的文件描述符是1024个，所以单个worker进程最多能响应1024个请求，所以如果希望提供更多的并发连接，这个值就需要调大。如果有4个进程，一个进程最多可以响应1024个连接，那么这里的值最少不能低于4×1024=4096个连接，也就是单个用户最多能打开4096个连接。
第二类：优化性能相关指令
4）worker_processes
|
1 2 3 |
Syntax: worker_processes number | auto; Default:worker_processes 1; Context:main |
指定打开worker进程的个数，通常应该为物理CPU核心数减1，而查看CPU核心的可以使用命令lscpu即可；另外也可以使用auto值，表示nginx会自动根据CPU核心数创建worker进程数量。需要注意的是，Nginx的特点是不使用进程来响应用户请求、也不使用线程要响应用户请求，而是使用一个进程响应多个用户请求（基于epoll事件驱动机制），这样就避免了进程切换的开销。为什么会核心数减1呢？如果你的系统是24核的，那么你可以把另外23核绑定到特定的worker进程上，这样可以实现非常好的响应性能；另外1核留给系统自身使用。当然这样做还需要一些额外的设置，系统开机时就把这23核隔离出来不给系统使用，然后绑定到每个worker进程上；这还不够，我们系统还有中断要处理，这就需要我们手动把中断也丢给那1个核心处理，这样一来这23核CPU才真正做到只处理worker进程。看上去非常麻烦是吧，好在Nginx还提供了一个类似的指令。
5）worker_cpu_affinity
|
1 2 3 4 |
Syntax: worker_cpu_affinity cpumask ...; worker_cpu_affinity auto [cpumask]; Default:— Context:main |
设置CPU绑定，也称为CPU的姻亲关系，而CPUMASK就是CPU的掩码，如0001、0010等；怎么绑定呢？如，worker进程开的是3个，worker_cpu_affinity就设定为worker_cpu_affinity 0001 0010 0011，对于这三个worker即可。当设置成auto时，tengine将根据worker的数量自动配置cpu绑定位图。绑定的顺序是按CPU编号从大到小。 如果worker数量大于cpu数量，则剩余的worker进程将按照CPU编号从大到小的顺序从编号最大的CPU开始再次绑定。但是这种方式并不能真正地绑定进程到特定CPU上。
6）worker_priority
|
1 2 3 |
Syntax: worker_priority number; Default:worker_priority 0; Context:main |
用于设定worker进程的nice值（进程调度优先级），可调整参数为-20到19，值越小优先级越高，默认值为0。
第三类：用于调试定位问题指令
7）daemon
|
1 2 3 |
Syntax: daemon on | off; Default:daemon on; Context:main |
是否已守护进程的方式开启Nginx，默认为on；如果需要定位问题可以使用off看看输出信息，另外如果想使用类似supervisor这样的工具来启动nginx进程也必须不能启用daemon为on，但应该没人这么做。
8）master_process
|
1 2 3 |
Syntax: master_process on | off; Default:master_process on; Context:main |
是否已master/worker模型来启动Nginx，默认是以master/worker方式启动Nginx，无需更改，知道就好。
9）error_log
|
1 2 3 |
Syntax: error_log file | stderr | syslog:server=address[,parameter=value] | memory:size [debug | info | notice | warn | error | crit | alert | emerg]; Default:error_log logs/error.log error; Context:main, http, mail, stream, server, location |
可以用于指定错误日志的日志级别，同样处于调试目的，可指定为debug级别，此时会有非常详细的信息输出，如Nginx接收文件内部怎么处理的等，但是编译时必须指定了–with-debug选项才可以。另外还可以使用syslog:server=address选项把日志发送到远程日志服务器中存储，后面讲日志模块会详细介绍，因为在企业中一般都是把日志打入到远程的ELK或日志服务器，用于分析使用。
二、event{}配置段常用配置指令
1）worker_connections
|
1 2 3 |
Syntax: worker_connections number; Default:worker_connections 512; Context:events |
用于指定每个worker进程最大可接收的并发连接数，默认为512个（安装完默认worker为2014，不知道为什么跟官方说的不一样）；同样这个参数一般配合worker processes和worker_rlimit_nofile这两个参数一块使用；如果你的服务器为8核，开启worker进程数为6个，那么就是6X512等于worker_rlimit_nofile的值。如果你想让服务器并发20000个请求，那么20000%6等worker_processes的值，当然worker_rlimit_nofile的值也必须要大于20000才有效。同时并发连接要根据CPU及内存的大小来决定，不能盲目设定。
并且经过测试，此最大连接数越多，Nginx占用内存越大，单个进程最大连接数为1024时启动Nginx占用内存为8M左右，当你把并发连接调整为10万时，每个进程占用内存为50M左右。
2）use
|
1 2 3 |
Syntax: use method; Default:— Context:events |
定义nginx以何种方式响应客户端连接请求，也就是定义使用的事件驱动模型。一般使用use epoll模型，如果epoll不可用，nginx就会退而求此次选项poll和select模型，但效率远不及epoll模型。关于事件驱动模型可以好好看看Linux的IO模型。
3）accept_mutex
|
1 2 3 |
Syntax: accept_mutex on | off; Default:accept_mutex on; Context:events |
互斥锁，就是各个worker接受用户请求的负载均衡锁，默认启用，表示让各个worker轮流地，序列化地响应用户请求；如果关闭那么所有的worker进程都会接收一个新的请求，如果连接数量不高的情况下，这么做只是会浪费系统资源。
4）lock_file
|
1 2 3 |
Syntax: lock_file file; Default:lock_file logs/nginx.lock; Context:main |
既然启动了负载均衡锁，那么就需要指定一个锁文件了。nginx使用锁机制来实现accept_mutex和序列化访问共享内存。
5）multi_accept
|
1 2 3 |
Syntax: multi_accept on | off; Default:multi_accept off; Context:events |
设置是否允许同时接收多个网络连接，每个nginx服务器的worker进程都有能力同时接收多个新到达的网络连接。但是默认是关闭的，使用序列化的方式处理请求。
关于核心功能更多配置指令可参考：Nginx Core functionality
