深入理解Nginx-第2章 - Nginx的配置 - 一

2.1 运行中的Nginx进程间的关系      

        Nginx 是使用一个 master 进程来管理多个worker 进程提供服务。master 负责管理 worker 进程，而 worker 进程则提供真正的客户服务，worker 进程的数量一般跟服务器上 CPU 的核心数相同，worker 进程之间通过一些进程间通信机制实现负载均衡等功能。Nginx 进程之间的关系可由下图表示： 

      

（1）      master进程不会对用户请求提供服务，只用于管理真正提供服务的worker进程，所以master进程是唯一的，它仅专注于自己的纯管理工作，为管理员提供命令行服务，包括诸如启动，停止服务、重载配置文件、平滑升级程序等。master进程需要拥有较大的权限。

（2）      多个worker进程处理互联网请求不但可以提高服务的健壮性（一个worker进程出错后，其他worker进程仍然可以正常提供服务），更重要的是，这样可以充分利用现在常见的SMP多核架构，从而实现微观上真正的多核并发处理。

        为什么要把worker进程数量设置得与CPU核心数量一致呢？这正是Nginx与Apache服务器不同之处。在Apache上每个进程在同一时刻只处理一个请求，而Nginx则不然，一个worker进程可以同时处理的请求数只受限于内存大小，而且在架构设计上，不同的worker进程之间处理并发请求时几乎没有同步锁的限制，worker进程通常不会进入睡眠状态。因此，当Nginx上的进程数与CPU核心数相等时，进程间切换的代价是最小的。

2.2 Nginx配置的通用语法

        Nginx 服务启动时会读入配置文件，后续的行为则按照配置文件中的指令进行。Nginx 的配置文件是纯文本文件，默认安装 Nginx 后，其配置文件均在 /usr/local/nginx/conf/ 目录下。其中，nginx.conf 为主配置文件。配置文件中以 # 开始的行，或者是前面有若干空格或者 TAB 键，然后再跟 # 的行，都被认为是注释。这里只是了解主配置文件的结构。

[root@chenchen ~]# cat/usr/local/nginx/conf/nginx.conf #user nobody;worker_processes  1; #error_log logs/error.log;#error_log logs/error.log  notice;#error_log logs/error.log  info; #pid       logs/nginx.pid;  events {   worker_connections  1024;}  http {   include       mime.types;   default_type application/octet-stream;    #log_format  main  '$remote_addr - $remote_user [$time_local]"$request" '   #                  '$status$body_bytes_sent "$http_referer" '   #                 '"$http_user_agent" "$http_x_forwarded_for"';    #access_log  logs/access.log  main;    sendfile        on;   #tcp_nopush     on;    #keepalive_timeout  0;keepalive_timeout  65;……}

2.2.1 块配置项

        Nginx 配置文件是以 block（块）形式组织，每个block 都是以一个块名字和一对大括号 “{}” 表示组成，block 分为几个层级，整个配置文件为 main 层级，即最大的层级；在 main 层级下可以有 event、http 、mail 等层级，而 http 中又会有 server block，server block中可以包含 location block。即块之间是可以嵌套的，内层块继承外层块。

2.2.2 配置项的语法格式

       最基本的配置项语法格式是“配置项名  配置项值1  配置项值2  配置项值3 ... ”；

        每个层级可以有自己的指令（Directive），例如worker_processes 是一个main层级指令，它指定 Nginx 服务的worker 进程数量。有的指令只能在一个层级中配置，如worker_processes 只能存在于 main 中，而有的指令可以存在于多个层级，在这种情况下，子 block 会继承父 block 的配置，同时如果子block配置了与父block不同的指令，则会覆盖掉父 block 的配置。指令的格式是“指令名参数1 参数2 … 参数N;”，注意参数间可用任意数量空格分隔，最后要加分号。

        下图是 Nginx 配置文件通常结构图示。

2.3 Nginx 服务的基本配置项

        Nginx 服务运行时，需要加载几个核心模块和一个事件模块，这些模块运行时所支持的配置项称为基本配置；基本配置项大概可分为以下四类：

（1）          用于调试、定位的配置项；

（2）          正常运行的必备配置项；

（3）          优化性能的配置项；

（4）          事件类配置项；

2.3.1  用于调试进程和定位问题的配置项  

/* Nginx 服务基本配置项 */    

#以守护进程 方式运行Nginx   #语法：daemon off | on;  #默认：daemon on;     守护进程（daemon）是脱离终端并且在后台运行的进程。提供关闭守护进程模式的目的是为了方便跟踪调试Nginx。

#master / worker 工作方式  #语法：master_process on | off;  #默认：master_process on;  

#error 日志设置  #                   路径        错误级别  #语法：error_log    /path/file  level;  #默认：error_log    logs/error.log  error;  #其中/path/file是一个具体文件；level是日志的输出级别，其取值如下：  #   debug info notice warn error crit alert emerg  #从左至右级别增大；若设定一个级别后，则在输出的日志文件中只输出级别大于或等于已设定的级别；  

#处理特殊调试点  #语法：debug_points [stop | abort]  #这个设置是来跟踪调试 Nginx 的；  

#仅对指定的客户端输出 debug 级别的日志  #语法：debug_connection [IP | DIR]  

#限制 coredump 核心转储文件的大小  #语法：worker_rlimit_core   size;  在Linux系统中，当进程发生错误或收到信号而终止时，系统会将进程执行时的内存内容写入一个文件（core文件），以作为调试之用，即核心转储（core dumps）。可以从core文件获取当时的堆栈，寄存器信息等，帮助我们定位问题。但这种core文件如果不加以限制，可能达到几个G，会浪费磁盘，通过worker_rlimit_core可以限制core文件的大小。

#指定 coredump 文件的生成目录  #语法：working_directory    path;  

2.3.2  正常运行的配置项   

  #定义环境变量  ，可以让用户直接设置操作系统上的环境变量#语法：env  VAR | VAR=VALUE;  #VAR 是变量名，VALUE 是目录；

#嵌入其他配置文件  #语法：include  /path/file;  #include 配置项可以将其他配置文件嵌入到 Nginx 的 nginx.conf 文件中，不加path的话，指的是相对路径，相对于Nginx.conf所在的目录；  

#pid 的文件路径  #语法：pid  path/file;  #默认：pid  logs/nginx.pid;  #保存 master 进程 ID 的 pid 文件存放路径；

#Nginx worker 运行的用户及用户组  ，设置master进程启动以后，fork出的worker进程运行在哪个用户和用户组下。#语法：user username    [groupname];  #默认：user nobody nobody;  

#指定 Nginx worker进程可打开最大句柄个数  #语法：worker_rlimit_nofile limit;  

#限制信号队列  #语法：worker_rlimit_sigpending limit;  #设置每个用户发给 Nginx 的信号队列大小，超出则丢弃；  

2.3.3  优化性能配置项 

  #Nginx worker 进程的个数  #语法：worker_process   number;  #默认：worker_process   1;  

           worker进程的数量会直接影响性能。配置多少个worker与业务需求有关。

           每个worker进程都是单线程的进程，它们会调用各个模块实现多种多样的功能。如果这些模块确认不会出现阻塞式的调用，那么有多少CPU内核就应该配置多少个进程；反之，如果有可能出现阻塞式调用，那么需要配置稍多一些的worker进程。多worker进程可以充分利用多核系统构架，但若worker进程的数量多于CPU内核数，会增大进程间切换带来的消耗。

 

#绑定 Nginx worker 进程到指定的 CPU 内核  ，每个worker进程独享一个CPU，就可以在内核的调度策略上实现了完全的并发。（仅对linux系统有效）#语法：worker_cpu_affinity  cpumask [cpumask...]  

#SSL 硬件加速  （服务器如果有SSL硬件加速设备，可以配置以加快SSL协议的处理速度）#语法：ssl_engine   device;  

#系统调用 gettimeofday 的执行频率  #语法：timer_resolution t;  

#Nginx worker 进程优先级设置  #语法：worker_priority  nice;  #默认：worker_priority  0;  

2.3.4  事件类配置项  

#一般有以下几种配置：  #1、是否打开accept锁  （负载均衡锁，可以让多个worker进程轮流地、序列化地与新的客户端建立TCP连接，如果关闭，则建立TCP连接的耗时会更短，但worker进程之间的负载会非常不均衡）#   语法格式：accept_mutex [on | off];  

#2、lock文件的路径  #   语法格式：lock_file  path/file;  

#3、使用accept锁后到真正建立连接之间的延迟时间 （这个锁是非阻塞锁，即如果取不到则立即返回，至少要等Nms时才能再次试图取锁）。 #   语法格式：accept_mutex_delay Nms; 

#4、批量建立新连接  #   语法格式：multi_accept [on | off];  

#5、选择事件模型  （Linux的事件驱动模型有poll、select、epoll，其中epoll性能最高）#   语法格式：use [kqueue | rtisg | epoll | /dev/poll | select | poll | eventport];  

#6、每个worker进程可以同时处理的最大连接数  #   语法格式：worker_connections number;