526互联

6、nginx通用配置

发布时间 2024-01-02 18:54:40作者: ccblblog

1、nginx进程之间的关系

部署Nginx时都是使用一个 master 进程来管理多个 worker 进程，一般情况下，worker 进程的数量与服务器上的CPU核心数相等。worker 进程之间通过共享内存、原子操作等一些进程间通信机制来实现负载均衡等功能

2、单进程nginx环境使用

  • 由于 master 进程不会对用户请求提供服务，只用于管理真正提供服务的 worker 进程。所以 master 进程可以是唯一的，它仅专注于自己的管理工作，为管理员提供命令行服务，包括诸如启动服务、停止服务、重载配置文件、平滑升级程序等。
  • master 进程需要拥有较大的权限，例如，通常会利用 root 用户启动 master 进程。worker进程的权限要小于或等于master进程，这样 master 进程才可以完全地管理 worker 进程。当任意一个 worker 进程出现错误从而导致 coredump 时，master 进程会立刻启动新的 worker 进程继续服务。
  • 多个 worker 进程处理互联网请求不但可以提高服务的健壮性 ( 一个 worker 进程出错后，其他 worker 进程仍然可以正常提供服务)，最重要的是，实现微观上真正的多核并发处理。因此，用一个进程 (master 进程) 来处理互联网请求肯定是不合适的。
  • 为什么要把 worker 进程数量设置得与CPU核心数量一致呢?这正是 Nginx 与 Apache 服务器的不同之处。在 Apache 上每个进程在一个时刻只处理一个请求，因此，如果希望 Web 服务器拥有并发处理的请求数更多，就要把 Apache 的进程或线程数设置得更多，通常会达到一台服务器拥有几百个工作进程，这样大量的进程间切换将带来无谓的系统资源消耗。而 Nginx 则不然，一个 worker 进程可以同时处理的请求数只受限于内存大小，而且在架构设计上，不同的 worker 进程之间处理并发请求时几平没有同步锁的限制，worker进程通常不会进入睡眠状态，因此，当 Nginx 上的进程数与 CPU 核心数相等时(最好每一个 worker 进程都绑定特定的 CPU 核心)，进程间切换的代价是最小的。

image

如果服务器的 CPU 核心数为8，那么就需要配置8个 worker进程

3、Nginx配置的通用语法

3.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 {...}参数，取决于解析这个块配置项的模块
  • 块配置项一定会用大括号把一系列所属的配置项全包含进来，表示大括号内的配置项同时生效。
  • 块配置项可以嵌套。内层块直接继承外层块，例如，上例中 server 块里的任意配置都是基于 http 块里的已有配置的。
  • 当内外层块中的配置与外层块发生冲突时，究竟是以内层块还是外层块的配置为准，取决于解析这个配置项的模块，例如，上例在http 模块中已经打开了gzip on;，但其下的location /webstatic 又把 gzip 关闭了:gzip off;，最终，在/webstatic 的处理模块中，gzip 模块是按照 gzip off来处理请求的。

3.2 配置项基本语法说明

nginx 最基本的配置项语法格式如下:配置项名 配置项值 1 配置项值 2 ··· ;

  • 在行首的是配置项名，这些配置项名必须是 Nginx 的某一个模块想要处理的，否则 Nginx 会认为配置文件出现了非法的配置项名。
  • 配置项名输入结束后，以空格作为分隔符。
  • 配置项值，可以是数字、字符串、正则表达式。
  • 一个配置项既可以只有一个值，也可以包含多个值，一个配置项对应的值究竟有多少个，取决于解析这个配置项的模块。
  • 配置项值之间由空格符来分隔。
  • 必须根据某 Nginx 模块对一个配置项的约定来更改配置项。
  • 每行配置的结尾需要加上分号。
  • 如果配置项值中包括语法符号，比如空格符，那么需要使用单引号或双引号括住配置项值，否则 Nginx 会报语法错误。例如:
    log_format main '$remote_addr - $remote_user [$time_local] "$request" '

3.3 配置项的注释

如果有一个配置项暂时需要注释掉，那么可以加#注释掉这一行配置。例如: # pid logs/nginx.pid;

3.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;

3.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等)，以使其他模块的配置可以即时使用。学习某个模块提供的配置说明时可以关注它是否提供变量。

4、Nginx服务的基本配置

4.1 配置项分类

  • 用于调试、定位问题的配置项。
  • 正常运行的必备配置项。
  • 优化性能的配置项。
  • 事件类配置项(有些事件类配置项归纳到优化性能类，这是因为它们虽然也属于 events{} 块，但作用是优化性能)。

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

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

语法: daemon on | off;
默认; daemon on;

  • 守护进程 (daemon)是脱离终端并且在后台运行的进程。它脱离终端是为了避免进程执行过程中的信息在任何终端上显示，这样一来，进程也不会被任何终端所产生的信息所打断。Nginx毫无疑问是一个需要以守护进程方式运行的服务，因此，默认都是以这种方式运行的。
  • Nginx 提供了关闭守护进程的模式，之所以提供这种模式，是为了方便跟踪调试 Nginx，毕竟用 gdb 调试进程时最烦的就是如何继续跟进 fork 出的子进程了。
  1. 是否以master/worker 方式工作

语法:master_process on|off;
默认: master_process on;

  • Nginx是以一个 master 进程管理多个 worker 进程的方式运行的，几乎所有 Nginx 都以这种方式工作。与daemon配置相同，提供 master process 配置也是为了方便跟踪调试Nginx。
  • 如果用off关闭了master_process 方式，就不会 fork 出 worker 子进程来处理请求，而是用 master 进程自身来处理请求。
  1. 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 配置项。

  1. 是否处理几个特殊的调试点

语法: debug_points [stop|abort]

  • 这个配置项是用来帮助用户跟踪调试 Nginx的。它接受两个参数: stop 和abort。
  • Nginx 在一些关键的错误逻辑中设置了调试点。如果设置了debug _points为stop，那么Nginx的代码执行到这些调试点时就会发出SIGSTOP信号以用于调试。如果 debug_points 设置为 abort，则会产生一个coredump 文件，可以使用gdb 来查看Nginx当时的各种信息。通常不会使用这个配置项。
  1. 仅对指定的客户端输出 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中配置的日志级别

注意 使用debug_connection 前，需确保在执行configure 时已经加入了--with-debug参数，否则不会生效。

  1. 限制 coredump 核心转储文件的大小

语法:worker_rlimit_core_size;

  • 在 Linux 系统中，当进程发生错误或收到信号而终止时，系统会将进程执行时的内存内容(核心映像)写入一个文件 (core 文件)，以作为调试之用，这就是所谓的核心转储 (coredumps)。
  • 当Nginx进出现一些非法操作(如内存界)导致进直接被操作系统强制结束时，会生成核心转储 core 文件，可以从 core 文件获取当时的堆栈、寄存器等信息，从而帮助我们定位问题。但这种 core 文中的许多信息不一定是用户需要的，如果不加以限制，那么可能一个 core 文件会达到几GB，这样随便 coredumps 几次就会把磁盘占满，引发严重问题。通过 worker_rlimit_core 配置可以限制core 文件的大小，从而有效帮助用户定位问题
  1. 指定 coredump 文件生成目录

语法:working_directory path;

  • worker 进程的工作目录。这个配置项的唯一用途就是设置 coredump 文件所放置的目录,协助定位问题。因此，需确保 worker 进程有权限向 working_directory指定的目录中写入文件。