Nginx配置入门(二)：Nginx服务的基本配置
Nginx服务的基本配置
Nginx在运行时，至少必须加载一个事件类模块和几个核心类模块。这些模块运行时所支持的配置项成为基本配置。所谓基本配置，就是其他模块执行时都依赖的配置项。
配置项种类繁多，按照用户使用时的预期功能分为以下4类：
- 用于调试、定位问题的配置项。
- 正常运行的必备配置项。
- 优化性能的配置项。
- 事件类配置项。
1 用于调试进程和定位问题的配置项
(1) 是否以守护进程方式运行Nginx
语法 ：daemon on | off;
默认 ：daemon on;
守护进程是脱离终端并在在后台运行的进程。脱离终端是为了避免进程执行过程中的信息在任何终端显示，这样也保证进程不会被任何终端产生的信息所打断。Nginx毫无疑问是一个需要以守护进程方式运行的服务，因此，默认是打开的。
(2) 是否以master/worker方式工作
语法 ：master_process on | off;
默认 ：master_process on;
Nginx是以一个master进程管理多个worker进程的方式运行的，几乎所有的产品环境下，都以这种方式进行工作。关闭仅仅是为了方便调试。
(3) error日志的设置
语法 ：error_log /path/file level;
默认 ：error_log logs/error.log error;
我们可以根据自己的需求来配置error日志的路径和级别，/path/file参数是一个具体文件，默认情况下是logs/error.log，最好将其放在一个空间比较大的位置；/path/file如果是/dev/null，这样就不会输出任何日志了；/path/file也可以是stderr，这样日志就会输出到标准错误文件中。
level是日志输出级别，取值范围是debug、info、notice、warn、error、crit、alert、emerg，从左至右级别依次增大。当设定一个级别时，大于等于该级别的日志都会被输入到/path/file中。
如果日志级别设定成debug，必须在configure时加入 --with-debug配置项。
(4) 是否处理几个特殊的测试点
语法 ：debug_points [stop | abort];
Nginx在一些关键的错误逻辑中设置了调试点。如果设置了debug_points 为stop，那么Nginx代码执行到这些调试点时就会发出SIGSTOP信号以用于调试；如果debug_points 设置为abort，则会产生一个coredump文件，可以使用gdb来查看Nginx当时的各种信息。
通常不会使用这个配置
(5) 仅对指定的客户端输出debug级别的日志
语法 ：debug_connection [IP| CIDR];
这个配置项属于事件类配置，必须放在events块中才有效。举例：
events {
debug_connection 10.224.66.14;
debug_connection 10.224.57.0/24;
}
这样，仅仅是来自以上IP地址的请求才会输出debug级别的日志，其他请求仍然沿用error_log中配置的日志级别。
(6) 限制coredump核心转储文件的大小
语法 ：worker_rlimit_core size;
在Linux系统中，当进程发生错误或收到信号而终止时，系统会将进程执行时的内存内容(核心镜像)写入一个文件(core文件)，以作调试之用，这就是所谓的核心转储。
当Nginx进程出现一些非法操作导致进程直接被操作系统强制结束时，会生成核心转储文件，可以从core文件获取当前的堆栈、寄存器等信息，从而帮助我们解决问题。
但是这种文件比较大，随便发生几次就会将硬盘占满。
(7) 指定coredump文件生成目录
语法 ：working_directory path;
2 正常运行的配置项
(1) 定义环境变量
语法 ：env VAR; env VAR=VALUE;
(2) 嵌入其他配置文件
语法 ：include /path/file;
include配置项可以将其他配置文件嵌入到当前的nginx.conf文件中，它的参数可以是相对路径也可以是绝对路径，例如：
include mime.types;
include vhost/*.conf;
(3) pid文件路径
语法 ：pid path/file;
默认 ：pid logs/nginx.pid;
保存master进程id的pid文件存放路径，该文件直接影响Nginx是否可以运行。
(4) Nginx worker 进程运行的用户及用户组
语法 ：user username [groupname];
默认 ：user nobody nobody;
user用于设置master进程启动后，fork出的worker进程运行在哪个用户和用户组下。若用户在configure命令执行时使用了参数--user=username和--group=groupname，此时nginx.conf将使用参数中指定的用户和用户组。
(5) 指定Nginx worker进程可以打开的最大句柄描述符个数
语法 ：worker_rlimit_nofile limit;
(6) 限制信号队列
语法 ：worker_rlimit_sigpending limit;
设置每个用户发送Nginx的信号队列的大小。当某个用户的信号队列满了，这个用户再发送的信号量会被丢掉。
3 优化性能的配置项
(1) Nginx worker进程个数
语法 ：work_processes number;
默认 ：work_processes 1;
work进程的数量会直接影响性能。每个worker都是单线程的进程，它们会调用各个模块以实现多种多样的功能。如果这些模块确认不会出现阻塞式调用，那么，有多少个CPU内核就应该配置多少个worker进程；反之，如果有可能出现阻塞式调用，那么需要配置稍多一些的worker进程。
多worker进程可以充分利用多核系统结构，但若worker进程的数量多于CPU内核，那么会增大进程间切换带来的消耗。一般情况下，用户要配置与CPU内核数相等的worker进程，并且配合worker_cpu_affinity配置来绑定CPU内核。
(2) 绑定Nginx worker进程到指定CPU内核
语法 ：worker_cpu_affinity cpumask [cpumask...];
4核CPU配置举例：
worker_processes 4;
worker_cpu_affinity 1000 0100 0010 0001;
worker_cpu_affinity 配置仅对Linux操作系统有效
(3) SSL硬件加速
语法 ：ssl_engine device;
(4) 系统调用gettimeofday的执行频率
语法 ：time_resolution t;
早期内核中，每次内核的事件调用返回时，都会执行一次gettimeofday，实现用内核时钟来更新Nginx中的缓存时钟。而执行gettimeofday有一次内核态到用户态的内存复制，是有代价的。使用time_resolution 100ms 表示至少100ms才调用一次gettimeofday。
而在目前的大多数内核中，gettimeofday只是一次vsyscall，仅仅对共享内存中的数据做访问，并不是通常的系统调用，代价并不大，一般不需要此配置。
(5) Nginx worker进程优先级配置
语法 ：worker_priority nice;
默认 ：worker_priority 0;
在Linux操作系统中，当许多进程都处于可执行状态时，将按照所有进程的优先级来决定内次内核选择哪一个进行执行。进程所分配的CPU时间片大小也与进程优先级相关。优先级高的进程会占有更多的系统资源。
nice值的取值范围是[-20,+19]，如果希望Nginx占有更多的系统资源，那么可以把nice值设置得小一点，但不建议比内核进程的nice值还要小。
4 事件类配置项
(1) 是否打开accept锁
语法 ：accept_mutex [on | off];
默认 ：accept_mutex on ;
accept_mutex 是Nginx的负载均衡锁。这把锁可以让多个worker进程轮流地、序列化地与新客户端建立TCP连接。默认是打开的，如果关闭它，那么建立TCP连接的耗时会更短，但worker进程之间的负载会非常不均衡，因此不建议关闭。
(2) lock文件的路径
语法 ：lock_file path/file;
默认 ：lock_file logs/nginx.lock;
accept锁可能需要这个lock文件。如果accept锁关闭，lock_file配置完全不生效。如果打开了accept锁，并且由于编译程序、操作系统架构等因素导致Nginx不支持原子锁，这是才会用文件锁实现accept锁，这样lock_file指定的lock文件才会生效。
(3) 使用accept锁后到真正建立连接之间的延迟时间
语法 ：accept_mutex_delay Nms;
默认 ：accept_mutex_delay 500ms;
accept锁打开后，同一时间只能有一个worker进程获取到accept锁。这个锁不是阻塞锁，如果取不到会立刻返回。如果一个worker进程试图取accept锁而没有取到，它至少等待accept_mutex_delay定义的时间后才能再次试图取锁。
(4) 批量建立新连接
语法 ：multi_accept [on | off];
默认 ：multi_accept off;
(5) 选择事件模型
语法 ：use [kqueue | rtsig | epoll | /dev/poll | select | poll | eventport];
默认 ：Nginx会自动使用最适合的事件模型
(6) 每个worker的最大连接数
语法 ：work_connections number;
定义每个worker进程可以同时处理的最大连接数。
