Nginx学习（12）—— 配置指令整理

丶星下灯

于 2023-09-07 10:06:10 发布

阅读量235

点赞数

文章标签： nginx

本文链接：https://blog.csdn.net/Stars____/article/details/130689092

版权

文章目录

基本配置项

基本配置项

Nginx中配置项比较多，所以按照用户使用时的预期功能划分为以下四类。

用于调试、定位问题的配置项

是否以守护进程的方式启动Nginx：守护进程（daemon）是脱离终端并且在后台运行的进程。它脱离终端是为了避免进程执行过程中的信息在任何终端上显示，这样一来，进程也不会被任何终端所产生的信息所打断。
Nginx提供了关闭守护进程的模式，之所以提供这种模式，是为了方便跟踪调试Nginx，因为用gdb调试多进程时很麻烦。
```
daemon on | off;
默认： daemon on;
```
是否以master/worker方式工作：如果用off关闭了master_process方式，就不会fork出worker子进程来处理请求，而是用master进程自身来处理请求。
```
master_process on | off;
默认： master_process off;
```
error日志的设置：pathfile也可以是/dev/null，这样就不会输出任何日志了，这也是关闭error日志的唯一手段；pathfile也可以是stderr。
```
error_log 	pathfile level;
默认：error_log logs/error.log error;
```
是否处理几个特殊的调试点：如果设置了debug_points为stop，那么Nginx的代码执行到这些调试点时就会发出SIGSTOP信号以用于调试。
如果debug_points设置为abort，则会产生一个coredump文件，可以使用gdb来查看Nginx当时的各种信息。
通常不会使用这个配置项。
```
debug_points[stop|abort];
```

仅对指定的客户端输出debug级别的日志：这个配置项实际上属于事件类配置，因此，它必须放在events{…}中才有效。它的值可以是IP地址或CIDR地址。

debug_connection[IP|CIDR];

#比如：
events {
	debug_connection 10.224.66.14;
	debug_connection 10.224.57.0/24;	# CIDR
}
#这样，仅仅来自以上IP地址的请求才会输出debug级别的日志，其他请求仍然沿用error_log中配置的日志级别

限制coredump核心转储文件的大小：当Nginx进程出现一些非法操作（如内存越界）导致进程直接被操作系统强制结束时，会生成核心转储core文件，可以从core文件获取当时的堆栈、寄存器等信息，从而帮助我们定位问题。但这种core文件中的许多信息不一定是用户需要的，如果不加以限制，那么可能一个core文件会达到几GB，这样随便coredumps几次就会把磁盘占满，引发严重问题。通过worker_rlimit_core配置可以限制core文件的大小，从而有效帮助用户定位问题。
```
worker_rlimit_core size;
```
指定coredump文件生成目录：这个配置项的唯一用途就是设置coredump文件所放置的目录。
```
working_directory path;
```

正常运行的必备配置项

定义环境变量：这个配置项可以让用户直接设置操作系统上的环境变量。
```
env VAR|VAR=VALUE;

#比如：
env TESTPATH=/tmp/;
```
嵌入其他配置文件：include配置项可以将其他配置文件嵌入到当前的nginx.conf文件中，它的参数既可以是绝对路径，也可以是相对路径（相对于Nginx的配置目录，即nginx.conf所在的目录）。参数的值可以是一个明确的文件名，也可以是含有通配符*的文件名，同时可以一次嵌入多个配置文件
```
include 	pathfile;
#比如：
include mime.types;
include vhost/*.conf;
```
pid文件的路径：保存master进程ID的pid文件存放路径。默认与configure执行时的参数“–pid-path”所指定的路径是相同的，也可以随时修改，但应确保Nginx有权在相应的目标中创建pid文件，该文件直接影响Nginx是否可以运行
```
pid path/file;
默认： pid logs/nginx.pid;
```
worker进程运行的用户及用户组：user用于设置master进程启动后，fork出的worker进程运行在哪个用户和用户组下。当按照“user username;”设置时，用户组名与用户名相同。
若用户在configure命令执行时使用了参数–user=username和–group=groupname，此时nginx.conf将使用参数中指定的用户和用户组。
```
user username[groupname];
默认： user nobody nobody;
```
worker进程可以打开的最大句柄描述符个数：设置一个worker进程可以打开的最大文件句柄数。
```
worker_rlimit_nofile limit;
```
限制信号队列：设置每个用户发往Nginx的信号队列的大小。也就是说，当某个用户的信号队列满了，这个用户再发送的信号量会被丢掉。
```
worker_rlimit_sigpending limit;
```

优化性能的配置项

worker进程个数：每个worker进程都是单线程的进程，它们会调用各个模块以实现多种多样的功能。如果这些模块确认不会出现阻塞式的调用，那么，有多少CPU内核就应该配置多少个进程；反之，如果有可能出现阻塞式调用，那么需要配置稍多一些的worker进程。
```
worker_processes number;
默认： worker_processes 1;
```
绑定Nginx worker进程到指定的CPU内核：为什么要绑定worker进程到指定的CPU内核呢？假定每一个worker进程都是非常繁忙的，如果多个worker进程都在抢同一个CPU，那么这就会出现同步问题。反之，如果每一个worker进程都独享一个CPU，就在内核的调度策略上实现了完全的并发。
```
worker_cpu_affinity cpumask[cpumask...]

# 比如：CPU有4个内核
worker_processes 4; 
worker_cpu_affinity 1000 0100 0010 0001;
```
注意：worker_cpu_affinity配置仅对Linux操作系统有效。Linux操作系统使用sched_setaffinity()系统调用实现这个功能。
SSL硬件加速：如果服务器上有SSL硬件加速设备，那么就可以进行配置以加快SSL协议的处理速度。用户可以使用OpenSSL提供的命令（openssl engine -t）来查看是否有SSL硬件加速设备：
```
ssl_engine device;
```
系统调用gettimeofday的执行频率：默认情况下，每次内核的事件调用（如epoll、select、poll、kqueue等）返回时，都会执行一次gettimeofday，实现用内核的时钟来更新Nginx中的缓存时钟。在早期的Linux内核中，gettimeofday的执行代价不小，因为中间有一次内核态到用户态的内存复制。当需要降低gettimeofday的调用频率时，可以使用timer_resolution配置。例如，“timer_resolution100ms；”表示至少每100ms才调用一次gettimeofday。
但在目前的大多数内核中，如x86-64体系架构，gettimeofday只是一次vsyscall，仅仅对共享内存页中的数据做访问，并不是通常的系统调用，代价并不大，一般不必使用这个配置。而且，如果希望日志文件中每行打印的时间更准确，也可以使用它。
```
timer_resolution t;
```
worker进程优先级设置：当许多进程都处于可执行状态时，将按照所有进程的优先级来决定本次内核选择哪一个进程执行。nice值是进程的静态优先级，它的取值范围是–20~+19，-20是最高优先级。
```
worker_priority nice;
默认：worker_priority 0;
```

事件类配置项

有些事件类配置项归纳到优化性能类，这是因为它们虽然也属于events{}块，但作用是优化性能。

是否打开accept锁：accept_mutex是Nginx的负载均衡锁。accept_mutex这把锁可以让多个worker进程轮流地、序列化地与新的客户端建立TCP连接。当某一个worker进程建立的连接数量达到worker_connections配置的最大连接数的7/8时，会大大地减小该worker进程试图建立新TCP连接的机会，以此实现所有worker进程之上处理的客户端请求数尽量接近。
accept锁默认是打开的，如果关闭它，那么建立TCP连接的耗时会更短，但worker进程之间的负载会非常不均衡，因此不建议关闭它。
```
accept_mutex[on|off];
默认：accept_mutex on;
```
lock文件的路径：accept锁可能需要这个lock文件，如果accept锁关闭，lock_file配置完全不生效。如果打开了accept锁，并且由于编译程序、操作系统架构等因素导致Nginx不支持原子锁，这时才会用文件锁实现accept锁。这样lock_file指定的lock文件才会生效。
```
lock_file path/file;
默认：lock_file logs/nginx.lock;
```
注意：在基于i386、AMD64、Sparc64、PPC64体系架构的操作系统上，若使用GCC、Intel C++、SunPro C++编译器来编译Nginx，则可以肯定这时的Nginx是支持原子锁的，因为Nginx会利用CPU的特性并用汇编语言来实现它。这时的lock_file配置是没有意义的。
使用accept锁后到真正建立连接之间的延迟时间：在使用accept锁后，同一时间只有一个worker进程能够取到accept锁。这个accept锁不是阻塞锁，如果取不到会立刻返回。如果有一个worker进程试图取accept锁而没有取到，它至少要等accept_mutex_delay定义的时间间隔后才能再次试图取锁。
```
accept_mutex_delay Nms;
默认：accept_mutex_delay 500ms;
```
批量建立新连接：当事件模型通知有新连接时，尽可能地对本次调度中客户端发起的所有TCP请求都建立连接。
```
multi_accept[on|off];
默认：multi_accept off;
```
选择事件模型：对于Linux操作系统来说，可供选择的事件驱动模型有poll、select、epoll三种。
```
use [kqueue|rtsig|epoll|/dev/poll|select|poll|eventport];
默认：Nginx会自动使用最适合的事件模型;
```
每个worker的最大连接数：定义每个worker进程可以同时处理的最大连接数。
```
worker_connections number;
```

丶星下灯

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
Nginx学习（12）—— 配置指令整理

当某一个worker进程建立的连接数量达到worker_connections配置的最大连接数的7/8时，会大大地减小该worker进程试图建立新TCP连接的机会，以此实现所有worker进程之上处理的客户端请求数尽量接近。使用accept锁后到真正建立连接之间的延迟时间：在使用accept锁后，同一时间只有一个worker进程能够取到accept锁。accept锁默认是打开的，如果关闭它，那么建立TCP连接的耗时会更短，但worker进程之间的负载会非常不均衡，因此不建议关闭它。
复制链接

扫一扫