nginx配置详解和原理

3 月，跳不动了？>>>

1.nginx的配置文件

user nobody nobody; # 指定Nginx Worker进程运行用户以及用户组，默认由nobody账号运行,nobody 是系统用户,是一个不能登陆的帐号，一个特殊用途的用户 ID
#启动进程,通常设置成和cpu的数量相等
worker_processes  1; #指定了Nginx要开启的进程数。每个Nginx进程平均耗费10M~12M内存。建议指定和CPU的数量一致即可。

#全局错误日志及PID文件 用来定义全局错误日志文件。日志输出级别有debug、info、notice、warn、error、crit可供选择，其中，debug输出日志最为最详细，而crit输出日志最少
#error_log  logs/error.log;
#error_log  logs/error.log  notice;
#error_log  logs/error.log  info;

#pid        logs/nginx.pid; # pid是个主模块指令，用来指定进程pid的存储文件位置
worker_rlimit_nofile 65535; #用于绑定worker进程和CPU， Linux内核2.4以上可用

#工作模式及连接数上限
events {
#epoll是多路复用IO(I/O Multiplexing)中的一种方式,
#仅用于linux2.6以上内核,可以大大提高nginx的性能
use   epoll;

#单个后台worker process进程的最大并发链接数
worker_connections  1024;

# 并发总数是 worker_processes 和 worker_connections 的乘积
# 即 max_clients = worker_processes * worker_connections
# 在设置了反向代理的情况下，max_clients = worker_processes * worker_connections / 4  为什么
# 为什么上面反向代理要除以4，应该说是一个经验值
# 根据以上条件，正常情况下的Nginx Server可以应付的最大连接数为：4 * 8000 = 32000
# worker_connections 值的设置跟物理内存大小有关
# 因为并发受IO约束，max_clients的值须小于系统可以打开的最大文件数
# 而系统可以打开的最大文件数和内存大小成正比，一般1GB内存的机器上可以打开的文件数大约是10万左右
# 我们来看看360M内存的VPS可以打开的文件句柄数是多少：
# $ cat /proc/sys/fs/file-max
# 输出 34336
# 32000 < 34336，即并发连接总数小于系统可以打开的文件句柄总数，这样就在操作系统可以承受的范围之内
# 所以，worker_connections 的值需根据 worker_processes 进程数目和系统可以打开的最大文件总数进行适当地进行设置
# 使得并发总数小于操作系统可以打开的最大文件数目
# 其实质也就是根据主机的物理CPU和内存进行配置
# 当然，理论上的并发总数可能会和实际有所偏差，因为主机还有其他的工作进程需要消耗系统资源。
# ulimit -SHn 65535

}

http {
#设定mime类型,类型由mime.type文件定义
include    mime.types;
default_type  application/octet-stream;#  default_type属于HTTP核心模块指令，这里设定默认类型为二进制流，也就是当文件类型未定义时使用这种方式，例如在没有配置PHP环境时，Nginx是不予解析的，此时，用浏览器访问PHP文件就会出现下载窗口。
#设定日志格式
log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';

access_log  logs/access.log  main;

#sendfile 指令指定 nginx 是否调用 sendfile 函数（zero copy 方式）来输出文件，
#对于普通应用，必须设为 on,
#如果用来进行下载等应用磁盘IO重负载应用，可设置为 off，
#以平衡磁盘与网络I/O处理速度，降低系统的uptime.
sendfile     on;
#tcp_nopush     on;

#连接超时时间
#keepalive_timeout  0;
keepalive_timeout  65;
tcp_nodelay     on;

#开启gzip压缩
gzip  on;
gzip_disable "MSIE [1-6].";

#设定请求缓冲
client_header_buffer_size    128k;
large_client_header_buffers  4 128k;

　　
　　　　upstream cszhi.com{
　　　　　　ip_hash;
　　　　　　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;
　　　　}; 负载均衡的设置
#设定虚拟主机配置
server {
#侦听80端口
listen    80;
#定义使用 www.nginx.cn访问
server_name  www.nginx.cn;

#定义服务器的默认网站根目录位置
root html;

#设定本虚拟主机的访问日志
access_log  logs/nginx.access.log  main;

#默认请求
location / {

#定义首页索引文件的名称
index index.php index.html index.htm;

}
　　　　

# 定义错误提示页面
error_page   500 502 503 504 /50x.html;
location = /50x.html {
}

#静态文件，nginx自己处理
location ~ ^/(images|javascript|js|css|flash|media|static)/ {

#过期30天，静态文件不怎么更新，过期可以设大一点，
#如果频繁更新，则可以设置得小一点。
expires 30d;
}

#PHP 脚本请求全部转发到 FastCGI处理. 使用FastCGI默认配置.
location ~ .php$ {
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
include fastcgi_params;
}
　　　　
　　　　 location /proxy {
　　proxy_pass http://192.168.33.10;
　　 } # 设置方向代理
#禁止访问 .htxxx 文件 location ~ /.ht { deny all; } } }

1.1 关于nobody用户

nobody 是系统用户,是一个不能登陆的帐号，一个特殊用途的用户 ID ,一些服务进程如apache，aquid等都采用一些特殊的帐号来运行，比如nobody,news,games等等。

一般来说 uid < 500 的都是系统 ID 。 Linux 系统为了安全，很多操作和服务的运行都不是运行在 root 用户下面的，而是一个专用的 ID ，这个 ID 一般就是 nobody ，这样就可以把每个服务运行的情况隔离出来。 保证不会因为服务器程序的问题而让服务器程序成了黑客的直接操作源。

同时也不会影响其他用户的数据。 服务器程序提权有专用的办法来防止恶意使用的。 除了 nobody ，常见的还有 ftp 、ssh 什么的。有的不是用来跑服务，而是用来占坑，主要是用用户组的权限管理进行权限设置，这个时候会有一个占坑用的同名 ID 加入到用户组。这种情况好像主要是为了兼容。

问题描述：

上午据反映，系统响应很慢，界面要刷新很久才出得来。查后台也没有报什么错，我们系统是用nginx做负载均衡。惯性地不走负载均衡而直接访 问单节点应用，发现响应很快，很正常。初步定位问题出在nginx上， 然后查nginx日志，发现有很多错误，错误中有“13: Permission denied”这个信息，明显是权限问题，很奇怪，之前运行都很正常啊。后来一问才知道，维护人员做了操作。 系统上nginx安装时使用的是root用户，也是用root用户启动的，所以要修改配置的时候需要使用root用户，管理上不方便，所以维护人员 心血来潮修改了nginx的权限（后来知道他是使用这个命令修改的权限chown -R user:group $nginxdir）。 就是将nginx的用户和组都换掉了，但是这样为什么会造成“响应慢”呢？

1.2 负载均衡设置

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软件包。

在HTTP Upstream模块中，可以通过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。