本文主要是介绍nginx教程第四篇：nginx服务的基本配置，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
Nginx服务的基本配置
由于配置项较多， 所以把基本配置项的用法按照用户使用时的预期功能
分成了以下4类：
- 用于调试、 定位问题的配置项
- 正常运行的必备配置项
- 优化性能的配置项
- 事件类配置项
用于调试和定位问题的配置项
- 是否以守护进程方式运行Nginx
语法： daemon on|off;
默认： daemon on;
说明：守护进程（ daemon）是脱离终端并且在后台运行的进程。它脱离终端是为了避免进程执行过程中的信
息在任何终端上显示，这样一来，进程也不会被任何终端所产生的信息所打断。Nginx毫无疑问是一个需要以
守护进程方式运行的服务， 因此， 默认都是以这种方式运行的。
不过Nginx还是提供了关闭守护进程的模式， 之所以提供这种模式，是为了方便跟踪调试Nginx，毕竟用gdb
调试进程时最烦琐的就是如何继续跟进fork出的子进程了。这在第三部分研究Nginx架构时很有用。
- 是否以master/worker方式工作
语法： master_process on|off;
默认： master_process on;
说明：前一博客，可以知道，Nginx是以一个master进程管理多个worker进程的方
式运行的， 几乎所有的产品环境下， Nginx都以这种方式工作。
与daemon配置相同， 提供master_process配置也是为了方便跟踪调试Nginx。 如果用off关
闭了master_process方式， 就不会fork出worker子进程来处理请求， 而是用master进程自身来
处理请求。
- error日志的设置
语法： error_log pathfile 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配置项
- 是否处理几个特殊的调试点
语法： debug_points[stop|abort]
这个配置项也是用来帮助用户跟踪调试Nginx的。 它接受两个参数： stop和abort。 Nginx
在一些关键的错误逻辑中（ Nginx 1.0.14版本中有8处） 设置了调试点。 如果设置了
debug_points为stop， 那么Nginx的代码执行到这些调试点时就会发出SIGSTOP信号以用于调
试。 如果debug_points设置为abort， 则会产生一个coredump文件， 可以使用gdb来查看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参
数， 否则不会生效。
- 限制coredump核心转储文件的大小
语法： worker_rlimit_core size;
在Linux系统中， 当进程发生错误或收到信号而终止时， 系统会将进程执行时的内存内
容（ 核心映像） 写入一个文件（ core文件） ， 以作为调试之用， 这就是所谓的核心转储
（ core dumps） 。 当Nginx进程出现一些非法操作（ 如内存越界） 导致进程直接被操作系统强
制结束时， 会生成核心转储core文件， 可以从core文件获取当时的堆栈、 寄存器等信息， 从
而帮助我们定位问题。 但这种core文件中的许多信息不一定是用户需要的， 如果不加以限
制， 那么可能一个core文件会达到几GB， 这样随便coredumps几次就会把磁盘占满， 引发严
重问题。 通过worker_rlimit_core配置可以限制core文件的大小， 从而有效帮助用户定位问
题。
- 指定coredump文件生成目录
语法： working_directory path;
worker进程的工作目录。 这个配置项的唯一用途就是设置coredump文件所放置的目录，
协助定位问题。 因此， 需确保worker进程有权限向working_directory指定的目录中写入文
件。
正常运行的必备配置项
- 定义环境变量
语法： env VAR|VAR=VALUE
这个配置项可以让用户直接设置操作系统上的环境变量。
例如：
env TESTPATH=/tmp/;
- 嵌入其他配置文件
语法：include pathfile;
include配置项可以将其他配置文件嵌入到当前的nginx.conf文件中， 它的参数既可以是绝
对路径， 也可以是相对路径（ 相对于Nginx的配置目录， 即nginx.conf所在的目录），
例如：
include mime.types;
include vhost/*.conf;
可以看到， 参数的值可以是一个明确的文件名， 也可以是含有通配符*的文件名， 同时
可以一次嵌入多个配置文件
- pid文件的路径
语法： pid path/file;
默认： pid logs/nginx.pid;
保存master进程ID的pid文件存放路径。 默认与configure执行时的参数“--pid-path”所指定
的路径是相同的， 也可以随时修改， 但应确保Nginx有权在相应的目标中创建pid文件， 该文
件直接影响Nginx是否可以运行
- Nginx worker进程运行的用户及用户组
语法： user username [groupname];
默认： user nobody nobody;
user用于设置master进程启动后， fork出的worker进程运行在哪个用户和用户组下。 当按
照“user username;”设置时， 用户组名与用户名相同。
若用户在configure命令执行时使用了参数--user=username和--group=groupname， 此时
nginx.conf将使用参数中指定的用户和用户组。
- 指定Nginx worker进程可以打开的最大句柄描述符个数
语法： worker_rlimit_nofile limit;
设置一个worker进程可以打开的最大文件句柄数。
- 限制信号队列
语法： worker_rlimit_sigpending limit;
设置每个用户发往Nginx的信号队列的大小。 也就是说， 当某个用户的信号队列满了，
这个用户再发送的信号量会被丢掉
优化性能的配置项
- 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内核。
- 绑定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()系统调用实现这个功能。
- SSL硬件加速
语法： ssl_engine device；
如果服务器上有SSL硬件加速设备， 那么就可以进行配置以加快SSL协议的处理速度。用户可以使用OpenSSL提供的命令来查看是否有SSL硬件加速设备：
openssl engine -t
- 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） 还要小。
事件类配置项
- 是否打开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进程
之间的负载会非常不均衡， 因此不建议关闭它。
注意：accept_mutex是Nginx的负载均衡锁
- lock文件的路径
语法： lock_file path/file;
默认： lock_file logs/nginx.lock;
accept锁可能需要这个lock文件， 如果accept锁关闭， lock_file配置完全不生效。 如果打
开了accept锁， 并且由于编译程序、 操作系统架构等因素导致Nginx不支持原子锁， 这时才会
用文件锁实现accept锁（ 14.8.1节将会介绍文件锁的用法） ， 这样lock_file指定的lock文件才
会生效
- 使用accept锁后到真正建立连接之间的延迟时间
语法： accept_mutex_delay Nms;
默认： accept_mutex_delay 500ms;
在使用accept锁后， 同一时间只有一个worker进程能够取到accept锁。 这个accept锁不是
阻塞锁， 如果取不到会立刻返回。 如果有一个worker进程试图取accept锁而没有取到， 它至
少要等accept_mutex_delay定义的时间间隔后才能再次试图取锁。
- 批量建立新连接
语法： multi_accept [on|off];
默认： multi_accept off;
当事件模型通知有新连接时， 尽可能地对本次调度中客户端发起的所有TCP请求都建立
连接。
- 选择事件模型
语法： use [kqueue|rtsig|epoll|/dev/poll|select|poll|eventport];
默认： Nginx会自动使用最适合的事件模型。
对于Linux操作系统来说， 可供选择的事件驱动模型有poll、 select、 epoll三种。 epoll当
然是性能最高的一种
- 每个worker的最大连接数
语法： worker_connections number;
定义每个worker进程可以同时处理的最大连接数。
这篇关于nginx教程第四篇：nginx服务的基本配置的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
