Nginx配置文件编写（基础配置）

目录：

一、从一个简单的Nginx配置文件入手

1. 如何使用自定义的配置文件
2. Nginx配置文件的结构

二、Nginx服务的基本配置

1. 用于调试进程和定位问题的配置项
2. 正常运行的配置项
3. 优化性能的配置项
4. 事件类配置项

---

一、从一个简单的Nginx配置文件入手：

worker_processes 4;

events {
	worker_connections 1024;
}

http {
	server {
		listen 192.254.1.16:9000;
		server_name  192.254.1.16;

		location / {
			root /usr/local/nginx/html/;
		}
	}
}

1. 如何使用自定义的配置文件：

Nginx默认的配置文件是：

/usr/local/nginx/conf/nginx.conf

如果需要使用自定义的配置文件，则需要在运行前指定所用配置文件的路径：

./sbin/nginx -c my_conf/my_conf.conf

关于Nginx命令行支持的参数，可使用 ./sbin/nginx -h 查看：

./nginx -h 			 	# this help
./nginx -c filename  	# set configuration file (default: conf/nginx.conf)
./nginx -s signal 		# send signal to a master process: stop, quit, reopen, reload

./nginx -v				# show version and exit
./nginx -V				# show version and configure options then exit

./nginx -q				# suppres non-error messages during configuration testing
./nginx -p prefix		# set prefix path (default: /usr/local/nginx)
./nginx -g directives	# set global directives out of configuration file

2. Nginx配置文件的结构：

配置文件由若干个指令组成，指令分为简单指令和块指令。
最基本的配置项语法格式：

配置项名  配置项值 ;

Nginx配置文件主要分为四部分：

（1）main：
全局配置，用于配置与具体业务无关的参数，例如 worker_processes用来配置要起几个线程；

（2）events：
用于配置影响Nginx服务与用户之间连接的属性，例如 worker_connections 配置每个线程的最大连接数；

（3）http：
用于配置Nginx的业务功能，除http外，还有email；

（4）server：
server必须位于http内部，用于配置Nginx的一个主机；其中listen指定监听的端口号；server_name指定主机名；location用于指定主机上的资源位置。

TIPS：

“worker_processes”, “events”, “http”, “server”, “worker_connections” 这些配置项的名称，在Nginx源码中都是写死的字符串，在Nginx运行时会根据配置文件中的配置项去源码中查找与之匹配的字符串，并按照给出的配置项值进行服务器配置，所以我们需要做的是熟悉这些常用的配置项的名称及功能、用法。

---

二、Nginx服务的基本配置：

Nginx的基本配置可按照 用户使用时的预期功能 分为以下 4 类：
（这些是Nginx的基本配置项，不论是要配置HTTP还是EMAIL服务，是静态Web服务器还是反向代理，都要先配置这些基本项，它们是通用项。）

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

(1) 使Nginx以守护进程的方式在后台运行，默认on

daemon on;
daemon off;

(2) 以master/worker的方式工作，默认on

master_process on;
master_process off;

(3) 设置error日志的路径

error_log logs/error.log error;

(4) 是否处理几个特殊的调试点：

debug_points stop
debug_points abort;

通常不会使用这个配置项。Nginx在一些关键的错误逻辑中设置了调试点，如果设置为stop，代码执行到这些预设的调试点就会发出SIGSTOP信号以用于调试；如果设置为abort，则会产生一个coredump，用于gdb查看当时的Nginx各种信息。

(5) 仅对某个IP的客户端输出debug级别的日志，其他客户端仍使用error_log中配置的日志界别：

debug_connection IP;
debug_connection CIDR;

这一配置项对定位高并发场景下发送的问题非常有用！仅跟踪某个IP的客户端的debug级别日志

例如：

events {
    debug_connection 10.224.66.14;
    debug_connection 10.224.57.0/24;
}

(6) 限制coredump核心转储文件的大小：

worker_rlimit_core [size];

(7) 指定coredump文件生成目录：

working_directory [path];

Tips：

1. 守护进程（daemon）是什么：

   守护进程（daemon）是脱离终端并且在后台运行的进程。它脱离终端是为了避免进程执行过程中的信息在任何终端上显示，这样一来，进程也不会被任何终端所产生的信息所打断（比如Ctrl+C不会终止Nginx的运行）。Nginx毫无疑问是一个需要以守护进程方式运行的服务，因此默认都是以这种方式运行的（默认配置项值为on）。
   不过Nginx还是提供了关闭守护进程的模式，之所以提供这种模式，是为了方便跟踪调试Nginx，毕竟用gdb调试进程时最烦琐的就是如何继续跟进fork出的子进程了。

2. coredump怎么用：

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

2. 正常运行的配置项：

(1) 定义环境变量：
允许用户直接设置操作系统上的环境变量。

env VAR | VAR = value;
eg:
env TESTPATH = /tmp/;

(2) 嵌入其他配置文件：
类似于与C源文件中包含其他的头文件，Nginx配置文件中也可以使用include将其他配置文件嵌入到当前的nginx.conf中。

http {
	include mime/types;
}

mime/types也是一个配置文件。

(3) pid文件的路径：

pid [path/file];

(4) Nginx worker进程运行的用户及用户组：

user [username][groupname];

(5) 指定Nginx worker进程可以打开的最大文件句柄数：

worker_rlimit_nofile [limit];

(6) 限制信号队列：

worker_rlimit_sigpending [limit];

3. 优化性能的配置项：

(1) 【常用】配置worker进程数:

worker_processes 1;

这些进程都是单线程，一般配置成与CPU数量相同。

(2) 绑定Nginx worker进程到指定的CPU内核：

worker_puc_affinity [cpumask][cpumask];

(3) SSL硬件加速：

ssl_engine device;

(4) 系统调用gettimeofday的执行频率：

timer_resolution t;

(5) Nginx worker进程优先级设置：

worker_priority 0;

4. 事件类配置项：

(1) 是否打开accept锁：

accept_mutex on;		# 默认on
accept_mutex off;

accept_mutex是Nginx的负载均衡锁，这把锁可以让多个worker进程轮流的、序列化的与新的客户端建立连接。
当某一个worker进程建立的连接数量达到worker_connections配置的最大连接数的7/8时，会大大的减少该worker进程试图建立新的TCP连接的机会，以此实现所有worker进程智商处理的客户端的请求数尽量相近。

accept锁是默认打开的，如果关闭它，那么TCP建立的耗时会更短，但worker进程之间的负载会非常不平衡。

(2) lock文件的路径：

lock_file logs/nginx.lock;

(3) 两次尝试获得accept锁之间的间隔时间：

accept_mutex_delay 500ms;

使用accept锁后同一时间只能有一个worker进程获得锁，accept锁是非阻塞的，获取失败会立即返回，此进程需要间隔accept_mutex_delay时间后才能再次尝试获得锁。

(4) 批量建立新连接：

multi_accept off;

(5) 选择事件类型：

use epoll;
use select;
use poll;
use kqueue;

Nginx会自动选择最合适的实现模型，默认为epoll

(6) 【常用】每个worker进程可以同时处理的最大连接数：

worker_connections 1024;

---

参考内容：

《深入理解Nginx：模块开发与架构解析》
死磕nginx系列 - - 配置文档解读