优雅关闭上一小节，我们讲到了关于nginx是如何工作的，本小节我们将讲到关于nginx主配置文件（nginx.conf）相关的配置语法进行相关说明
1.用于调试进程和定位问题的配置项
1.1关于nginx的守护进程
| 语法:daemon on | off; | 是否以守护进程运行nginx 默认值:daemon on; |
守护进程（daemon）是脱离终端并且在后台运行的进程。它脱离终端是为了避免进程执行过程中的信息在任何终端上显示，这样一来，进程也不会被任何终端所产生的信息所打断。Nginx毫无疑问是一个需要以守护进程方式运行的服务，因此，默认都是以这种方式运行的。
不过Nginx还是提供了关闭守护进程的模式，之所以提供这种模式，是为了方便跟踪调试Nginx，毕竟用gdb调试进程时最烦琐的就是如何继续跟进fork出的子进程了。
1.2关于nginx的工作方式
| 语法：master_process on | off; | 是否以master/worker方式工作，默认：master_process on; |
可以看到，nginx是以一个master进程管理多个worker进程的方式运行的，几乎所有的环境下，Nginx都以这种方式工作。
与daemon配置相同，提供master_process配置也是为了方便跟踪调试Nginx。如果用off关闭了master_process方式，就不会fork出worker子进程来处理请求，而是用master进程自身来处理请求。
1.3关于nginx的error日志的设置
| 语法：error_log /path/file level; | 默认：error_log logs/error.log error; |
error日志是定位Nginx问题的最佳工具，我们可以根据自己的需求妥善设置error日志的路径和级别。
/path/file参数可以是一个具体的文件，例如，默认情况下是logs/error.log文件，最好将它放到一个磁盘空间足够大的位置；/path/file也可以是/dev/null，这样就不会输出任何日志了，这也是关闭error日志的唯一手段；/path/file也可以是stderr，这样日志会输出到标准错误文件中。
level是日志的输出级别，取值范围是debug、info、notice、warn、error、crit、alert、emerg，从左至右级别依次增大。当设定为一个级别时，大于或等于该级别的日志都会被输出到/path/file文件中，小于该级别的日志则不会输出。例如，当设定为error级别时，error、crit、alert、emerg级别的日志都会输出。
如果设定的日志级别是debug，则会输出所有的日志，这样数据量会很大，需要预先确保/path/file所在磁盘有足够的磁盘空间。
注意 如果日志级别设定到debug，必须在configure时加入--with-debug配置项。
1.4关于nginx是否处理几个特殊的调试点
| 语法：debug_points [stop | abort] | 默认值stop |
这个配置项也是用来帮助用户跟踪调试Nginx的。它接受两个参数：stop和abort。Nginx在一些关键的错误逻辑（Nginx 1.0.14版本中有8处）设置了调试点。如果设置了debug_points为stop，那么Nginx的代码执行到这些调试点时就会发出SIGSTOP信号以用于调试。如果debug_points设置为abort，则会产生一个coredump文件，可以使用gdb来查看Nginx当时的各种信息。
通常不会使用这个配置项。
1.5 关于nginx仅对指定的客户端输出debug级别的日志
语法：debug_connection [IP | CIDR]
这个配置项实际上属于事件类配置，因此，它必须放在events {...}中才有效。它的值可以是IP地址或CIDR地址，例如：
events {
debug_connection 10.224.66.14;
debug_connection 10.224.57.0/24;
}
这样，仅仅来自以上IP地址的请求才会输出debug级别的日志，其他请求仍然沿用error_log中配置的日志级别。上面这个配置对修复Bug很有用，特别是定位高并发请求下才会发生的问题。
注意 使用debug_connection前，需确保在执行configure时已经加入了--with-debug参数，否则不会生效。
1.6 关于nginx限制coredump核心转储文件的大小
语法：worker_rlimit_core size;
在Linux系统中，当进程发生错误或收到信号而终止时，系统会将进程执行时的内存内容（核心映像）写入一个文件（core文件），以作为调试之用，这就是所谓的核心转储（core dumps）。当Nginx进程出现一些非法操作（如内存越界）导致进程直接被操作系统强制结束时，会生成核心转储core文件，可以从core文件获取当时的堆栈、寄存器等信息，从而帮助我们定位问题。但这种core文件中的许多信息不一定是用户需要的，如果不加以限制，那么可能一个core文件会达到几GB，这样随便coredumps几次就会把磁盘占满，引发严重问题。通过worker_rlimit_core配置可以限制core文件的大小，从而有效帮助用户定位问题。
1.7 关于nginx定coredump文件生成目录
worker进程的工作目录。这个配置项的唯一用途就是设置coredump文件所放置的目录，协助定位问题。因此，需确保worker进程有权限向working_directory指定的目录中写入文件。
2.用于正常运行的配置项
2.1 关于nginx嵌入其他配置文件
| 语法：include /path/file; | 用于包含其他的配置文件 |
include配置项可以将其他配置文件嵌入到当前的nginx.conf文件中，它的参数既可以是绝对路径，也可以是相对路径(相对于Nginx的配置目录，即nginx.conf所在的目录），例如：
include mime.types;
include vhost/*.conf;
可以看到，参数的值可以是一个明确的文件名，也可以是含有通配符*的文件名，同时可以一次嵌入多个配置文件。
2.2 关于nginx pid文件的路径设置
| 语法：pid path/file; | 默认：pid logs/nginx.pid; |
保存master进程ID的pid文件存放路径。默认与configure执行时的参数“--pid-path”所指定的路径是相同的，也可以随时修改，但应确保Nginx有权在相应的目标中创建pid文件，该文件直接影响Nginx是否可以运行。
2.3 关于nginx服务运行用户设置
| 语法：user username [groupname]; | 默认：user nobody nobody; |
user用于设置master进程启动后，fork出的worker进程运行在哪个用户和用户组下。当按照“user username;”设置时，用户组名与用户名相同。
若用户在configure命令执行时使用了参数--user=username和--group=groupname，此时nginx.conf将使用参数中指定的用户和用户组。
2.4 关于nginx worker进程可以打开的最大句柄描述符个数
| 语法：worker_rlimit_nofile limit; | 通常值:102400 | 设置一个worker进程可以打开的最大文件句柄数。 |
注：以上选项的参数值牵扯到nginx的并发连接数
2.5 关于nginx 限制信号队列
语法：worker_rlimit_sigpending limit;
设置每个用户发往Nginx的信号队列的大小。也就是说，当某个用户的信号队列满了，这个用户再发送的信号量会被丢掉。
3.用于优化性能的配置项
3.1 关于nginx worker进程个数
| 语法:worker_processes number; | 默认：worker_processes 1; 亦可以设置为:auto |
在master/worker运行方式下，定义worker进程的个数。
worker进程的数量会直接影响性能。那么，用户配置多少个worker进程才好呢？这实际上与业务需求有关。每个worker进程都是单线程的进程，它们会调用各个模块以实现多种多样的功能。如果这些模块确认不会出现阻塞式的调用，那么，有多少CPU内核就应该配置多少个进程；反之，如果有可能出现阻塞式调用，那么需要配置稍多一些的worker进程。
例如，如果业务方面会致使用户请求大量读取本地磁盘上的静态资源文件，而且服务器上的内存较小，以至于大部分的请求访问静态资源文件时都必须读取磁盘（磁头的寻址是缓慢的），而不是内存中的磁盘缓存，那么磁盘I/O调用可能会阻塞住worker进程少量时间，进而导致服务整体性能下降。
多worker进程可以充分利用多核系统架构，但若worker进程的数量多于CPU内核数，那么会增大进程间切换带来的消耗（Linux是抢占式内核）。一般情况下，用户要配置与CPU内核数相等的worker进程，并且使用下面的worker_cpu_affinity配置来绑定CPU内核。
3.2 关于nginx绑定worker进程到指定的CPU内核
语法：worker_cpu_affinity cpumask [cpumask...]
为什么要绑定worker进程到指定的CPU内核呢？假定每一个worker进程都是非常繁忙的，如果多个worker进程都在抢同一个CPU，那么这就会出现同步问题。反之，如果每一个worker进程都独享一个CPU，就在内核的调度策略上实现了完全的并发。
例如，如果有4颗CPU内核(4核心)，就可以进行如下配置：
worker_processes 4;
worker_cpu_affinity 1000 0100 0010 0001;
注意 worker_cpu_affinity配置仅对Linux操作系统有效。Linux操作系统使用sched_setaffinity()系统调用实现这个功能。
4.用于事件类配置项
4.1 关于nginx是否打开accept锁
| 语法：accept_mutex [on | off] | 默认：accept_mutext on; |
accept_mutex是Nginx的负载均衡锁，本书会在第9章事件处理框架中详述Nginx是如何实现负载均衡的。这里，读者仅需要知道accept_mutex这把锁可以让多个worker进程轮流地、序列化地与新的客户端建立TCP连接。当某一个worker进程建立的连接数量达到worker_connections配置的最大连接数的7/8时，会大大地减小该worker进程试图建立新TCP连接的机会，以此实现所有worker进程之上处理的客户端请求数尽量接近。
accept锁默认是打开的，如果关闭它，那么建立TCP连接的耗时会更短，但worker进程之间的负载会非常不均衡，因此不建议关闭它。
4.2 关于nginx设置lock文件的路径
| 语法：lock_file path/file; | 默认：lock_file logs/nginx.lock; |
accept锁可能需要这个lock文件，如果accept锁关闭，lock_file配置完全不生效。如果打开了accept锁，并且由于编译程序、操作系统架构等因素导致Nginx不支持原子锁，这时才会用文件锁实现accept锁，这样lock_file指定的lock文件才会生效。
注意 在基于i386、AMD64、Sparc64、PPC64体系架构的操作系统上，若使用GCC、Intel C++ 、SunPro C++编译器来编译Nginx，则可以肯定这时的Nginx是支持原子锁的，因为Nginx会利用CPU的特性并用汇编语言来实现它。这时的lock_file配置是没有意义的。
4.3 关于nginx设置使用accept锁后到真正建立连接之间的延迟时间
| 语法：accept_mutex_delay Nms; | 默认：accept_mutex_delay 500ms; |
在使用accept锁后，同一时间只有一个worker进程能够取到accept锁。这个accept锁不是阻塞锁，如果取不到会立刻返回。如果有一个worker进程试图取accept锁而没有取到，它至少要等accept_mutex_delay定义的时间间隔后才能再次试图取锁。
4.4 关于nginx设置批量建立新连接
| 语法：multi_accept [ on | off ]; | 默认：multi_accept off; |
当事件模型通知有新连接时，尽可能地对本次调度中客户端发起的所有TCP请求都建立连接。
4.5 关于nginx选择事件模型
语法：use [ kqueue | rtsig | epoll | /dev/poll | select | poll | eventport ];
默认：Nginx会自动使用最适合的事件模型。
对于Linux操作系统来说，可供选择的事件驱动模型有poll、select、epoll三种。epoll当然是性能最高的一种。
4.6 关于nginx设置每个worker的最大连接数
语法：worker_connections number;
定义每个worker进程可以同时处理的最大连接数。该选项值与打开最大的文件句柄数：worker_rlimit_nofile相关
到这里关于nginx主配置文件中一些关于常规配置语法介绍就到这里，下一小节将介绍到关于nginx中一些网络设置，文件优化等配置语法介绍