码迷,mamicode.com
首页 > 其他好文 > 详细

nginx

时间:2019-06-26 09:25:54      阅读:111      评论:0      收藏:0      [点我收藏+]

标签:onclick   个数   pre   应用   运行   优雅   操作   两种   增强   

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块:配置请求的路由,以及各种页面的处理情况。
View Code

 

events


http
server
location

nginx

标签:onclick   个数   pre   应用   运行   优雅   操作   两种   增强   

原文地址:https://www.cnblogs.com/lichihua/p/11087573.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!