nginx核心参数

-user USERNAME [GROUP]

解释：指定运行nginx的worker子进程的属主和属组，其中属组可以不指定

示例：user nginx nginx

-pid DIR

解释：指定运行nginx的master主进程的pid文件存放路径

示例：opt/nginx/logs/nginx.pid

-worker_rlimit_nofile number

解释：指定worker子进程可以打开的最大文件句柄数

示例：worker_rlimit_nofile 20480

-worker_rlimit_core size

解释：指定worker子进程异常终止后的core文件，用于记录分析问题, 注意nginx用户要对目录有写权限，不然无法记录。

示例：worker_rlimit_core 50M working_directory /opt/nginx/tem

-worker_processes number | auto

解释：指定nginx启动的worker子进程数量

示例：worker_processes 4 worker_process auto

-worker_cpu_affinity cpumask1 cpumask2...

解释：将每个worker子进程与我们的cpu物理核心绑定

示例：

worker_cpu_affinity 0001 0010 0100 1000 4个物理核心，4个worker子进程

worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000 01000000 10000000 8物理核心，8

子进程

worker_cpu_affinity 01 10 01 10 2物理核心，4子进程

备注：将每个worker子进程与特定的cpu物理核心绑定，优势在于：避免同一个worker子进程在不同的cpu核心上切换，导致缓存失效，降低性能；但是其并不能真正的避免进程切换

-worker_priority number

解释：指定worker子进程的nice值，以调整运行nginx的优先级，通常设定为负值，以优先调用nginx

示例：worker_priority -10

备注：Linux默认进程的优先级是120，值越小越优先；nice设定范围为-20到+19

-work_shutdown_timeout time

解释：指定worker子进程优雅退出的超时时间

示例：worker_shutdown_timeout 5s

备注：防止恶意请求，比如建立tcp连接后没有发请求或者没有回应，会在5s后关闭连接。避免占用系统资源。

-timer_resolution interval

解释：worker子进程内部使用的计时器精度，调用时间间隔越大，系统调用越少，有利于性能提升；反之，系统调用越多，性能下降

示例：worker_resolution 100ms

-daemon on|off

解释：设定nginx的运行方式。默认为on，表示后台运行。off表示前台运行，会输出日志信息。前台用于调试，后台用于生产

-lock_file file

解释：负载均衡互斥锁文件存放路径

-use [ select | poll | kqueue | epoll | /dev/poll | eventpot ]

nginx使用何种事件驱动模型。默认配置无，建议不配置，让nginx自己选择。

-worker_connections number

worker子进程能够处理的最大并发连接数。默认1024，建议65535。Linux可以打开的最大文件句柄数是65535，设置65535可以保证即使只有一个子进程也可以充分利用系统资源。

-accept_mutex [ on | off ]

是否打开负载均衡互斥锁。默认关闭。当用户向nginx发起请求时，主进程会向所有子进程询问，空闲的子进程将处理进程。当互斥锁打开时，由互斥锁轮流分配任务给子进程，可以提高效率。

-accept_mutex_delay time

互斥锁延迟时间。在互斥锁打开时生效，当互斥锁分配某个请求给子进程时，如果子进程由于繁忙不能处理时，会在延迟时间结束后分配给下一个子进程。可以避免请求长时间等待。

-muti_accept [ on | off ]

默认关闭。nginx子进程在某一时刻只能同时处理一个请求。打开后可以在同一时刻处理多个请求。实际情况下对提升性能不是很明显。

-server_name name1 name2...

匹配请求服务器的域名，比如： www.nginx.com 、* .nginx.com 、 www.nginx.* 、~^www\.nginx\..*%匹配顺序为：完全匹配>左侧匹配>右侧匹配>正则表达式匹配

-root path

文件根目录，不一定放在server段中，可以放的上下文环境是http、server、location、if。

-location [ = | ~ | ~* | ^~ ] url { ... }

解释：

=表示完全匹配，优先级最高。

示例：location = /images/ { ... } ，可以匹配 www.url.com/images , www.url.com/images/item ，不可以匹配带参数的url，例如： www.url.com/images?name=k 。需要注意的是 www.url.com/images 比 www.url.com/images/item 优先级要高。

^~匹配到即停止搜索，优先级次之。不能与不带符号的相同url同时存在。

示例：location ^~ /images/ { ... } 和 location /images/ { ... } 不能同时存在。

~正则匹配，优先级次之

~*正则匹配，不区分大小写，优先级次之

不带符号优先级最低

备注：url后面到底跟不跟/？简单来说，带/表示目录，不带/表示文件。比如/nginx/会匹配nginx目录下的index文件，/nginx会先匹配nginx目录下的index文件，如果没有nginx目录，则会把nginx当成文件。

-stub_status

监控nginx状态。

示例：location /url { stub_status}

显示的参数解释：

Active Connections 活跃的连接数量($connections_active)

accepts 接受的客户端连接总数量

handled 处理的客户端连接总数量

requests 客户端总的请求数量

Reading 读取客户端的连接数($connections_reading)

Writing 响应数据到客户端的连接数($connections_writing)

Waiting 空闲客户端请求连接数量($connections_waiting)

-alias path

文件根目录。注意path后要以/结尾，且只能放在location段中。跟root区别是：root会将定义路径与url叠加，alias只取定义路径。比如访问的location为/admin, root为/etc/nginx, alias为/etc/nginx/, 则root的绝对路径为/etc/nginx/admin, 而alias的绝对路径为/etc/nginx。

nginx是个多进程web容器，不同的配置下它的启动方式也是不同的，这里我只说说最典型的启动方式。

它有1个master进程，和多个worker进程（最优配置的数量与CPU核数相关）。那么，首先我们要找到main函数，它在src/core/nginx.c文件中。谈到源码了，这时我们先简单看下源码的目录结构吧。

nginx主要有下列目录：

src/core，这个目录存放了基础的数据结构像LIST、红黑树、nginx字符串，贯穿始终的一些逻辑结构如ngx_cycle_s、ngx_connection_s等，还有对一些底层 *** 作的封装如log、文件 *** 作、共享内存、内存池等，最后还有个nginx.c这个main启动函数了。

src/event，这个目录下存放与抽象事件相关的结构和钩子函数。nginx是以事件驱动处理流程的，事件自然是整个体系的核心了，这里定义了最核心的ngx_event_s结构。

src/event/modules目录存放了具体的种种事件驱动方式，例如epoll、kqueue、poll、aio、select等，它们通过ngx_event_actions_t结构体中的钩子挂在nginx中。nginx启动时会根据配置来决定使用哪种实现方式。

src/os/unix中存放了unix系统下许多函数调用的UNIX实现。

src/http目录存放到http module的相关实现，这个module负责处理http请求，包括协议的解析以及访问backend server的代码。

src/http/module目录存放http module类型的一些特定用途的module，比如gzip处理加密，图片压缩等。

有个初步了解后，回到main函数中，顺序看看我们感兴趣的事情。它先执行了ngx_time_init，为什么要初始化时间呢？nginx考虑的还是很周到的，取系统时间gettimeofday是系统调用，这意味着，需要发送中断给linux内核，内核需要做进程间切换来处理这个调用。这是一个不能忽视成本的函数。nginx封装了时间函数，这样，每次我们需要处理时间时，并不是调用gettimeofday，而是nginx自己缓存的时间，这样大量减少了系统调用，取当前时间这事可是谁都爱干的。

那么，nginx是怎么维护自己的这个时钟呢？如何保证用户取到的当前时间是有意义的？nginx设计者的出发点是，nginx是事件驱动机制，当一批事件发生时，也就是epoll_wait返回时，会取一次gettimeofday来更新自己的时间，然后调用各个事件对应的处理函数。这些函数都会保证自己是无阻塞的，也就是毫秒级的处理能力，所以，在任何一个事件处理函数中，取到的时间都是之前epoll_wait刚返回时取到的时间，这样，即使拿到的时间慢了几毫秒也无所谓。关键是，每个函数都是无阻塞的，都要迅速的把控制权交还给nginx，这是基本设计原则哈。

---