缘起

接触nginx（以下简称ng）也并不是才接触的，其实笔者早在2015年的时候就已经在项目中使用过ng了，但限于当时的知识有限，需要学习的东西也很多，一直没能对ng做深入的了解。近来项目稍空，所以准备对ng做一个比较深入的了解，其中了解的方式就是读陶辉的《深入理解Nginx:模块开发与架构解析(第二版)》，而本文也是读这本书的一些收获做一个笔记。

关于阅读对象
在阅读本书前，笔者已经对ng有一定的了解并且在项目中使用过ng了，所以本文不是ng的使用说明书，阅读本文前需要读者对ng的基本使用方式有一定的了解

关于配置

ng本身可以理解为一个容器，我们可以在其中引入很多模块，其中一些模块是ng必须的，另一些是我们需要扩展ng的时候才需要引入的。ng有成千上万个模块，每个模块又有它自己的配置参数。在本文中，我们只会对常用的几个模块配置进行讲解。

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

（1）是否以守护进程方式运行Nginx
语法： daemon on|off;
默认： daemon on;
守护进程（daemon）是脱离终端并且在后台运行的进程。它脱离终端是为了避免进程执行过程中的信息在任何终端上显示，这样一来，进程也不会被任何终端所产生的信息所打断。Nginx毫无疑问是一个需要以守护进程方式运行的服务，因此，默认都是以这种方式运行的。
不过Nginx还是提供了关闭守护进程的模式，之所以提供这种模式，是为了方便跟踪调试Nginx，毕竟用gdb调试进程时最烦琐的就是如何继续跟进fork出的子进程了。这在第三部分研究Nginx架构时很有用。

（2）是否以master/worker方式工作
语法： master_process on|off;
默认： master_process on;
默认nginx是以一个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指定的目录中写入文件。

正常运行的配置项

（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的信号队列的大小。也就是说，当某个用户的信号队列满了，这个用户再发送的信号量会被丢掉。

优化性能的配置项

（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的负载均衡锁，本书会在第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请求都建立连接。

（6）每个worker的最大连接数
语法： worker_connections number;
定义每个worker进程可以同时处理的最大连接数。

Nginx的一些配置项，Nginx调优相关推荐

Nginx源码安装及调优配置(二)
Nginx运行进程个数,一般我们设置CPU的核心或者核心数x2,如果你不了解,top命令之后按1也可以看出来(一般直接追到线程即可) [root@linuxprobe ~]# vim /usr/loc ...
Nginx源码安装及调优配置
由于Nginx本身的一些优点,轻量,开源,易用,越来越多的公司使用nginx作为自己公司的web应用服务器,本文详细介绍nginx源码安装的同时并对nginx进行优化配置. Nginx编译前的优化 [ ...
hadoop 配置项的调优
dfs.block.size 决定HDFS文件block数量的多少(文件个数),它会间接的影响Job Tracker的调度和内存的占用(更影响内存的使用), mapred.map.tasks.spec ...
今天决定写一篇LNMP的深入调优，
LNMP=Linux Nginx Mysql PHP LNMP的调优着重体现在Nginx服务器上的调优 Nginx 是一个高性能的 HTTP 和反向代理服务器,因它的稳定性.丰富的功能集.示例配 ...
性能测试分析与性能调优诊断--史上最全的服务器性能分析监控调优篇
来源: https://www.cnblogs.com/laoqing/p/11629941.html 一个系统或者网站在功能开发完成后一般最终都需要部署到服务器上运行,那么服务器的性能监控和分析就显 ...
【转载】软件性能测试分析与调优实践之路-Web中间件的性能分析与调优总结
本文主要阐述软件性能测试中的一些调优思想和技术,节选自作者新书<软件性能测试分析与调优实践之路>部分章节归纳. 在国内互联网公司中,Web中间件用的最多的就是Apache和Nginx这两款 ...
AI4DB:openGauss人工智能参数调优之X-Tuner
X-Tuner:参数调优与诊断一.概述二.使用准备三.使用示例四.获取帮助五.命令参考六.常见问题处理一.概述增量物化视图可以对物化视图增量刷新,需要用户手动执行语句完成对物化视图 ...
服务器：浅谈 Nginx 性能调优，太实用了！
Linux系统参数优化下文中提到的一些配置,需要较新的Linux(2.6以上)内核才能够支持,笔者使用的CentOS 7.4,内核版本3.10,如果不满足需要的话,最好进行相应的升级,毕竟打补丁是件 ...
浅谈Nginx性能调优
女主宣言 Web服务性能调优是一项系统工程,涵盖许多方面,其中某一环节做的好并不能够保证整体性能好:但是如果某个环节做的不好,那么整体性能必然不会好. 可以调优的配置有很多,绝大多数情况下我们不需要追 ...
Nginx 配置和性能调优
优化 Nginx worker 进程数 Nginx 有 master 和 worker 两种进程,master 进程用于管理 worker 进程,worker 进程用于 Nginx 服务. worke ...

Nginx的一些配置项，Nginx调优

缘起