依赖
在安装Nginx之前, 需确保系统已经安装了gcc、 openssl-devel、 pcre-devel和zlib-devel软件库
配置
Nginx的配置文件nginx.conf位于其安装目录的conf目录下
Nginx.conf由多个块组成, main section、events section、http section、sever section、location section、upstream section, 最外面的块是main, main包含events和http, http包含upstream和多个server, server又包含多个location：
main（全局设置）、server（主机设置）、upstream（负载均衡服务器设置）和 location（URL匹配特定位置的设置）
main块设置的指令将影响其他所有设置
server块的指令主要用于指定主机和端口
upstream指令主要用于负载均衡，设置一系列的后端服务器
location块用于匹配网页位置
这四者之间的关系式：server继承main, location继承server, upstream既不会继承其他设置也不会被继承
在这四个部分当中, 每个部分都包含若干指令, 这些指令主要包含Nginx的主模块指令、事件模块指令、HTTP核心模块指令, 同时每个部分还可以使用其他HTTP模块指令, 例如Http SSL模块、HttpGzip Static模块和Http Addition模块等
nginx是由模块组成的，这些模块在配置文件中又有指定的指令。指令被分成简单指令和块指令。简单指令包括名称和用空格分割的参数以及用来结尾的分号(;)。一个块指令和简单指令有相同的结构，但是它使用大括号({and})来包围一系列说明来替代使用分号作为结尾。如果一个块指令在大括号中有其他的指令，则称之为上下文（如：events,http,server, 和location）。
放在配置文件最外面的指令的称之为主文，event,http指令在主文中；server在http中，location在server中。
http: 一般情况下，配置文件中包含多个server块，它们之间以监听的端口号和server name来区分。 一旦nginx决定了哪个server处理请求，它测试在请求的对server块内定义的位置指令的参数头中指定的URI。
server: 如果有多个匹配的location块，nginx会选择前缀最长的。
server { location / { root /data/www; } location /images/ { root /data; } }
例如，响应 http://localhost/images/example.png 路由请求，nginx将会发送/data/images/example.png文件。
不带/images/的URIs请求将会映射到/data/www目录。
例如，为了响应http://localhost/some/example.html请求，nginx将会发送/data/www/some/example.html文件
main module: 主要控制子进程的所属用户/用户组、派生子进程数、错误日志位置/级别、pid位置、子进程优先级、进程对应cpu、进程能够打开的文件描述符数目等
#user是个主模块指令, 指定Nginx Worker进程运行用户以及用户组, 默认由nobody账号运行 user nobody nobody; #worker_processes是个主模块指令, 指定了Nginx要开启的进程数, 每个Nginx进程平均耗费10M~12M内存, 建议指定和CPU的数量一致即可 worker_processes 8;
#Nginx默认没有开启利用多核cpu，我们可以通过增加worker_cpu_affinity配置参数来充分利用多核cpu的性能。cpu是任务处理，计算最关键的资源，cpu核越多，性能就越好。cpu有多少个核，就有几位数，1代表内核开启，0代表内核关闭。worker_processes最多开启8个，8个以上性能就不会再提升了，而且稳定性会变的更低，因此8个进程够用了。
#详情参考下文中的进程数与CPU核数对应配置
worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000 01000000 10000000;
#error_log是个主模块指令, 用来定义全局错误日志文件, 日志输出级别有debug、info、notice、warn、error、crit可供选择, 其中, debug输出日志最为最详细, 而crit输出日志最少 error_log logs/error.log notice; #pid是个主模块指令, 用来指定进程pid的存储文件位置(kill -9 `cat /usr/local/nginx/logs/nginx.pid`) pid logs/nginx.pid; #worker_rlimit_nofile用于绑定worker进程和CPU, Linux内核2.4以上可用 #这个指令是指当一个nginx进程打开的最多文件描述符数目, 理论值应该是最多打开文 件数（ulimit -n）与nginx进程数相除 #但是nginx分配请求并不是那么均匀, 所以最好与ulimit -n 的值保持一致 #现在在linux 2.6内核下开启文件打开数为65535, worker_rlimit_nofile就相应应该填写65535 这是因为nginx调度时分配请求到进程并不是那么的均衡, 所以假如填写10240, 总并发量达到3-4万时就有进程可能超过10240了, 这时会返回502错误 worker_rlimit_nofile 65535;
events module: 设定Nginx的工作模式(Nginx处理连接的方式)及连接数上限
events { #使用网络的I/O模型 #补充说明: #与apache相似, nginx针对不同的操作系统, 有不同的事件模型 #A）标准事件模型 #Select、poll属于标准事件模型, 如果当前系统不存在更有效的方法, nginx会选择select或poll, 使用网络IO模型 #B）高效事件模型 #Kqueue: 使用于FreeBSD 4.1+, OpenBSD 2.9+, NetBSD 2.0 和 MacOS X.使用双处理器的MacOS X系统使用kqueue可能会造成内核崩溃 #Epoll: 使用于Linux内核2.6版本及以后的系统 #/dev/poll: 使用于Solaris 7 11/99+, HP/UX 11.22+ (eventport), IRIX 6.5.15+ 和 Tru64 UNIX 5.1A+ #Eventport: 使用于Solaris 10. 为了防止出现内核崩溃的问题, 有必要安装安全补丁
#Linux下效率最高的是epoll模型 use epoll; #每个进程允许的最多连接数, 根据硬件调整, 和前面工作进程配合起来用, 尽量大, 但是别把cpu跑到100%就行 #理论上每台nginx服务器的 最大连接数 = worker_processes*worker_connections
#很多人会误解worker_connections这个参数的意思，认为这个值就是nginx所能建立连接的最大值。其实不然，这个值是表示每个worker进程所能建立连接的最大值。
#所以，一个nginx能建立的最大连接数，应该是worker_connections * worker_processes。
#当然 ，这里说的是最大连接数，对于HTTP请求本地资源来说，能够支持的最大并发数量是worker_connections * worker_processes。
#而如果是HTTP作为反向代理来说，最大并发数量应该是worker_connections * worker_processes/2。因为作为反向代理服务器，每个并发会建立与客户端的连接和与后端服务的连接，会占用两个连接。 #worker_connections 值的设置跟物理内存大小有关
#默认是1024, 考虑到keep-alive为60秒, 每个浏览器平均消耗两个链接（chrom会同时打开多个连接提高加载速度）
#那么平均每秒处理 1024 / 60 / 2 = 8.5, 一天可以处理 8.5 * 86400 = 734400, 相当于每天有70万IP。 #因为并发受IO约束, 最大连接数的值须小于系统可以打开的最大文件数 #而系统可以打开的最大文件数和内存大小成正比, 一般1GB内存的机器上可以打开的文件数大约是10万左右 #我们来看看360M内存的VPS可以打开的文件句柄数是多少： #$ cat /proc/sys/fs/file-max #输出 34336 #32000 < 34336, 即并发连接总数小于系统可以打开的文件句柄总数, 这样就在操作系统可以承受的范围之内 #所以, worker_connections 的值需根据 worker_processes 进程数目和系统可以打开的最大文件总数进行适当地进行设置 #使得并发总数小于操作系统可以打开的最大文件数目 #其实质也就是根据主机的物理CPU和内存进行配置 #当然, 理论上的并发总数可能会和实际有所偏差, 因为主机还有其他的工作进程需要消耗系统资源 #ulimit -SHn 65535 #进程的最大连接数受Linux系统进程的最大打开文件数限制, 在执行操作系统命令`ulimit -n 65536`后worker_connections的设置才能生效
worker_connections 204800; #长连接过期时间, 10~20比较合理 keepalive_timeout 60; #客户端请求头部的缓冲区大小, 这个可以根据你的系统分页大小来设置 #一般一个请求头的大小不会超过1k, 不过由于一般系统分页都要大于1k, 所以这里设置为分页大小 #分页大小可以用命令 ·getconf PAGESIZE· 取得 #但也有client_header_buffer_size超过4k的情况, 但是client_header_buffer_size该值必须设置为“系统分页大小”的整倍数 client_header_buffer_size 4k; #这个将为打开文件指定缓存, 默认是没有启用的, max指定缓存数量, 建议和打开文件数一致 #inactive是指经过多长时间文件没被请求后删除缓存 open_file_cache max=65535 inactive=60s; #这个是指多长时间检查一次缓存的有效信息 open_file_cache_valid 80s; #open_file_cache指令中的inactive参数时间内文件的最少使用次数, 如果超过这个数字, 文件描述符一直是在缓存中打开的, 如上例, 如果有一个文件在inactive时间内一次没被使用, 它将被移除 open_file_cache_min_uses 1; }
http module: 配置http服务器相关属性(可以利用它的反向代理功能提供负载均衡支持, 以及正向代理的X墙)
http { #include是个主模块指令, 实现对配置文件所包含的文件的设定, 可以减少主配置文件的复杂度 #类似于Apache中的include方法 include mime.types; #属于HTTP核心模块指令, 这里设定默认类型为二进制流, 也就是当文件类型未定义时使用这种方式 #例如在没有配置PHP环境时, Nginx是不予解析的, 此时, 用浏览器访问PHP文件就会出现下载窗口 default_type application/octet-stream; #log_format是Nginx的HttpLog模块指令, 用于指定Nginx日志的输出格式。main为此日志输出格式的名称, 可以在下面的access_log指令中引用 #$remote_addr与$http_x_forwarded_for用以记录客户端的ip地址； #$remote_user：用来记录客户端用户名称； #$time_local： 用来记录访问时间与时区； #$request： 用来记录请求的url与http协议； #$status： 用来记录请求状态；成功是200, #$body_bytes_s ent ：记录发送给客户端文件主体内容大小； #$http_referer：用来记录从那个页面链接访问过来的； #$http_user_agent：记录客户毒啊浏览器的相关信息； #通常web服务器放在反向代理的后面, 这样就不能获取到客户的IP地址了, 通过$remote_add拿到的IP地址是反向代理服务器的iP地址 #反向代理服务器在转发请求的http头信息中, 可以增加x_forwarded_for信息, 用以记录原有客户端的IP地址和原来客户端的请求的服务器地址 log_format main '$host $status [$time_local] $remote_addr [$time_local] $request_uri ' '"$http_referer" "$http_user_agent" "$http_x_forwarded_for" ' '$bytes_sent $request_time $sent_http_x_cache_hit'; log_format log404 '$status [$time_local] $remote_addr $host$request_uri $sent_http_location'; #设置了log_format肯定要设置日志存放路径 access_log /usr/local/nginx/logs/access_log main; #用来设置允许客户端请求的最大的单个文件字节数 client_max_body_size 20m; #用来指定客户端请求中较大的消息头的缓存最大数量和大小, “4”为个数, “128K”为大小, 最大缓存量为4个128K large_client_header_buffers 32K; #用于开启高效文件传输模式 sendfile on； #将tcp_nopush和tcp_nodelay两个指令设置为on用于防止网络阻塞 tcp_nopush on; tcp_nodelay on; #设置客户端连接保持活动的超时时间, 在超过这个时间之后, 服务器会关闭该连接 keepalive_timeout 60; #指定响应客户端的超时时间, 这个超时仅限于两个连接活动之间的时间, 如果超过这个时间, 客户端没有任何活动, Nginx将会关闭连接 send_timeout 10; #gzip用于设置开启或者关闭gzip模块, “gzip on”表示开启GZIP压缩, 实时压缩输出数据流 gzip on; #gzip_min_length设置允许压缩的页面最小字节数, 页面字节数从header头的Content-Length中获取 #默认值是0, 即不管页面多大都进行压缩, 建议设置成大于1K的字节数, 小于1K可能会越压越大 gzip_min_length 1k; #gzip_buffers表示申请4个单位为16K的内存作为压缩结果流缓存, 默认值是申请与原始数据大小相同的内存空间来存储gzip压缩结果 gzip_buffers 4 16k; #gzip_http_version用于设置识别HTTP协议版本, 默认是1.1, 目前大部分浏览器已经支持GZIP解压, 使用默认即可 gzip_http_version 1.1; #gzip_comp_level用来指定GZIP压缩比 #1 压缩比最小, 处理速度最快 #9 压缩比最大, 传输速度快, 但处理最慢, 也比较消耗cpu资源 gzip_comp_level 2; #gzip_types用来指定压缩的类型, 无论是否指定, “text/html”类型总是会被压缩的 gzip_types text/plain application/x-javascript text/css application/xml; #gzip_vary选项可以让前端的缓存服务器缓存经过GZIP压缩的页面, 例如用Squid缓存经过Nginx压缩的数据 gzip_vary on; #保存服务器名字的hash表是由指令server_names_hash_max_size和server_names_hash_bucket_size所控制的 #参数hash_bucket_size总是等于hash表的大小, 并且是一路处理器缓存大小的倍数 #在减少了在内存中的存取次数后, 使在处理器中加速查找hash表键值成为可能 #如果hash_bucket_size等于一路处理器缓存的大小, 那么在查找键的时候, 最坏的情况下在内存中查找的次数为2 #第一次是确定存储单元的地址, 第二次是在存储单元中查找键值 #因此, 如果Nginx给出需要增大hash_max_size或hash_bucket_size的提示, 那么首要的是增大前一个参数的大小. server_names_hash_bucket_size 128; #客户端请求头部的缓冲区大小, 这个可以根据你的系统分页大小来设置, 一般一个请求的头部大小不会超过1k #不过由于一般系统分页都要大于1k, 所以这里设置为分页大小, 分页大小可以用命令`getconf PAGESIZE`取得 client_header_buffer_size 4k; #客户请求头缓冲大小, Nginx默认会用client_header_buffer_size这个buffer来读取header值 #如果header过大, 它会使用large_client_header_buffers来读取 #如果设置过小HTTP头/Cookie过大 会报400 错误nginx 400 bad request求行 #如果超过buffer, 就会报HTTP 414错误(URI Too Long) #nginx接受最长的HTTP头部大小必须比其中一个buffer大, 否则就会报400的HTTP错误(Bad Request) large_client_header_buffers 8 128k; #使用字段:http, server, location 这个指令指定缓存是否启用,如果启用,将记录文件以下信息: #打开的文件描述符,大小信息和修改时间. ·存在的目录信息. ·在搜索文件过程中的错误信息 --没有这个文件,无法正确读取,参考open_file_cache_errors指令选项: #·max -指定缓存的最大数目,如果缓存溢出,最长使用过的文件(LRU)将被移除 #例: open_file_cache max=1000 inactive=20s; open_file_cache_valid 30s; open_file_cache_min_uses 2; open_file_cache_errors on; open_file_cache max 102400 #语法:open_file_cache_errors on | off 默认值:open_file_cache_errors off 使用字段:http, server, location 这个指令指定是否在搜索一个文件是记录cache错误. open_file_cache_errors on; #语法:open_file_cache_min_uses number 默认值:open_file_cache_min_uses 1 使用字段:http, server, location #这个指令指定了在open_file_cache指令无效的参数中一定的时间范围内可以使用的最小文件数,如果使用更大的值,文件描述符在cache中总是打开状态 open_file_cache_min_uses on; #语法:open_file_cache_valid time 默认值:open_file_cache_valid 60 使用字段:http, server, location 这个指令指定了何时需要检查open_file_cache中缓存项目的有效信息. open_file_cache_valid on; #设定通过nginx上传文件的大小 client_max_body_size 300m; #设置客户端请求头读取超时时间, 如果超过这个时间, 客户端还没有发送任何数据 #Nginx将返回“Request time out（408）”错误； client_header_timeout 10; #设置客户端请求主体读取超时时间, 如果超过这个时间, 客户端还没有发送任何数据 #Nginx将返回“Request time out（408）”错误, 默认值是60； client_body_timeout 10; }
server module: 虚拟主机配置, 建议将对虚拟主机进行配置的内容写进另外一个文件，然后在http module中通过include指令包含进来，这样更便于维护和管理
server{ #listen指定虚拟主机的服务监听端口 listen 80; #server_name用来指定IP地址或者域名, 多个域名之间用空格分开 server_name 192.168.8.18 yilexun.com; #index用于设定访问的默认首页地址 index index.html index.htm index.php; #root指令用于指定虚拟主机的网页根目录, 这个目录可以是相对路径, 也可以是绝对路径 root /wwwroot/www.yilexun.com #charset用于设置网页的默认编码格式 charset gb2312; #access_log用来指定此虚拟主机的访问日志存放路径, 最后的main用于指定访问日志的输出格式 access_log logs/access.log main; location ...往下看location module.... }
location module: URL地址匹配配置, URL地址匹配是进行Nginx配置中最灵活的部分, location支持正则表达式匹配, 也支持条件判断匹配, 用户可以通过location指令实现Nginx对动、静态网页进行过滤处理, 使用location URL匹配配置还可以实现反向代理, 用于实现PHP动态解析或者负载负载均衡
#默认请求 location / { #指定对应目录 如果没有指定root则往上级寻找 root /wwwroot/www.yilexun.com #定义首页索引文件的名称 index index.php index.html index.htm; } #定义错误提示页面 #设置了虚拟主机的错误信息返回页面, 通过error_page指令可以定制各种错误信息的返回页面 #在默认情况下, Nginx会在主目录的html目录中查找指定的返回页面 #特别需要注意的是, 这些错误信息的返回页面大小一定要超过512K, 否者会被ie浏览器替换为ie默认的错误页面 error_page 404 /404.html; error_page 500 502 503 504 /50x.html; location = /50x.html { root /wwwroot/www.yilexun.com/500 } #图片请求 #或者其他JS等请求
#~ 波浪线表示执行一个正则匹配，区分大小写
#~* 表示执行一个正则匹配，不区分大小写
#^~ 表示普通字符匹配，如果该选项匹配，只匹配该选项，不匹配别的选项，一般用来匹配目录
#= 进行普通字符精确匹配
#@ 定义一个命名的 location，使用在内部定 #location ~ ^/(images|javascript|js|css|flash|media|static)/ { location ~ .*.(gif|jpg|jpeg|png|bmp|swf)$ { #指定对应目录 如果没有指定root则往上级寻找 root /wwwroot/www.yilexun.com/images; #过期30天, 静态文件不怎么更新, 过期可以设大一点, 如果频繁更新, 则可以设置得小一点 expires 30d; } #PHP, 脚本请求全部转发到FastCGI处理, 使用FastCGI默认配置 location ~ .php$ { #也就是将所有以.php为后缀的文件都交给本机的9000端口处理, 也可以使用unix的sock, 127.0.0.1:9000监听设置可以使用 php-cgi -b 127.0.0.1 或者在 php-fpm.conf 中的 listen 选项中设置 fastcgi_pass 127.0.0.1:9000; #设置默认的地址 fastcgi_index index.php; #定义$_SERVER['SCRIPT_FILENAME'] fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; #包含fastcgi_params配置 include fastcgi_params; } #禁止访问 .htxxx 文件 location ~ /.ht { deny all; }
upstream module: 负载均衡配置模块, Nginx的HTTP Upstream模块, 这个模块通过一个简单的调度算法来实现客户端IP到后端服务器的负载均衡, 在上面的设定中, 通过upstream指令指定了一个负载均衡器的名称yilexun.com, 这个名称可以任意指定, 在后面需要的地方直接调用即可, 指定设置一群服务器，服务器可以指定不同的权重
upstream yilexun.com{ #Nginx的负载均衡模块目前支持4种调度算法, 下面进行分别介绍, 其中后两项属于第三方的调度方法 #轮询（默认）: 每个请求按时间顺序逐一分配到不同的后端服务器, 如果后端某台服务器宕机, 故障系统被自动剔除, 使用户访问不受影响 #Weight: 指定轮询权值, Weight值越大, 分配到的访问机率越高, 主要用于后端每个服务器性能不均的情况下 #ip_hash: 每个请求按访问IP的hash结果分配, 这样来自同一个IP的访客固定访问一个后端服务器, 有效解决了动态网页存在的session共享问题 #fair: 比上面两个更加智能的负载均衡算法, 此种算法可以依据页面大小和加载时间长短智能地进行负载均衡 #也就是根据后端服务器的响应时间来分配请求, 响应时间短的优先分配, Nginx本身是不支持fair的, 如果需要使用这种调度算法, 必须下载Nginx的upstream_fair模块 #url_hash: 按访问url的hash结果来分配请求, 使每个url定向到同一个后端服务器, 可以进一步提高后端缓存服务器的效率 #Nginx本身是不支持url_hash的, 如果需要使用这种调度算法, 必须安装Nginx的hash软件包 ip_hash; #可以通过server指令指定后端服务器的IP地址和端口, 同时还可以设定每个后端服务器在负载均衡调度中的状态 #常用的状态有： #down: 表示当前的server暂时不参与负载均衡 #backup: 预留的备份机器, 当其他所有的非backup机器出现故障或者忙的时候, 才会请求backup机器, 因此这台机器的压力最轻 #max_fails: 允许请求失败的次数, 默认为1, 当超过最大次数时, 返回proxy_next_upstream模块定义的错误 #fail_timeout: 在经历了max_fails次失败后, 暂停服务的时间, max_fails可以和fail_timeout一起使用 #注意, 当负载调度算法为ip_hash时, 后端服务器在负载均衡调度中的状态不能是weight和backup server 192.168.8.11:80; server 192.168.8.12:80 down; server 192.168.8.13:8009 max_fails=3 fail_timeout=20s; server 192.168.8.146:8080; }
进程与CPU配置实例：
1、2核CPU，开启2个进程
worker_processes 2; worker_cpu_affinity 01 10;
2、2核CPU，开启4进程
worker_processes 4; worker_cpu_affinity 01 10 01 10;
3、2核CPU，开启8进程
worker_processes 8; worker_cpu_affinity 01 10 01 10 01 10 01 10;
4、8核CPU，开启2进程
worker_processes 2; worker_cpu_affinity 10101010 01010101;
说明：10101010表示开启了第2,4,6,8内核，01010101表示开始了1,3,5,7内核
通过apache 的ab测试查看nginx对CPU的使用状况：
top - 11:25:53 up 39 days, 1:25, 2 users, load average: 0.33, 0.11, 0.09 Tasks: 133 total, 3 running, 130 sleeping, 0 stopped, 0 zombie Cpu0 : 2.3%us, 0.9%sy, 0.0%ni, 82.7%id, 0.0%wa, 0.0%hi, 0.0%si, 14.1%st Cpu1 : 1.7%us, 0.6%sy, 0.0%ni, 81.8%id, 0.0%wa, 0.0%hi, 0.0%si, 16.0%st Cpu2 : 2.8%us, 1.9%sy, 0.0%ni, 74.4%id, 0.0%wa, 0.0%hi, 0.0%si, 20.9%st Cpu3 : 2.0%us, 0.9%sy, 0.0%ni, 83.0%id, 0.0%wa, 0.0%hi, 0.0%si, 14.0%st Cpu4 : 2.2%us, 0.8%sy, 0.0%ni, 79.3%id, 0.0%wa, 0.0%hi, 0.0%si, 17.6%st Cpu5 : 3.6%us, 1.1%sy, 0.0%ni, 75.9%id, 0.0%wa, 0.0%hi, 0.0%si, 19.5%st Cpu6 : 2.1%us, 0.9%sy, 0.0%ni, 87.2%id, 0.0%wa, 0.0%hi, 0.0%si, 9.8%st Cpu7 : 1.7%us, 0.6%sy, 0.0%ni, 80.6%id, 0.0%wa, 0.0%hi, 0.0%si, 17.1%st Mem: 1024884k total, 891020k used, 133864k free, 144912k buffers Swap: 262140k total, 4172k used, 257968k free, 434244k cached
全文参考:
Nginx 反向代理、负载均衡、页面缓存、URL重写及读写分离详解 http://freeloda.blog.51cto.com/2033581/1288553
http://www.cszhi.com/20120513/nginx_nginx-conf.html
http://wiki.nginx.org/NginxChs
Nginx文档翻译 https://segmentfault.com/a/1190000006129358