## 核心参数 * user * pid * worker_rlimit_nofile * worker_rlimit_core * worker_processess * worker_cpu_affinity * worker_priority * worker_shutdown_timeout * timer_resolution * daemon * lock_file ## user ``` user USERNAME [GROUP] ``` 指定运行的nginx的worker子进程的属主和属组,其中属组可以不指定; 示例 : ``` user nginx nginx; ``` ## pid ``` pid DIR ``` 指定运行nginx的master的主进程的pid文件存放路径 示例: ``` pid /opt/nginx/logs/nginx.pid; ``` ## worker_rlimit_nofile ``` worker_rlimit_nofile number ``` 指定每个worker子进程可以打开的最大文件句柄数,Linux最大的限制是65535; 示例: ``` worker_rlimit_nofile 20480; ``` ## worker_rlimit_core ``` worker_rlimit_core size ``` 指定worker子进程异常终止后的core文件,用于记录分析问题;配置的目录必须要有写的权限; 示例: ``` worker_rlimit_core 50M; worker_directory /opt/nginx/tmp; ``` ## worker_processess ``` worker_processess number | auto ``` 指定nginx启动的worker子进程数量;auto会自动启动和物理核心个数一致的数量; 示例: ``` worker_processess 4; worker_processess auto; ``` ## worker_cpu_affinity ``` worker_cpu_affinity cpumask1 cpumask2... ``` 将每个worker子进程与我们的CPU物理核心绑定;这里的绑定不是指worker子进程完全占用了一个核心的计算资源;而是说只获取获得此核心的时间片;不会使用其他的核心的时间片;  示例: ``` worker_cpu_affinity 0001 0010 0100 1000 #4个物理核心,4个worker进程 worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000 010000010 10000000 #8个物理核心,8个worker进程 worker_cpu_affinity 01 10 01 10 #2个物理核心,4个子进程 ``` 备注:将每个worker子进程与特定的CPU物理核心绑定,优势在于:避免同一个worker子进程在不同的CPU核心上切换,缓存失效,降低性能;其并不能真正的避免进程切换; ## worker_priority ``` worker_priority number ``` 指定worker子进程的nice值,以调整运行nginx的优先级,通常设定为负数,以优先调用nginx; 示例: ``` worker_priority -10; ``` 备注:Linux默认进程的优先值是120,值越小越优先,nice设定范围为-20到+19; ## worker_shutdown_timeout ``` worker_shutdown_timeout time ``` 指定worker子进程优雅退出时的超时时间;热部署的时候会给子进程发送一个优雅退出的指令;worker不会直接关闭进程,而是将客户端的请求处理完毕才会退出;有很多客户端异常了,和nginx建立TCP连接后,就是不发送请求,或是不返回回应.那么worker不能一直等待,当超过优雅退出的超时时后,worker自动退出; 示例: ``` worker_shutdown_timeout 5s ``` ## timer_resolution ``` timer_resolution interval ```  worker子进程内部使用的计时器精度,调整时间间隔越大,系统调用越少,有利于性能提升;反之,系统调用越多,性能下降; **计时器解析度：降低此值，可减少gettimeofday()系统调用的次数；**     这种无谓的系统调用次数或者是我们用不到那么高的时候，降低这个值减少这个次数会在一定意义上提升Nginx性能的或者提升我们整个系统性能的。对于一个非常繁忙的服务器这点是不容忽略的。     可用来减少降低worker线程中的计时器的解析度，降低解析度以后带来的结果是，说白了就是减少发起gettimeofday()这么一个系统调用，任何一个进程运行过程当中，如果系统调用很多，任何一次系统调用的发生必然会产生软中断，产生软中断的直接结果就是模式转换，每一次的模式转换必然会消耗时间。因为我们说过很多次，一个生产力非常强的进程应该把大量时间用在用户空间，那因此timer\_resolution这个时间解析度为什么要用到这个东西呢？     我们简单举个例子：比如任何一个请求到达Nginx的时候Nginx就得响应它，响应完以后就得记录日志了，但是到日志中会记录时间。那因此一旦有用户请求到达，我们这边处理响应而要记录日志的话那么它必须要获取系统当前时间并记录在日志文件中。怎么获取系统时间呢？通过gettimeofdate来获取时间而后把这个结果再保存到日志文件中。而如果我们的时间解析度过大的话，就可能带来的结果是他一秒钟就解析一千次，一秒钟就发起一千次系统调用，如果我把这个降低一点，比如100ms解析一次，那就意味着一秒钟只解析10次了。如果指定1s一次那就意味着1s钟只解析1次，但是我们知道时间解析度越低它的精准度就越小，时间解析度越高精度就越高，正如我们的显示器一样，分辨率越高，显示的就越逼真越清晰但是它所需要消耗的资源一定也是越大的。     那因此为了提高性能，这个时间解析度应该是降低的。只要我们对于它的时间解析度要求不是特别高的话。 示例: ``` timer_resolution 100ms; ``` ## daemon ``` daemon on | off ``` 设定nginx的运行方式,前台还是后台,前台用户调试,后台用于生产; 示例: ``` daemon off ``` ## lock_file 需要将accept_mutex设为on有意义; ``` lock_file file ``` 负载均衡互斥锁文件存放路径; 默认配置: ``` lock_file /logs/nginx.lock; ``` 推荐配置: ``` lock_file /logs/nginx.lock; ```