Nginx 之 全局配置段介绍

Posted 2020-10-12

1  概述

---

nginx的配置段不一样，同一指令的用法不一样。关于nginx更详细的配置，可以查看官方帮助文档http://nginx.org/en/docs/，本文将介绍全局配置段常见的配置指令

---

2  全局配置段 

Main 全局配置段常见的配置指令分类：

.正常运行必备的配置

.优化性能相关的配置

.用于调试及定位问题相关的配置

.事件驱动相关的配置

全局性的配置一般比较少改动，默认选项可以满足一般的需求，可以根据实际情况进行调整

2.1  正常运行必备的配置

.1、user

Syntax:user user [group];

例子：

 user nginx;

Default:user nobody nobody;

Context:main

指定worker进程的运行身份，如组不指定，默认和用户名同名

.2、pid  /PATH/TO/PID_FILE

指定存储nginx主进程PID的文件路径

pid /run/nginx.pid;

.3、includefile | mask

指明包含进来的其它配置文件片断

 例子：

include  /usr/share/nginx/modules/*.conf;

.4、load_module  file

模块加载配置文件：/usr/share/nginx/modules/*.conf

指明要装载的动态模块路径: /usr/lib64/nginx/modules

2.2  性能优化相关的配置

.1、worker_processes  number | auto

auto和number的区别

auto 是nginx根据系统当前的情况开启进程数，模式是1个主进程，4个worker进程

number是人为指定开启进程数量，比如设置8，那么总共是1个主进程，7个worker进程

这里number不建议加太多，worker进程的个数通常应该为当前主机的cpu的物理核心数，可以略少，因为nginx是一个进程响应多个请求，不是线程处理。

.2、worker_cpu_affinity  cpumask ...

worker_cpu_affinity  auto [cpumask] 提高缓存命中率，机器运行时，内核的数量只能增加不能减少，如果要减少内核数，需要停机才能设置

CPU MASK：

00000001：0号CPU

00000010：1号CPU

10000000：8号CPU

例子

假设有4个内核，那么，内核的编号是0,1,2,3.设置如下，

 worker_cpu_affinity 0001 0010 1000 0100;

表示

第一个进程工作在0号内核

第二个进程工作在1号内核

第三个进程工作在3号内核

第四个进程工作在2号内核

如果这里设置为0000，则表示对应的进程不指定内核，随机工作在某个内核上。

正常情况下，主进程是随机工作在任意进程下的

进程具体工作在哪个内核，可以通过如下的命令进行查看

ps axo pid,cmd,psr,ni |grep nginx

.3、worker_priority   number

指定worker进程的nice值，设定worker进程优先级：[-20,20]，值越小，优先级越高

 .4、worker_rlimit_nofile  number

worker进程所能够打开的文件数量上限,如65535

同时连接的数量受限于系统上可用的文件描述符的数量，因为每个套接字将打开一个文件描述符。如果NGINX尝试打开比可用文件描述符更多的套接字，会发现error.log中出现Too many opened files的信息。使用ulimit检查文件描述符的数量：$ ulimit -n。现在，将此值增加到大于worker_processes *worker_connections的值。应该是增加当前worker运行用户的最大文件打开数值。NGINX提供了worker_rlimit_nofile指令，这是除了ulimit的一种设置可用的描述符的方式。该指令与使用ulimit对用户的设置是同样的效果。此指令的值将覆盖ulimit的值，如：

worker_rlimit_nofile 20960;

2.3  事件驱动相关的配置

event

语法如下

.events {

...

}

events放在主配置文件里

.1、worker_connections  number

每个worker进程所能够打开的最大并发连接数数量，如10240

这个参数建议调大点，如果请求太多，导致客户连接不上而已，不至于浪费了资源

总最大并发数：worker_processes* worker_connections

.2、use method

指明并发连接请求的处理方法,默认自动选择最优方法，为epoll.

默认：useepoll;不需要配置

.3、accept_mutex   on | off 互斥

处理新的连接请求的方法；on指由各个worker轮流处理新请求，off指每个新请求的到达都会通知(唤醒)所有的worker进程，但只有一个进程可获得连接，造成“惊群”，影响性能，默认on

2.4  调试和定位问题

.1、daemon on|off

是否以守护进程方式运行nignx，默认是守护进程方式.如果是off就是前端运行。默认是守护进程on，为后台执行

.2、master_process  on|off

是否以master/worker模型运行nginx；默认为on,如果设置为off 将不启动worker进程，主要是开发环境使用，关闭后没有worker进程，只有master提供服务。需要重启nginx服务后生效

.3、error_log  file [level]

错误日志文件及其级别；出于调试需要，可设定为debug；但debug仅在编译时使用了“--with-debug”选项时才有效

方式：file /path/logfile;

stderr:发送到标准错误

syslog:server-address[,parameter=values]:发送到syslogmemory:size内存
level:debug|info|notice|warn|error|crit|alter|emerg

 例子

error_log  /var/log/nginx/error.log;

---

本文出自 “阳光运维” 博客，请务必保留此出处http://ghbsunny.blog.51cto.com/7759574/1977217