1、块配置项
块配置项由一个块配置项名和一对大括号组成。具体示例如下:
events {
…
}
http {
upstream backend {
server 127.0.0.1:8080;
}
gzip on;
server {
…
location /webstatic {
gzip off;
}
}
}
上面代码段中的events、http、server、location、upstream等都是块配置项,块配置项之后是否如“location /webstatic {...}”那样在后面加上参数,取决于解析这个块配置项的模块,不能一概而论,但块配置项一定会用大括号把一系列所属的配置项全包含进来,表示大括号内的配置项同时生效。所有的事件类配置都要在events块中,http、server等配置也遵循这个规定。
块配置项可以嵌套。内层块直接继承外层块,例如,上例中,server块里的任意配置都是基于http块里的已有配置的。当内外层块中的配置发生冲突时,究竟是以内层块还是外层块的配置为准,取决于解析这个配置项的模块,第4章将会介绍http块内配置项冲突的处理方法。例如,上例在http模块中已经打开了“gzip on;”,但其下的location/webstatic又把gzip关闭了:gzip off;,最终,在/webstatic的处理模块中,gzip模块是按照gzip off来处理请求的。
2.2.2 配置项的语法格式
从上文的示例可以看出,最基本的配置项语法格式如下:
配置项名 配置项值1 配置项值2 … ;
下面解释一下配置项的构成部分。
首先,在行首的是配置项名,这些配置项名必须是Nginx的某一个模块想要处理的,否则Nginx会认为配置文件出现了非法的配置项名。配置项名输入结束后,将以空格作为分隔符。
其次是配置项值,它可以是数字或字符串(当然也包括正则表达式)。针对一个配置项,既可以只有一个值,也可以包含多个值,配置项值之间仍然由空格符来分隔。当然,一个配置项对应的值究竟有多少个,取决于解析这个配置项的模块。我们必须根据某个Nginx 模块对一个配置项的约定来更改配置项,第4章将会介绍模块是如何约定一个配置项的格式。
最后,每行配置的结尾需要加上分号。
注意 如果配置项值中包括语法符号,比如空格符,那么需要使用单引号或双引号括住配置项值,否则Nginx会报语法错误。例如:
log_format main '$remote_addr - $remote_user [$time_local] "$request" ';
2.2.3 配置项的注释
如果有一个配置项暂时需要注释掉,那么可以加“#”注释掉这一行配置。例如:#pid logs/nginx.pid;
2.2.4 配置项的单位
大部分模块遵循一些通用的规定,如指定空间大小时不用每次都定义到字节、指定时间时不用精确到毫秒。
当指定空间大小时,可以使用的单位包括:
K或者k千字节(KiloByte,KB)。
M或者m兆字节(MegaByte,MB)。
例如:
gzip_buffers 4 8k;
client_max_body_size 64M;
当指定时间时,可以使用的单位包括:
ms(毫秒),s(秒),m(分钟),h(小时),d(天),w(周,包含7天),M(月,包含30天),y(年,包含365天)。
例如:
expires 10y;
proxy_read_timeout 600;
client_body_timeout 2m;
注意 配置项后的值究竟是否可以使用这些单位,取决于解析该配置项的模块。如果这个模块使用了Nginx框架提供的相应解析配置项方法,那么配置项值才可以携带单位。第4章中详细描述了Nginx框架提供的14种预设解析方法,其中一些方法将可以解析以上列出的单位。
2.2.5 在配置中使用变量
有些模块允许在配置项中使用变量,如在日志记录部分,具体示例如下。
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
其中,remote_addr是一个变量,使用它的时候前面要加上$符号。需要注意的是,这种变量只有少数模块支持,并不是通用的。
许多模块在解析请求时都会提供多个变量(如本章后面提到的http core module、http proxy module、http upstream module等),以使其他模块的配置可以即时使用。我们在学习某个模块提供的配置说明时可以关注它是否提供变量。
提示 在执行configure命令时,我们已经把许多模块编译进Nginx中,但是否启用这些模块,一般取决于配置文件中相应的配置项。换句话说,每个Nginx 模块都有自己感兴趣的配置项,大部分模块都必须在nginx.conf中读取某个配置项后才会在运行时启用。例如,只有当配置http {...}这个配置项时,ngx_http_module模块才会在Nginx中启用,其他依赖ngx_http_module的模块也才能正常使用。
2.3 Nginx服务的基本配置
Nginx在运行时,至少必须加载几个核心模块和一个事件类模块。这些模块运行时所支持的配置项称为基本配置—所有其他模块执行时都依赖的配置项。
下面详述基本配置项的用法。由于配置项较多,所以把它们按照用户使用时的预期功能分成了以下4类:
用于调试、定位问题的配置项。
正常运行的必备配置项。
优化性能的配置项。
事件类配置项(有些事件类配置项归纳到优化性能类,这是因为它们虽然也属于events {}块,但作用是优化性能)。
有这么一些配置项,即使没有显式地进行配置,它们也会有默认的值,如daemon,即使在nginx.conf中没有对它进行配置,也相当于打开了这个功能,这点需要注意。对于这样的配置项,作者会在下面相应的配置项描述上加入一行“默认:”来进行说明。
2.3.1 用于调试进程和定位问题的配置项
先来看一下用于调试进程、定位问题的配置项,如下所示。
(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_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配置项。
(4)是否处理几个特殊的调试点
语法:debug_points [stop | abort]
这个配置项也是用来帮助用户跟踪调试Nginx的。它接受两个参数:stop和abort。Nginx在一些关键的错误逻辑中(Nginx 1.0.14版本中有8处)设置了调试点。如果设置了debug_points为stop,那么Nginx的代码执行到这些调试点时就会发出SIGSTOP信号以用于调试。如果debug_points设置为abort,则会产生一个coredump文件,可以使用gdb来查看Nginx当时的各种信息。
通常不会使用这个配置项。
(5)仅对指定的客户端输出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参数,否则不会生效。
(6)限制coredump核心转储文件的大小
语法:worker_rlimit_core size;
在Linux系统中,当进程发生错误或收到信号而终止时,系统会将进程执行时的内存内容(核心映像)写入一个文件(core文件),以作为调试之用,这就是所谓的核心转储(core dumps)。当Nginx进程出现一些非法操作(如内存越界)导致进程直接被操作系统强制结束时,会生成核心转储core文件,可以从core文件获取当时的堆栈、寄存器等信息,从而帮助我们定位问题。但这种core文件中的许多信息不一定是用户需要的,如果不加以限制,那么可能一个core文件会达到几GB,这样随便coredumps几次就会把磁盘占满,引发严重问题。通过worker_rlimit_core配置可以限制core文件的大小,从而有效帮助用户定位问题。
(7)指定coredump文件生成目录
语法:working_directory path;
worker进程的工作目录。这个配置项的唯一用途就是设置coredump文件所放置的目录,协助定位问题。因此,需确保worker进程有权限向working_directory指定的目录中写入文件。
2.3.2 正常运行的配置项
下面是正常运行的配置项的相关介绍。
(1)定义环境变量
语法:env VAR|VAR=VALUE
这个配置项可以让用户直接设置操作系统上的环境变量。例如:
env TESTPATH=/tmp/;
(2)嵌入其他配置文件
语法:include /path/file;
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的信号队列的大小。也就是说,当某个用户的信号队列满了,这个用户再发送的信号量会被丢掉。
2.3.3 优化性能的配置项
下面是优化性能的配置项的相关介绍。
(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)还要小。
2.3.4 事件类配置项
下面是事件类配置项的相关介绍。
(1)是否打开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进程之间的负载会非常不均衡,因此不建议关闭它。
(2)lock文件的路径
语法:lock_file path/file;
默认:lock_file logs/nginx.lock;
accept锁可能需要这个lock文件,如果accept锁关闭,lock_file配置完全不生效。如果打开了accept锁,并且由于编译程序、操作系统架构等因素导致Nginx不支持原子锁,这时才会用文件锁实现accept锁(14.8.1节将会介绍文件锁的用法),这样lock_file指定的lock文件才会生效。
注意 在基于i386、AMD64、Sparc64、PPC64体系架构的操作系统上,若使用GCC、Intel C++ 、SunPro C++编译器来编译Nginx,则可以肯定这时的Nginx是支持原子锁的,因为Nginx会利用CPU的特性并用汇编语言来实现它(可以参考14.3节x86架构下原子操作的实现)。这时的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进程可以同时处理的最大连接数。
块配置项由一个块配置项名和一对大括号组成。具体示例如下:
events {
…
}
http {
upstream backend {
server 127.0.0.1:8080;
}
gzip on;
server {
…
location /webstatic {
gzip off;
}
}
}
上面代码段中的events、http、server、location、upstream等都是块配置项,块配置项之后是否如“location /webstatic {...}”那样在后面加上参数,取决于解析这个块配置项的模块,不能一概而论,但块配置项一定会用大括号把一系列所属的配置项全包含进来,表示大括号内的配置项同时生效。所有的事件类配置都要在events块中,http、server等配置也遵循这个规定。
块配置项可以嵌套。内层块直接继承外层块,例如,上例中,server块里的任意配置都是基于http块里的已有配置的。当内外层块中的配置发生冲突时,究竟是以内层块还是外层块的配置为准,取决于解析这个配置项的模块,第4章将会介绍http块内配置项冲突的处理方法。例如,上例在http模块中已经打开了“gzip on;”,但其下的location/webstatic又把gzip关闭了:gzip off;,最终,在/webstatic的处理模块中,gzip模块是按照gzip off来处理请求的。
2.2.2 配置项的语法格式
从上文的示例可以看出,最基本的配置项语法格式如下:
配置项名 配置项值1 配置项值2 … ;
下面解释一下配置项的构成部分。
首先,在行首的是配置项名,这些配置项名必须是Nginx的某一个模块想要处理的,否则Nginx会认为配置文件出现了非法的配置项名。配置项名输入结束后,将以空格作为分隔符。
其次是配置项值,它可以是数字或字符串(当然也包括正则表达式)。针对一个配置项,既可以只有一个值,也可以包含多个值,配置项值之间仍然由空格符来分隔。当然,一个配置项对应的值究竟有多少个,取决于解析这个配置项的模块。我们必须根据某个Nginx 模块对一个配置项的约定来更改配置项,第4章将会介绍模块是如何约定一个配置项的格式。
最后,每行配置的结尾需要加上分号。
注意 如果配置项值中包括语法符号,比如空格符,那么需要使用单引号或双引号括住配置项值,否则Nginx会报语法错误。例如:
log_format main '$remote_addr - $remote_user [$time_local] "$request" ';
2.2.3 配置项的注释
如果有一个配置项暂时需要注释掉,那么可以加“#”注释掉这一行配置。例如:#pid logs/nginx.pid;
2.2.4 配置项的单位
大部分模块遵循一些通用的规定,如指定空间大小时不用每次都定义到字节、指定时间时不用精确到毫秒。
当指定空间大小时,可以使用的单位包括:
K或者k千字节(KiloByte,KB)。
M或者m兆字节(MegaByte,MB)。
例如:
gzip_buffers 4 8k;
client_max_body_size 64M;
当指定时间时,可以使用的单位包括:
ms(毫秒),s(秒),m(分钟),h(小时),d(天),w(周,包含7天),M(月,包含30天),y(年,包含365天)。
例如:
expires 10y;
proxy_read_timeout 600;
client_body_timeout 2m;
注意 配置项后的值究竟是否可以使用这些单位,取决于解析该配置项的模块。如果这个模块使用了Nginx框架提供的相应解析配置项方法,那么配置项值才可以携带单位。第4章中详细描述了Nginx框架提供的14种预设解析方法,其中一些方法将可以解析以上列出的单位。
2.2.5 在配置中使用变量
有些模块允许在配置项中使用变量,如在日志记录部分,具体示例如下。
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
其中,remote_addr是一个变量,使用它的时候前面要加上$符号。需要注意的是,这种变量只有少数模块支持,并不是通用的。
许多模块在解析请求时都会提供多个变量(如本章后面提到的http core module、http proxy module、http upstream module等),以使其他模块的配置可以即时使用。我们在学习某个模块提供的配置说明时可以关注它是否提供变量。
提示 在执行configure命令时,我们已经把许多模块编译进Nginx中,但是否启用这些模块,一般取决于配置文件中相应的配置项。换句话说,每个Nginx 模块都有自己感兴趣的配置项,大部分模块都必须在nginx.conf中读取某个配置项后才会在运行时启用。例如,只有当配置http {...}这个配置项时,ngx_http_module模块才会在Nginx中启用,其他依赖ngx_http_module的模块也才能正常使用。
2.3 Nginx服务的基本配置
Nginx在运行时,至少必须加载几个核心模块和一个事件类模块。这些模块运行时所支持的配置项称为基本配置—所有其他模块执行时都依赖的配置项。
下面详述基本配置项的用法。由于配置项较多,所以把它们按照用户使用时的预期功能分成了以下4类:
用于调试、定位问题的配置项。
正常运行的必备配置项。
优化性能的配置项。
事件类配置项(有些事件类配置项归纳到优化性能类,这是因为它们虽然也属于events {}块,但作用是优化性能)。
有这么一些配置项,即使没有显式地进行配置,它们也会有默认的值,如daemon,即使在nginx.conf中没有对它进行配置,也相当于打开了这个功能,这点需要注意。对于这样的配置项,作者会在下面相应的配置项描述上加入一行“默认:”来进行说明。
2.3.1 用于调试进程和定位问题的配置项
先来看一下用于调试进程、定位问题的配置项,如下所示。
(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_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配置项。
(4)是否处理几个特殊的调试点
语法:debug_points [stop | abort]
这个配置项也是用来帮助用户跟踪调试Nginx的。它接受两个参数:stop和abort。Nginx在一些关键的错误逻辑中(Nginx 1.0.14版本中有8处)设置了调试点。如果设置了debug_points为stop,那么Nginx的代码执行到这些调试点时就会发出SIGSTOP信号以用于调试。如果debug_points设置为abort,则会产生一个coredump文件,可以使用gdb来查看Nginx当时的各种信息。
通常不会使用这个配置项。
(5)仅对指定的客户端输出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参数,否则不会生效。
(6)限制coredump核心转储文件的大小
语法:worker_rlimit_core size;
在Linux系统中,当进程发生错误或收到信号而终止时,系统会将进程执行时的内存内容(核心映像)写入一个文件(core文件),以作为调试之用,这就是所谓的核心转储(core dumps)。当Nginx进程出现一些非法操作(如内存越界)导致进程直接被操作系统强制结束时,会生成核心转储core文件,可以从core文件获取当时的堆栈、寄存器等信息,从而帮助我们定位问题。但这种core文件中的许多信息不一定是用户需要的,如果不加以限制,那么可能一个core文件会达到几GB,这样随便coredumps几次就会把磁盘占满,引发严重问题。通过worker_rlimit_core配置可以限制core文件的大小,从而有效帮助用户定位问题。
(7)指定coredump文件生成目录
语法:working_directory path;
worker进程的工作目录。这个配置项的唯一用途就是设置coredump文件所放置的目录,协助定位问题。因此,需确保worker进程有权限向working_directory指定的目录中写入文件。
2.3.2 正常运行的配置项
下面是正常运行的配置项的相关介绍。
(1)定义环境变量
语法:env VAR|VAR=VALUE
这个配置项可以让用户直接设置操作系统上的环境变量。例如:
env TESTPATH=/tmp/;
(2)嵌入其他配置文件
语法:include /path/file;
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的信号队列的大小。也就是说,当某个用户的信号队列满了,这个用户再发送的信号量会被丢掉。
2.3.3 优化性能的配置项
下面是优化性能的配置项的相关介绍。
(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)还要小。
2.3.4 事件类配置项
下面是事件类配置项的相关介绍。
(1)是否打开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进程之间的负载会非常不均衡,因此不建议关闭它。
(2)lock文件的路径
语法:lock_file path/file;
默认:lock_file logs/nginx.lock;
accept锁可能需要这个lock文件,如果accept锁关闭,lock_file配置完全不生效。如果打开了accept锁,并且由于编译程序、操作系统架构等因素导致Nginx不支持原子锁,这时才会用文件锁实现accept锁(14.8.1节将会介绍文件锁的用法),这样lock_file指定的lock文件才会生效。
注意 在基于i386、AMD64、Sparc64、PPC64体系架构的操作系统上,若使用GCC、Intel C++ 、SunPro C++编译器来编译Nginx,则可以肯定这时的Nginx是支持原子锁的,因为Nginx会利用CPU的特性并用汇编语言来实现它(可以参考14.3节x86架构下原子操作的实现)。这时的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进程可以同时处理的最大连接数。