【nginx】相关配置

Nginx配置通用语法

1) 块配置项

块配置项由一个块配置项名和一对大括号组成。比如

events {

use epoll;

}

 

nginx.conf中的events，http，server，location，upstream等都是块配置项块配置项可以嵌套，内嵌块直接继承外层块。

 

2) 块配置项的语法格式

基本格式：

配置项名 配置项值1 配置项值2 ...;

 

配置项目必须是nginx的某一模块想要处理的，否则判定为非法配置项名。配置项值可

以是数字，字符串包括正则表达式,可能有多个值，每行配置的末尾以分好';'结束。

 

3) 配置项的单位

以'#'字符开始的一行视为注释：

#pid logs/nginx.pid

 

指定空间大小 单位包括 K k 千字节(KB)，M m 兆字节(MB)：

gzip_buffers 4 8k;

client_max_body_size 64M;

 

4) 配置项中使用变量

$varname 比如:

log_format main '$remote_addr - $remote_user'

2、Nginx服务基本配置

Nginx服务在运行时,至少需要加载几个核心模块和一个事件类模块。这些模块所支持

的配置统称为基本配置。主要分为4大类：

1．用于调试定位为题的配置项

2．正常运行的必备配置项

3．优化性能的配置项

4．事件类配置项

 

1) 用以调试和定位问题的配置块

是否以守护进程方式运行

daemon on|off;

默认为on

如果调试阶段可以设置为off，以前台进程方式运行这样便于跟踪调试Nginx。

 

是否以master/worker方式工作

master_process on | off;

默认为on

如果调试阶段，可以设置为off 以 master进程自身来响应请求，这样便于跟踪调试Ngi

nx

 

errorr日志的设置

error_log /path/file level;

#第一个项为设置为error日志的路径和文件名

#第二项为等级 有debug,info,notice,warn,error,crit,alert,emerg 默为 logs/error.log error;

 

当第一项设置为 /dev/null 表示忽略任何日志

当设置为 stderr 这样错误日志会输出到标准错误文件中

 

第二项的等级自左向右依次增加

 

最后应该保证输出日志的硬盘空间应当足够使用

 

设置成debug模式的时候，需要在configure时加上--with-debug 参数

 

仅对指定的客户端输出debug级别的日志

debug_connection IP[/port]

由于该配置属于事件类配置，需要放置在events{...}才有效，例如：

events{

debug_connection 192.168.1.100;

        debug_connection 192.168.1.100/24;

}

仅对以上设置的IP才设置成debug级别的日志，其他请求沿用error_log 配置的级别

 

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

worker_rlimit_core_size size;

以size来限制coredump文件的大小

指定coredump文件的位置

working_directory path;

path指定coredump文件的位置

需要保证path路径有足够的写入权限和足够的使用空间

 

2) 正常运行配置项

引入其他配置文件

include /path/file;

include配置项可以将其他配置文件引入到当前的nginx.conf文件中,参数可以是绝对路径和相对(conf/)路径

include mine.types;

include vhost/*.conf

 

pid文件的位置

pid path/file

logs/nginx/pid

保存master进程ID的pid文件夹的存放路径

应该确保nginx在相应的目录中有创建pid文件的权限

 

Nginx worker进程运行的用户和用户组

user username [groupname];

user nobody nobody;

user用于设置master进程启动后，fork出的worker子进程运行在哪个用户和用户组

当设置username没有设置groupname,则默认username与groupname相同

 

指定worker进程可以打开的最大文件句柄描述符个数

worker_rlimit_nofile limit_num;

设置一个worker进程可以打开的最大文件句柄数(应该大于最大连接数)

 

限制信号队列长度

worker_rlimit_sigpending limit_num;

设置每个用户发往Nginx信号队列的大小，多的将丢弃

 

3) 优化性能配置项

Nginx worker进程的个数

worker_process number;

默认为1

worker进程的数量直接影响性能.合适的worker进程数量和业务息息相关

worker进程是单线程的进程,如果确认各模块中不会出现阻塞调用那么number设置为c

pu的核数

如果有可能出现阻塞调用，number设置的比cpu核数大一点

多worker进程可以充分利用多核系统架构，如果worker进程相比CPU数量太多会增加进程间切换的消耗

 

绑定Nginx worker进程到指定的CPU内核

 

#仅对Linux有效

worker_cpu_affinity cpumask[cpumask...]

可防止多个进程抢占同一核心

worker_processes 4;

worker_cpu_affinity 1000 0100 0010 0001;

worker_processes 2;

worker_cpu_affinity 10 01;

 

系统调用getimeofday()的执行频率

默认 timer_resolution t;

例如 timer_resolution 100ms;表示至少每100ms才调用一次gettimeofday()

目前大多数内核中，花销只是一次vsyscall()仅对共享内存页中的数据做访问。一般可

以不适用这个配置

 

4) 事件类配置项

是否打开accept锁

accept是Nginx负载均衡锁，这把锁可以让多个work进程轮流,有序的与新的客户端建立TCP连接

默认是打开的，如果配置关闭,建立TCP连接耗时会更短.但是多个worker之间负载不会均衡

 

lock文件的路径

lock_file path/file

默认 logs/nginx.lock

accept锁可能需要这个lock文件,如果accept锁配置关闭那么lock_file配置无效

如果accept锁配置打开且由于操作系统和编译器等因素导致Nginx不支持原子锁，将利

用文件锁实现accept

 

使用accept锁后到真正建立连接之间的延迟时间

accept_mutex_delay numberms;

默认500ms;

一个worker进程试图获取到accept锁失败,经过number ms时间再次试图获取accept锁

 

批量建立连接

 

multi_accept [on|off]

默认off

当时间模型通知有新连接时,尽量对本次调度中客户端发起的TCP请求都建立连接

 

选择事件模型

use [kqueue | rtsig epoll | /dev/poll | select |poll |eventport]

默认 Nginx会自动选择最适合的事件模型

对于Linux来说，可以供选择的时间驱动模型有select、poll、epoll的三种

 

每个worker的最大连接数

worker_connection number;

定义每个worker进程可以同时处理的最大连接数