一、nginx服务的nginx.conf参数解析

后一篇:    二、nginx服务的参数配置解析


目录

一、全局配置参数 

1.1、参数补充: 

二、events块参数配置


nginx的nginx.conf参数配置解析

样例参数如下:


一、全局配置参数 

#worker进程的个数,通常应该略少于CPU物理核心数,也可以使用auto自动获取

worker_processes auto;

#一般情况是默认的,除非是业务场景的特殊要求,会将该物理核心数调高

worker_processes 1;

#运行用户和组,组身份可以省略

语法:user username [groupname]
默认:user nobody nobody

user 用于设置 master 进程启动后,fork 出的 worker 进程运行在哪个用户和用户组下。当按照“user username;”设置时,用户组与用户名相同。
若用户在 configure 命令执行时使用了参数 --user=username 和 --group=groupname,此时 nginx.conf 将使用参数中指定的用于和用户组。

#nginx的error日志存放路径,相对路径和绝对路径都可以的,相对路径就是conf目录所在的路径下的

error_log logs/error.log;

#指定nginx守护进程的pid文件

pid       logs/nginx.pid;


1.1、参数补充: 

#指定所有worker进程所能打开的最大文件句柄数
worker_rlimit_nofile 100000;

#性能优化相关的配置

#CPU的亲缘性绑定(同样是无法避免CPU的上下文的切换的)
#优点:提升缓存的命中率
#context switch:会产生CPU不必要的消耗


参考样例:

首先Nginx服务默认没有开启利用多核CPU,我们可以通过增加worker_cpu_affinity配置参数来充分利用多核CPU。CPU是任务处理,计算最关键的资源,CPU核越多,性能就越好。
如下就是配置Nginx多核CPU,worker_cpu_affinity使用方法和样例


1、开启2核CPU,开启2个进程

配置参数如下:

worker_processes     2;
worker_cpu_affinity 01 10;

解析:

01表示启用第一个CPU内核,

10表示启用第二个CPU内核

worker_cpu_affinity 01 10;  表示开启两个进程,第一个进程对应着第一个CPU内核,第二个进程对应着第二个CPU内核。


2. 开启2核CPU,开启4个进程

worker_processes     4;
worker_cpu_affinity 01 10 01 10;

表示开启两个进程分别是01和10内核,开启了四个进程,它们分别对应着开启2个CPU内核


3. 开启4核CPU,开户4个进程

worker_processes     4;
worker_cpu_affinity 0001 0010 0100 1000;

注:0001表示启用第一个CPU内核,0010表示启用第二个CPU内核,依此类推


4. 开启4核CPU,开启2个进程

worker_processes     2;
worker_cpu_affinity 0101 1010;

注:0101表示开启第一个和第三个内核,1010表示开启第二个和第四个内核
2核是 01,四核是0001,8核是00000001,有多少个核,就有几位数,1表示该内核开启,0表示该内核关闭。


5. 开启8核CPU,开启8个进程

worker_processes     8;
worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000 01000000 10000000;

0001表示启用第一个CPU内核,0010表示启用第二个CPU内核,依此类推


总结:

worker_processes最多开启8个,8个以上性能提升不会再提升了,而且稳定性变得更低,所以8个进程够用了。配置完毕后,重启nginx ,执行/etc/init.d/nginx restart

测试验证:
测试nginx是否有用到多个CPU内核 ,在另一台机器上执行

ab.exe -c 1000 -n 1000

注:ab.exe是装apache后带的一个性能测试工具,它可以模拟多客户端的并发请求。
在服务器上执行top

top

然后按1,就可以看到CPU内核的工作情况。如果多个CPU内核的利用率都相差不多,证明nginx己经成功的利用了多核CPU。
测试结束后,CPU内核的负载应该都同时降低。


#计时器解析度(请求到达nginx,nginx相应用户请求后,要获取系统时间并记录日志,高并发的时候可能每秒钟获取很多很多次)
#降低此值,可以减少gettimeofday()系统调用的次数

timer_resolution 100ms;

#指明worker进程的nice值:数字越小,优先级越高
#nice值范围:【-20,20】

worker_priority -10;


二、events块参数配置

#指明使用的时间模型:建议让Nginx自行选择

use [epoll|rtsig|select|poll];

#定义每个 worker 进程可以同时处理的最大连接数,worker_processes*worker_connections

语法:worker_connections number;
worker_connections 2048;

事件类配置项 是否打开 accept 锁

语法:accept_mutex [on|off]
默认:accept_mutex on;

 lock 文件的路径

语法:lock_file path/file;
默认:lock_file logs/nginx.lock;

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

语法:accept_mutex_delay Nms;
默认:accept_mutex_delay 500ms;

在使用 accept 锁后,同一时间只有一个 worker 进程能够取到 accept 锁。这个 accept 锁不是阻塞锁,如果娶不到会立刻返回。如果有一个 worker 进程试图取 accept 锁而没有取到,它至少要等 accept_mutex_delay 定义的时间间隔后才能再次试图取锁。

语法:accept_mutex_delay Nms;
默认:accept_mutex_delay 500ms;

#告诉nginx收到一个新链接通知后接受尽可能多的链接

语法:multi_accept [on|off];
默认:multi_accept off;

你可能感兴趣的:(中间件应用服务,运维日常工作,nginx,linux,负载均衡)