Nginx-安装依赖及配置详解

时间 2019-12-02

标签 nginx 安装依赖配置详解栏目 Nginx 繁體版

原文原文链接

依赖javascript

　　在安装Nginx以前, 需确保系统已经安装了gcc、 openssl-devel、 pcre-devel和zlib-devel软件库php

配置css

　　Nginx的配置文件nginx.conf位于其安装目录的conf目录下html

　　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匹配特定位置的设置）java

　　　　main块设置的指令将影响其余全部设置node

　　　　server块的指令主要用于指定主机和端口linux

　　　　upstream指令主要用于负载均衡，设置一系列的后端服务器nginx

　　　　location块用于匹配网页位置web

　　这四者之间的关系式：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配置实例：

一、2核CPU，开启2个进程

worker_processes  2;  
worker_cpu_affinity 01 10;

二、2核CPU，开启4进程

worker_processes 4;
worker_cpu_affinity 01 10 01 10;

三、2核CPU，开启8进程

worker_processes  8;  
worker_cpu_affinity 01 10 01 10 01 10 01 10;

四、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