【Nginx】nginx优化性能配置

#user  nobody;
worker_processes  8;

worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000 01000000 10000000 ;

worker_rlimit_nofile 65535;



events {
    worker_connections  65535;
    use epoll;
}

（1）Nginx worker进程个数

语法： worker_processes number;

默认： worker_processes 1;

在master/worker运行方式下，定义worker进程的个数。

worker进程的数量会直接影响性能。那么，用户配置多少个worker进程才好呢？这实际 上与业务需求有关。 每个worker进程都是单线程的进程，它们会调用各个模块以实现多种多样的功能。如果 这些模块确认不会出现阻塞式的调用，那么，有多少CPU内核就应该配置多少个进程；反 之，如果有可能出现阻塞式调用，那么需要配置稍多一些的worker进程。

例如，如果业务方面会致使用户请求大量读取本地磁盘上的静态资源文件，而且服务器 上的内存较小，以至于大部分的请求访问静态资源文件时都必须读取磁盘（磁头的寻址是缓 慢的），而不是内存中的磁盘缓存，那么磁盘I/O调用可能会阻塞住worker进程少量时间，进 而导致服务整体性能下降。

多worker进程可以充分利用多核系统架构，但若worker进程的数量多于CPU内核数，那 么会增大进程间切换带来的消耗（Linux是抢占式内核）。一般情况下，用户要配置与CPU内 核数相等的worker进程，并且使用下面的worker_cpu_affinity配置来绑定CPU内核。

 

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

语法： worker_cpu_affinity cpumask[cpumask...]

为什么要绑定worker进程到指定的CPU内核呢？

假定每一个worker进程都是非常繁忙的，如果多个worker进程都在抢同一个CPU，那么这就会出现同步问题。反之，如果每一个 worker进程都独享一个CPU，就在内核的调度策略上实现了完全的并发。

例如，如果有8颗CPU内核，就可以进行如下配置：

worker_processes  8;

worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000 01000000 10000000 ;

worker_rlimit_nofile 65535;

 

注意 worker_cpu_affinity配置仅对Linux操作系统有效。Linux操作系统使用

sched_setaffinity()系统调用实现这个功能。

 

（3）PU内核worker_rlimit_nofile 

更改worker进程的最大打开文件数限制。如果没设置的话，这个值为操作系统的限制。设置后你的操作系统和Nginx可以处理比“ulimit -a”更多的文件，所以把这个值设高，这样nginx就不会有“too many open files”问题了。

（4）use epoll

use 设置用于复用客户端线程的轮询方法。如果你使用Linux 2.6+，你应该使用epoll。如果你使用*BSD，你应该使用kqueue。（值得注意的是如果你不知道Nginx该使用哪种轮询方法的话，它会选择一个最适合你操作系统的）