events { #nginx使用连接互斥锁进行顺序的accept（）系统调用，防止惊群现象发生，默认为on（on时顺序调用防止惊群，大流量高并发不推荐） 惊群解释当设置为off时，一个请求从客户端过来，会导致nginx唤醒所有的进程，但只有一个会work进程能够获取到这个链接，其他空闲的work进程重新进入休眠（其他唤醒的空闲的work是无用功） #Apache动辄就会启动成百上千的进程，如果发生惊群问题的话，影响相对较大；但是对Nginx而言，一般来说，worker_processes会设置成CPU个数，所以最多也就几十个，即便发生惊群问题的话，影响相对也较小。 #另：高版本的Linux中，accept不存在惊群问题，不过epoll_wait等操作还有 比喻： /* 假设你养了一百只小鸡，现在你有一粒粮食，那么有两种喂食方法： 你把这粒粮食直接扔到小鸡中间，一百只小鸡一起上来抢，最终只有一只小鸡能得手，其它九十九只小鸡只能铩羽而归。这就相当于关闭了accept_mutex。 你主动抓一只小鸡过来，把这粒粮食塞到它嘴里，其它九十九只小鸡对此浑然不知，该睡觉睡觉。这就相当于激活了accept_mutex。 可以看到此场景下，激活accept_mutex相对更好一些，让我们修改一下问题的场景，我不再只有一粒粮食，而是一盆粮食(大流量高并发)，怎么办？ 此时如果仍然采用主动抓小鸡过来塞粮食的做法就太低效了，一盆粮食不知何年何月才能喂完，大家可以设想一下几十只小鸡排队等着喂食时那种翘首以盼的情景。此时更好的方法是把这盆粮食直接撒到小鸡中间，让它们自己去抢，虽然这可能会造成一定程度的混乱，但是整体的效率无疑大大增强了。 */ #高并发访问量大的网站请设置为off accept_mutex on; #设置一个进程是否同时接受多个网络连接，默认为off (on时告诉nginx收到一个新连接通知后接受尽可能多的连接) multi_accept on; #如果一个进程没有互斥锁，它将至少在这个值的时间后被回收(即在accept_mutex 启用时其他空余进程不会被唤醒而是轮流处于进程等待 而accept_mutex_delay指定的时间就是这些worker进程的等待时间，等待时间一到则等待的进程将尝试获取互斥锁并开始接受新的连接)，默认是500ms accept_mutex_delay 500ms; #指定只记录由某个客户端IP产生的debug信息 debug_connection 192.168.0.1; ############ # devpoll_changes # devpoll_events # kqueue_events # epoll_events ############ ########################## # rtsig_signo # rtsig_overflow_events # rtsig_overflow_test # rtsig_overflow_threshold ########################## #事件驱动模型，select|poll|kqueue|epoll|resig|/dev/poll|eventport use epoll; #用户复用客户端线程的轮训方法。 #单个work进程允许的最大连接数，默认为512 worker_connections 1024; }
查看Nginx的版本号：
nginx -V
nginx安装目录sbin下（或者自己配置全局）
强制关闭
nginx： nginx -s stop
优雅关闭nginx（处理完请求后关机）：
nginx -s quit 或者： ps -ef|grep nginx #查看进程 kill -HUP 进程id #杀掉进程
重新加载配置文件：
nginx -s reload
重新打开日志文件
nginx -s reopen
配置文件的结构：由多个上下文模块以及main组成
不同模块指令关系：server继承main；location继承server；upstream既不会继承指令也不会被继承，它有自己的特殊指令，不需要在其他地方的应用
#main全局块 ... events { #events块 ... } http #http块 { #http全局块 ... #server块① server { #server全局块 ... #location块① location [PATTERN] #location块 { ... } #location块② location [PATTERN] { ... } } #server块② server { ... } #http全局块 ... }
说明：
1、main全局块：配置影响nginx全局的指令。一般有运行nginx服务器的用户组，nginx进程pid存放路径，日志存放路径，配置文件引入，允许生成worker process数等。 2、events块：配置影响nginx服务器或与用户的网络连接。有每个进程的最大连接数，选取哪种事件驱动模型处理连接请求，是否允许同时接受多个网路连接，开启多个网络连接序列化等。 3、http块：可以嵌套多个server，配置代理，缓存，日志定义等绝大多数功能和第三方模块的配置。如文件引入，mime-type定义，日志自定义，是否使用sendfile传输文件，连接超时时间，单连接请求数等。 4、server块：配置虚拟主机的相关参数，一个http中可以有多个server。 5、location块：配置请求的路由，以及各种页面的处理情况。
events
events { #设置网路连接序列化，防止惊群现象发生，默认为on 惊群解释当设置为off时，一个请求从客户端过来，会导致nginx唤醒所有的进程，但只有一个会work进程能够获取到这个链接，其他空闲的work进程重新进入休眠（其他唤醒的空闲的work是无用功） #Apache动辄就会启动成百上千的进程，如果发生惊群问题的话，影响相对较大；但是对Nginx而言，一般来说，worker_processes会设置成CPU个数，所以最多也就几十个，即便发生惊群问题的话，影响相对也较小。 #另：高版本的Linux中，accept不存在惊群问题，不过epoll_wait等操作还有 比喻： /* 假设你养了一百只小鸡，现在你有一粒粮食，那么有两种喂食方法： 你把这粒粮食直接扔到小鸡中间，一百只小鸡一起上来抢，最终只有一只小鸡能得手，其它九十九只小鸡只能铩羽而归。这就相当于关闭了accept_mutex。 你主动抓一只小鸡过来，把这粒粮食塞到它嘴里，其它九十九只小鸡对此浑然不知，该睡觉睡觉。这就相当于激活了accept_mutex。 可以看到此场景下，激活accept_mutex相对更好一些，让我们修改一下问题的场景，我不再只有一粒粮食，而是一盆粮食，怎么办？ 此时如果仍然采用主动抓小鸡过来塞粮食的做法就太低效了，一盆粮食不知何年何月才能喂完，大家可以设想一下几十只小鸡排队等着喂食时那种翘首以盼的情景。此时更好的方法是把这盆粮食直接撒到小鸡中间，让它们自己去抢，虽然这可能会造成一定程度的混乱，但是整体的效率无疑大大增强了。 */ #高并发访问量大的网站请设置为off(不要轻易用哦CPU占用会大幅提高，QPS严重恶化accept_mutex on时，QPS：3500，负载只有0.3 accept_mutex off时，QPS：2500，负载达到9.5，且CPU占用极高) accept_mutex on; #设置一个进程是否同时接受多个网络连接，默认为off (on时告诉nginx收到一个新连接通知后接受尽可能多的连接) multi_accept on; #如果一个进程没有互斥锁，它将至少在这个值的时间后被回收，默认是500ms accept_mutex_delay 500; #指定只记录由某个客户端IP产生的debug信息 debug_connection 192.168.0.1; ############ # devpoll_changes # devpoll_events # kqueue_events # epoll_events ############ ########################## # rtsig_signo # rtsig_overflow_events # rtsig_overflow_test # rtsig_overflow_threshold ########################## #事件驱动模型，select|poll|kqueue|epoll|resig|/dev/poll|eventport use epoll; #单个work进程允许的最大连接数，默认为512 worker_connections 1024; }
http
server
location