第二章Nginx配置

​这一章主要学习如图所示的四个模块功能

一、模块管理

    Nginx采用模块化设计，模块一旦编译进来就不可能被卸载，如果有特别的需求，就只能重新编译Nginx了。

    Nginx提供了core、event、http、mail和misc（杂项）五类模块，而每一类模块根据需要又有多种模块，这五类模块只有core不能被禁用，其它模块可以根据实际情况选择。

    使用./configure  --help命令了解默认安装和默认不安装模块的信息。

    

    在这个信息中，--with-XXX表示启用，而--without-XX表示禁用，在这里，所有的--with-XXX模块在默认安装时都没有安装，--without-XX的模块则是在默认安装中被选中的模块。既有--with-XXX，也有--without-XX标识的，那么这个选择就不是我们选择的了，是安装时，根据操作习题情况来自行决定的了。

    如何使用第三方模块呢？在对Nginx进行configure的时候，有一个参数--add-module，就是用来添加第三方模块的，例如：--add-module=/root/nginx-accesskey-2.0.3。

二、进程管理

    Nginx分为Single和Master两种进程模块，Single即为单线程方式工作，通过ngx_single_process_cycle完成；Master即为一个master进程+n个worker进程的工作方式，通过ngx_master_process_cycle完成。

    1、master进程和worker进程

    每一个worker进程都很繁忙，他们在真正的提供互联网服务，master则很清闲，只负责监控、管理worker进程。

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

    

    多个worker管理进程处理互联网请求不但可以提高服务器性能，而且可以实现微观上真正的多核并发。

    

    2、关于worker数目设置

    一般情况下，worker进程的数量与服务器上的CPU核心数相等。这是为什么呢？这证书nginx与apache的不同之处。在apache上每个进程在同一时刻只能处理一个请求，因此，如果需要web服务器拥有并发处理的请求书更多，就要把apache的进程或线程数设置的更多，通常会达到一台服务器拥有几百个工作进程，这样大量的进程切换将带来无畏的系统资源消耗。而Nginx则不同，一个进程可以同时处理的请求数只受限于内存的大小，而且在架构设计上，不同的worker进程间处理并发请求时几乎没有同步锁的限制，worker进程通常不会进入睡眠状态，因此，当Nginx上的进程数与cpu核数相等时（最好每个worker都绑定指定的cpu），进程间切换的代价是最小的。

三、反向代理

    反向代理方式是指用代理服务器来接受Internet上的链接请求，然后将请求转发给内部网络中的上游服务器，并将从上游服务器上得到的结果返回给Internet上请求连接的客户端，此时代理服务器对外表现就是一个web服务器。

    

四、通用配置语法

    1、块配置项

    块配置项是由配置项名称和一个大括号组成的：

    events {…

    } 

    http {    

        upstream backend {           

                server 127.0.0.1:8080;    

        }    

        gzip on;    

        server {           …

               location /webstatic {                        

                    gzip off;          

                }    

        } 

    }

    下面解释一下配置项的构成部分。

    首先，在行首的是配置项名，这些配置项名必须是Nginx的某一个模块想要处理的，否则Nginx会认为配置文件出现了非法的配置项名。配置项名输入结束后，将以空格作为分隔符。

    其次是配置项值，它可以是数字或字符串（当然也包括正则表达式）。针对一个配置项，既可以只有一个值，也可以包含多个值，配置项值之间仍然由空格符来分隔。当然，一 个配置项对应的值究竟有多少个，取决于解析这个配置项的模块。我们必须根据某个Nginx 模块对一个配置项的约定来更改配置项。

    最后，每行配置的结尾需要加上分号。

    注意 　如果配置项值中包括语法符号，比如空格符，那么需要使用单引号或双引号 括住配置项值，否则Nginx会报语法错误。例如：

log_format  main  '$remote_addr - $remote_user [$time_local] "$request" ';

    2、配置项注解

    如果有一个配置项暂时需要注释掉，那么可以加“#”注释掉这一行配置。

    3、在配置中使用变量

    例如：log_format  main  '$remote_addr - $remote_user [$time_local] "$request" ';其中，remote_addr是一个变量，使用它的时候前面要加上$符号。需要注意的是，这种变量只有少数模块支持，并不是通用的。

    4、提示 　在执行configure命令时，我们已经把许多模块编译进Nginx中，但是否启用这 些模块，一般取决于配置文件中相应的配置项。换句话说，每个Nginx模块都有自己感兴趣 的配置项，大部分模块都必须在nginx.conf中读取某个配置项后才会在运行时启用。例如，只 有当配置http{...}这个配置项时，ngx_http_module模块才会在Nginx中启用，其他依赖 ngx_http_module的模块也才能正常使用。

    5、Nginx服务的基本配置

    Nginx配置项较多，我们根据用户使用的语气功能将其分为以下四类

•     用于调试定位的配置项
  

•     正常运行必备配置项
  

•     优化性能配置项
  

•     事件类配置项

现在针对比较常用的配置项做一些梳理，具体详细的可以再参考相关书籍，或者网上查找。

•     用于调试定位的配置项

（1）是否以守护进程方式运行Nginx

        语法： daemon on|off;

        默认： daemon on;

        守护进程（daemon）是脱离终端并且在后台运行的进程。它脱离终端是为了避免进程执行过程中的信息在任何终端上显示，这样一来，进程也不会被任何终端所产生的信息所打 断。Nginx毫无疑问是一个需要以守护进程方式运行的服务，因此，默认都是以这种方式运行的。

        不过Nginx还是提供了关闭守护进程的模式，之所以提供这种模式，是为了方便跟踪调 试Nginx，毕竟用gdb调试进程时最烦琐的就是如何继续跟进fork出的子进程了。这在第三部 分研究Nginx架构时很有用。

（2）是否以master/worker方式工作

        语法： master_process on|off;

        默认： master_process on;

        可以看到，在如图2-1所示的产品环境中，是以一个master进程管理多个worker进程的方 式运行的，几乎所有的产品环境下，Nginx都以这种方式工作。与daemon配置相同，提供master_process配置也是为了方便跟踪调试Nginx。如果用off关 闭了master_process方式，就不会fork出worker子进程来处理请求，而是用master进程自身来处理请求。

（3）error日志的设置

        语法： error_logpathfile level;

        默认： error_log logs/error.log error;

        error日志是定位Nginx问题的最佳工具，我们可以根据自己的需求妥善设置error日志的路径和级别。pathfile参数可以是一个具体的文件，例如，默认情况下是logs/error.log文件，最好将它 放到一个磁盘空间足够大的位置；pathfile也可以是/dev/null，这样就不会输出任何日志了， 这也是关闭error日志的唯一手段；pathfile也可以是stderr，这样日志会输出到标准错误文件中。

        level是日志的输出级别，取值范围是debug、info、notice、warn、error、crit、alert、 emerg，从左至右级别依次增大。当设定为一个级别时，大于或等于该级别的日志都会被输 出到pathfile文件中，小于该级别的日志则不会输出。例如，当设定为error级别时，error、 crit、alert、emerg级别的日志都会输出。

如果设定的日志级别是debug，则会输出所有的日志，这样数据量会很大，需要预先确 保pathfile所在磁盘有足够的磁盘空间。

         注意 　如果日志级别设定到debug，必须在configure时加入--with-debug配置项。

• 正常运行必备配置项

（1）定义环境变量

        语法： env VAR|VAR=VALUE

        这个配置项可以让用户直接设置操作系统上的环境变量。例如：env TESTPATH=/tmp/;

（2）嵌入其他配置文件

        语法： includepathfile;

        include配置项可以将其他配置文件嵌入到当前的nginx.conf文件中，它的参数既可以是绝 对路径，也可以是相对路径（相对于Nginx的配置目录，即nginx.conf所在的目录），例如：include mime.types; include vhost/*.conf;

可以看到，参数的值可以是一个明确的文件名，也可以是含有通配符*的文件名，同时可以一次嵌入多个配置文件。

（3）pid文件的路径

        语法： pid path/file;

        默认： pid logs/nginx.pid;

        保存master进程ID的pid文件存放路径。默认与configure执行时的参数“--pid-path”所指定 的路径是相同的，也可以随时修改，但应确保Nginx有权在相应的目标中创建pid文件，该文 件直接影响Nginx是否可以运行。

（4）Nginx worker进程运行的用户及用户组

        语法： user username[groupname];

        默认： user nobody nobody;

        user用于设置master进程启动后，fork出的worker进程运行在哪个用户和用户组下。当按 照“user username;”设置时，用户组名与用户名相同。若用户在configure命令执行时使用了参数--user=username和--group=groupname，此时 nginx.conf将使用参数中指定的用户和用户组。

（5）指定Nginx worker进程可以打开的最大句柄描述符个数

        语法： worker_rlimit_nofile limit;

        设置一个worker进程可以打开的最大文件句柄数。

（6）限制信号队列

        语法： worker_rlimit_sigpending limit;

        设置每个用户发往Nginx的信号队列的大小。也就是说，当某个用户的信号队列满了，这个用户再发送的信号量会被丢掉。

• 优化性能配置项

（1）Nginx worker进程个数

        语法： worker_processes number;

        默认： worker_processes 1;

        在master/worker运行方式下，定义worker进程的个数。worker进程的数量会直接影响性能。那么，用户配置多少个worker进程才好呢？这实际上与业务需求有关。每个worker进程都是单线程的进程，它们会调用各个模块以实现多种多样的功能。如果 这些模块确认不会出现阻塞式的调用，那么，有多少CPU内核就应该配置多少个进程；反 之，如果有可能出现阻塞式调用，那么需要配置稍多一些的worker进程。例如，如果业务方面会致使用户请求大量读取本地磁盘上的静态资源文件，而且服务器上的内存较小，以至于大部分的请求访问静态资源文件时都必须读取磁盘（磁头的寻址是缓 慢的），而不是内存中的磁盘缓存，那么磁盘I/O调用可能会阻塞住worker进程少量时间，进而导致服务整体性能下降。多worker进程可以充分利用多核系统架构，但若worker进程的数量多于CPU内核数，那 么会增大进程间切换带来的消耗（Linux是抢占式内核）。一般情况下，用户要配置与CPU内 核数相等的worker进程，并且使用下面的worker_cpu_affinity配置来绑定CPU内核。

（2）绑定Nginx worker进程到指定的CPU内核

        语法： worker_cpu_affinity cpumask[cpumask...]

        为什么要绑定worker进程到指定的CPU内核呢？假定每一个worker进程都是非常繁忙的，如果多个worker进程都在抢同一个CPU，那么这就会出现同步问题。反之，如果每一个 worker进程都独享一个CPU，就在内核的调度策略上实现了完全的并发。

        例如，如果有4颗CPU内核，就可以进行如下配置：

        worker_processes 4; worker_cpu_affinity 1000 0100 0010 0001;

         注意 　worker_cpu_affinity配置仅对Linux操作系统有效。Linux操作系统使用 sched_setaffinity()系统调用实现这个功能。

（3）SSL硬件加速

        语法： ssl_engine device；

        如果服务器上有SSL硬件加速设备，那么就可以进行配置以加快SSL协议的处理速度。 用户可以使用OpenSSL提供的命令来查看是否有SSL硬件加速设备：openssl engine -t

（4）系统调用gettimeofday的执行频率

        语法： timer_resolution t;

        默认情况下，每次内核的事件调用（如epoll、select、poll、kqueue等）返回时，都会执 行一次gettimeofday，实现用内核的时钟来更新Nginx中的缓存时钟。在早期的Linux内核中， gettimeofday的执行代价不小，因为中间有一次内核态到用户态的内存复制。当需要降低 gettimeofday的调用频率时，可以使用timer_resolution配置。例如，“timer_resolution 100ms；”表示至少每100ms才调用一次gettimeofday。但在目前的大多数内核中，如x86-64体系架构，gettimeofday只是一次vsyscall，仅仅对共享内存页中的数据做访问，并不是通常的系统调用，代价并不大，一般不必使用这个配置。而且，如果希望日志文件中每行打印的时间更准确，也可以使用它。

（5）Nginx worker进程优先级设置

        语法： worker_priority nice;

        默认： worker_priority 0;

        该配置项用于设置Nginx worker进程的nice优先级。

        在Linux或其他类UNIX操作系统中，当许多进程都处于可执行状态时，将按照所有进程 的优先级来决定本次内核选择哪一个进程执行。进程所分配的CPU时间片大小也与进程优先级相关，优先级越高，进程分配到的时间片也就越大（例如，在默认配置下，最小的时间片 只有5ms，最大的时间片则有800ms）。这样，优先级高的进程会占有更多的系统资源。优先级由静态优先级和内核根据进程执行情况所做的动态调整（目前只有±5的调整）共 同决定。nice值是进程的静态优先级，它的取值范围是–20~+19，–20是最高优先级，+19是 最低优先级。因此，如果用户希望Nginx占有更多的系统资源，那么可以把nice值配置得更小 一些，但不建议比内核进程的nice值（通常为–5）还要小。

• 事件类配置项

（1）是否打开accept锁

        语法： accept_mutex[on|off]

        默认： accept_mutext on;

        accept_mutex是Nginx的负载均衡锁。这里，读者仅需要知道accept_mutex这把锁可以让多个worker进程轮流地、 序列化地与新的客户端建立TCP连接。当某一个worker进程建立的连接数量达到 worker_connections配置的最大连接数的7/8时，会大大地减小该worker进程试图建立新TCP连 接的机会，以此实现所有worker进程之上处理的客户端请求数尽量接近。accept锁默认是打开的，如果关闭它，那么建立TCP连接的耗时会更短，但worker进程之间的负载会非常不均衡，因此不建议关闭它。

（2）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配置是没有意义的。

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

        语法： accept_mutex_delay Nms;

        默认： accept_mutex_delay 500ms;

        在使用accept锁后，同一时间只有一个worker进程能够取到accept锁。这个accept锁不是 阻塞锁，如果取不到会立刻返回。如果有一个worker进程试图取accept锁而没有取到，它至 少要等accept_mutex_delay定义的时间间隔后才能再次试图取锁。

（4）批量建立新连接

        语法： multi_accept[on|off];

        默认： multi_accept off;

        当事件模型通知有新连接时，尽可能地对本次调度中客户端发起的所有TCP请求都建立连接。

（5）选择事件模型

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

        默认： Nginx会自动使用最适合的事件模型。

        对于Linux操作系统来说，可供选择的事件驱动模型有poll、select、epoll三种。epoll当 然是性能最高的一种，在9.6节会解释epoll为什么可以处理大并发连接。

（6）每个worker的最大连接数

        语法： worker_connections number;

        定义每个worker进程可以同时处理的最大连接数。

 

欢迎关注公众号