文章目录
- Nginx 配置文件内容
- Nginx 配置文件基本结构
- Nginx 配置文件详细信息
- 全局块配置
- 配置运行 Nginx 服务器用户（组）
- 配置 worker processes 相关
- 配置 ssl 相关
- 配置错误日志存放路径及级别
- 配置PID文件存放路径及名称
- 配置锁文件
- event 块配置
- 配置事件驱动模型
- 配置网络连接相关
Nginx 配置文件内容
Nginx的主配置文件是nginx.conf，这个配置文件一共由三部分组成，分别为全局块、events块和http块。在http块中，又包含http全局块、多个server块。每个server块中，可以包含server全局块和多个location块。在同一配置块中嵌套的配置块，各个之间不存在次序关系。
配置文件支持大量可配置的指令，绝大多数指令不是特定属于某一个块的。同一个指令放在不同层级的块中，其作用域也不同，一般情况下，高一级块中的指令可以作用于自身所在的块和此块包含的所有低层级块。如果某个指令在两个不同层级的块中同时出现，则采用“就近原则”，即以较低层级块中的配置为准。比如，某指令同时出现在http全局块中和server块中，并且配置不同，则应该以server块中的配置为准。
以下是一个完整的nginx配置文件。
worker_processes 1; #全局生效
events {
worker_connections 1024; #在events部分中生效
}
http {
include mime.types ; #以下指令在http部分中生效
default_type application/octet-stream;
sendfile on;
keepalive_timeout 65;
server { #以下指令在http的server部分中生效
listen 80;
server_name localhost;
location / { #以下指令在http/server的location中生效
root html;
index index.html index.htm;
}
error_page 500 502 503 504 /50x.html;
location - /50x.html {
root html;
}
location ~ \.php$ {
root html;
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include fastcgi_params;
}
}
}
注意：在nginx配置中，还包括注释内容，注释标志位“#”。
Nginx 配置文件基本结构
初始的nginx服务器主配置是比较长的，不过结构和内容还是比较清晰的。通过上面的配置文件内容分析，我们可以总结出以下nginx.conf的基本结构：
... #全局快
events #events块
{
...
}
http #http块
{
... #http全局块
server #server块
{
... #server全局块
location [PATTERN] #location块
{
...
}
location [PATTERN] #location块
{
...
}
}
server #server块
{
...
}
... #http全局块
}
最外层的花括号将内容整体分为两部分，再加上最开始的内容，即第一行省略号表示的nginx.conf一共由三部分组成，分为全局块，events块和http块。在http块中，又包含http全局块，多个server块。每个server块中，可以包含server全局块和多个location块。在同一块配置中嵌套的配置块，各个之间不存在次序关系。
配置文件支持大量可配置的指令，绝大多数指令不是特定属于某一个块的。同一个指令放在不同层级的块中，其作用域也不同，一般情况下，高一级块中的指令可以作用于自身所在的块和此块包含的所有低层级块。如果某个指令在两个不同层级的块中同时出现，则采用“就近原则”，即以较低层级块中的配置为准。比如，某指令同时出现在http全局块中和server块中，并且配置不同，则应该以server块中的配置为准。
Nginx 配置文件详细信息
注意：在 Nginx 配置文件中，每一条指令配置都必须以分号结束。
全局块配置
配置运行 Nginx 服务器用户（组）
# 配置可以运行nginx服务器的用户和用户组
user user [group];
# 如果希望所有用户都可以启动Nginx，则配置为 user nobady;
user root root;
配置 worker processes 相关
官网介绍
#【可配置调优项】
# 配置允许生成的worker processes(工作进程)数
# 理论上来说 worker processes 值越大，可以支持的并发数量也越多，性能就越好
# 但实际上它的数量，还要受到服务器 CPU 处理器数量以及软件配置制约
# 从Nginx1.9.10开始可以使用auto值，系统自动检测 CPU 处理器数量，设置想要的工作进程数量
# 当然你设置的工作进程数量超过 CPU 处理器数量也行，但是这样就出现 CPU 的进程切换，影响性能
worker processes auto; # 可以用lscpu命令来找出CPU的核数
#【可配置调优项】
#设定nginx的worker进程工作在哪几个CPU核心上，上面的worker进程数量最好和这里的数量对应
#CPU几核心就用几位数，1表示使用，0表示不使用，从Nginx1.9.10可以使用auto值，系统自动设置
#这样绑定只是说明每个CPU只运行一个Nginx进程，并不能保证其他进程下次运行时，不会跑到当前这些CPU核心上去
#虽然限制了worker进程的范围，但是没有限制其他进程，如果想限制这些CPU核心不能被其他进程使用
#就只能做CPU隔离，在操作系统启动的时候就隔离出去。但这样对于内核级别的进程，比如中断还是可能会跑过去，所以
#真正做到严格隔离也可以，就是比较麻烦。
worker_cpu_affinity auto;
例如：
#2 CPU（2 Core） + 2 worker_processes（每个worker_processes 使用1个CPU）
#worker_processes 2;
#worker_cpu_affinity 01 10;
#2 CPU（2 Core） + 8 worker_processes（每个worker_processes 使用1个CPU）
#worker_processes 8;
#worker_cpu_affinity 01 10 01 10 01 10 01 10; (CPU与工作进程数量不对应时，多个工作进程抢占，轮流使用同一个CPU)
#4 CPU（4 Core） + 4 worker_processes（每个worker_processes 使用1个CPU）
#worker_processes 4;
#worker_cpu_affinity 0001 0010 0100 1000;
#8 CPU（8 Core） +2 worker_processes（每个worker_processes 使用1个CPU）
#worker_processes 2;
#worker_cpu_affinity 10101010 01010101;
#8 CPU（8 Core） + 8 worker_processes（每个worker_processes 使用1个CPU）
#worker_processes 8;
#worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000 01000000 10000000;
#【可配置调优项】
#这个指令是指当一个 nginx 进程打开的最多文件描述符数目；用于指定单个worker进程可以打开最大文件描述符数量，
#每个连接都会打开一个文件，所以对于并发非常大的场景这个值应该设置的大一点
#理论值应该是最多打开文件数（ulimit -n）与 nginx 进程数相除，但是 nginx 分配请求并不是那么均匀，所以最好
#与 ulimit -n 的值保持一致。现在在linux 2.6内核下开启文件打开数为65535，worker_rlimit_nofile就相应应该填写65535。
#这是因为nginx调度时分配请求到进程并不是那么的均衡，所以假如填写10240，总并发量达到3-4万时就有进程可能超过10240了，
#这时会返回502错误
#这个配置，在默认的配置文件中没有，受限于Linux系统设置，默认是1024个；可以自行修改，比如改成 65535 个。
#把这个值设高，这样nginx就不会有“too many open files”问题了
#如果Nginx作为web服务器，worker_rlimit_nofile要大于等于worker_connections，因为Nginx自己也要打开一些文件。
#如果Nginx作为代理服务器，worker_rlimit_nofile要是worker_connections的2倍，原因是Nginx作为代理的时候，面向请求是一个套接字，
#面向后端应用服务器也是一个套接字，所以一个请求在Nginx上要使用2个套接字，所以worker_rlimit_nofile要是worker_connections的2倍
worker_rlimit_nofile 65535;
#【可配置调优项】
#worker进程的优先级，与使用 nice 命令完成类似：负数意味着更高的优先级。允许范围通常在 -20 到 20 之间。
worker_priority -10;
配置 ssl 相关
#定义SSL硬件加速器，如果支持HTTPS的话，每一个都创建SSL会话，加密、解密、会话建立和断开等这些对CPU的占用率非常高，
#一个服务器可以承载的HTTPS会话大概是HTTP会话的1/5左右。服务器可以安装硬件的SSL会话加速器，那么你这里就可以指定，
#这样SSL会话就不会占用CPU资源。这个就跟高端服务器网卡带特殊芯片一样都是为了减轻CPU负担。
ssl_engine device;
配置错误日志存放路径及级别
#错误日志路径，这个error_log变量可以设置在任何地方
#可以在全局块中配置、在http全局块中配置、在server全局块中配置、在location块中配置、在stream块以及mail块中配置
#该配置有两个参数，第一个值设置为日志存放的实际路径，第二个值为日志级别
#debug级别必须在编译安装时要--with-debug启用debug功能
#它有debug、info、notice、warn、error、crit、alert、emerg，默认级别是error。
#如果设置为error级别，日志中会包括error级别和以上级别的信息，即error、crit、alert、emerg级别的信息。
error_log /var/log/nginx/error.log error;
配置PID文件存放路径及名称
#配置nginx服务器运行时的pid文件存放路径和名称
pid logs/nginx.pid;
配置锁文件
#锁文件，这个和events中的accept_mutex有关，如果这个参数是off，那么就不会出现锁文件。
lock_file /var/lock/nginx.lock
event 块配置
events块涉及的指令主要影响Nginx服务器与用户的网络连接。常用到的设置包括是否开启对多worker process下的网络连接进行序列化，是否允许同时接收多个网络连接，选取哪种事件驱动模型处理连接请求，每个worker process可以同时支持的最大连接数等。
这一部分的指令对Nginx服务器的性能影响较大，在实际配置中应该根据实际情况灵活调整。
配置事件驱动模型
# 一般不用设置，因为Nginx会自动选择当前系统中所支持的最有效率的IO模型。#select、poll是标准方法大多系统都支持。
#kqueue：是FreeBSE 4.1+ OpenBSD 2.9+和Mac OS X上用的
#epool：在Linux 2.6+开始支持# 还有其它很多事件驱动模型，就不列举了，最常用的高效率模型是 epoll
# use [epoll|rtsig|select|poll|kqueue|/dev/poll]
use epool;
配置网络连接相关
#如果启用了 accept_mutex，则工作进程将轮流接受新连接。否则，将新连接通知给所有工作进程，如果新连接数量较少，
#某些工作进程可能会浪费系统资源。即造成 “惊群” 问题。
#“惊群” 大意是指在 Nginx 多进程环境下，当某一时刻只有一个网络连接到来时，因为新连接会通知所有工作进程，
#那么会导致所有所有睡眠进程都会被同时叫醒，但是只有一个进程可以获得连接。如果每次唤醒的进程数目太多，会影响一些性能。
#为了解决这样的问题，可以设置 accept_mutex 为开启状态，这样多个 Nginx 进程接收网络连接时将会进行序列化接收，防止多个进程对连接的争抢
accept_mutex on; # 默认 accept_mutex off;
#如果启用了 accept_mutex，则指定另外工作进程请求新链接失败后，间隔多少毫秒可以发起第二次请求。默认500ms，不过如果accept_mutex是
#off，那就没有必要设置这个参数了。
accept_mutex_delay time; # 时间单位是毫秒，默认为 accept_mutex_delay 500ms;
#如果 multi_accept 被禁用，工作进程将一次只接收一个新连接。否则，工作进程将一次接受所有新连接。
multi_accept off; # multi_accept on;
#设置工作进程可以打开的同时连接的最大数量
#应该注意的是，这个数字包括了所有连接（例如与代理服务器的连接等），而不仅仅是客户端的连接。另一个要考虑因素是实际的并发连接数不能超过最
#大打开文件数的限制，可以通过 worker_rlimit_nofile 来修改
worker_connections 1024;
参考文章一
参考文章二
参考文章三
