nginx的优化

转：http://blog.sina.com.cn/s/blog_704836f40100zlht.html

说起nginx的调优，坏消息是事实上没有方法能很大程度优化nginx，不存在一个"神奇的"设置选项可以将负载降低到原来的一半或者可以让PHP运行速度加倍。不过接下来是好消息，nginx本身已经优化的足够好了！其实相比apache，最大的优化在你敲入"apt-get install","yum install"或者"make install"的时候已经产生了，呵呵。

那么怎么还要说到nginx调优这个话题呢？

一个原因是因为nginx有很多的配置选项，这些选项会影响nginx的行为。但是，这些选项的默认值并不是完全针对高负载这种状况优化的，所以需要调整。

另一个原因是nginx所运行的OS的设置也会影响nginx的运行，想要达到理想的运行效果，也需要调整。

我们下面就来分别分析一下相关的问题。

一、操作系统的限制

1.操作系统本身

nginx可以运行在Linux, MacOS, FreeBSD, Solaris, Windows等众多平台上，这些平台都有各自的高性能event polling方法，不过nginx只支持其中的4种。一般来说，运行在freebsd，linux，MacOS,Solaris上性能不会有很巨大的差别，所有选择你自己熟悉的OS比要选择所谓"绝对优化"的，但是不熟悉的OS更加重要。不过，windows是一个例外，在生产环境中，千万不要把nginx运行在windows上。因为windows有自己的event polling方法，而nginx的作者明确说明不支持该方法。

在nginx中，可以在配置文件中指定所使用的event polling模型，指令如下:

use epoll; Linux系统

use kqueue; FreeBSD系统

2.`ulimit -a`命令所列出来的这些参数

这些参数是nginx无法超越的。例如，在许多系统中，默认允许打开的最大文件数为1024，如果nginx运行在这个环境下，那么当流量大时就会出现(24: Too many open files) 错误。而nginx的处理能力远不止1024，因此这个参数必须调整。

二、nginx自身的限制

1.编译优化

默认的nginx编译选项是用debug模式(-g)的（debug模式会插入很多跟踪和ASSERT之类），编译以后一个nginx可执行文件有好几MB。去掉nginx的debug模式编译，编译以后只有几百KB。

在源码auto/cc/gcc中，在最后几行中找到如下内容:

# debug

CFLAGS=”$CFLAGS -g”

把CFLAGS这一行删除或者注释掉，然后再编译即可。

另外，如果只是把nginx作为web server，那么可以禁用一些用不到的modules，可以减少内存footprint，提高服务器性能。

./configure --prefix=/webserver/nginx --without-mail_pop3_module --without-mail_imap_module --without-mail_smtp_module --with-http_ssl_module --with-http_stub_status_module --with-http_gzip_static_module

2.Worker Processes

worker process是整个nginx的关键，一旦主进程绑定到了指定的IP/Port上以后，主进程会使用指定的用户派生出worker process，这些worker process会处理所有的用户请求。worker process不是多线程的，不需要将每个connection在不同CPU内核间切换，因此运行多个worker process是必然的，通常每个CPU core对应一个worker process。通常，如果超过4个worker process，那么CPU肯定不会成为瓶颈了，因为在CPU成为瓶颈之前，nginx的其他部分肯定已经不行了。

cat /proc/cpuinfo |grep 'core id'

3.Worker
Connections

worker
connctions是一个有点"怪异"的概念，我不确定这个指令的确切目的。但是可以确定的是这个指令可以有效的限制每个worker
process在同一时间可以维护多少个连接。如果非要我猜的话，我认为这个指令是一个保险机制，为了防止错误配置的keep-alive耗尽可用端口。

在默认配制文件中，worker
connections的值是1024。通常一个浏览器会针对一个站点打开2个连接，那么最大可以并发服务的用户数量为512个。这个数字看起来不小了，但是考虑到keep-alive默认的timeout值是65，那么意味着其实我们每秒只能处理8个connection。显然这个数字超过了大多数人的需求，尤其是当我们使用2-4个worker
process的时候。但是对于大流量的站点，并且打开了keep-alvie，那么应该时刻考虑到这一点。

当考虑worker
connections的值的时候，其实很简单，流量增加就增加这个值。2048对于绝大多数人应该够用了，不过如果你的站点真的增长这么快的话，那么最大该设置多大，只有你自己尝试了。

4.CPU
Affinity

设置CPU
affinity的意思是告诉nginx，每个worker
process应该使用哪一个CPU
core，指定以后该worker
process只会使用你指定的那个CPU
core。请小心的做这个配置，因为OS的CPU调度器在处理负载均衡方面远比人类做的更好。如果你确实认为你需要在CPU调度器层面做优化的话，你可以选择不同的CPU调度器，不过你需要清楚的知道你自己在干什么，如果不知道，不要碰这个配置。

5.Keep
Alive

keep
alive是一个HTTP的特性，其允许用户agent(浏览器)和服务器之间保持连接，以便其他请求共用或者直到指定的timeout时间到达。这个特性事实上并不会改善我们的nginx服务器性能，因为nginx自己可以非常好的处理空闲连接。nginx作者指出，处理10000个空闲连接只耗费2.5MB的内存。

在这里提到keep
alive的目的很简单。keep
alive对于终端用户感觉到的等待时间影响是巨大的。如果你的站点看起来载入很快，那么用户会很开心。Amazon做过调查，用户感觉的等待时间和最终业务成交量之间有直接的关系。

keep
alive可以避免在创建HTTP连接过程中许多无用操作，因此它的作用才如此明显。一般我们不需要65这么大的timeout值，但推荐你将这个值设置在10-20之间。

keepalive_timeout
15

6.tcp_nodelay
and tcp_nopush

这两个参数的用途很难理解，因为它们在很底层的网络部分影响nginx。一个简单肤浅的解释是这两个指令控制OS如何处理网络缓冲，何时将他们刷新给最终用户。因为这两个参数不会明显提高或改变任何事情，如果你不明白这两个参数的含义，那我建议你不用碰它，保持默认值就好了。

三、硬件的限制

上边已经讨论了OS，nginx本身的一些限制，现在让我们看看怎么把服务器的性能压榨到底。

服务器上能成为瓶颈的就CPU,内存和IO。对于nginx来说，CPU和内存都不会是瓶颈。因此瓶颈只会产生在IO部分。硬盘相对于CPU和内存来说，是非常非常慢的设备。硬盘读取和写入是非常耗时的操作，因此我们需要尽量减少nginx对硬盘的读写操作。

1.Access
log

nginx默认会将每个请求写入到日志文件中，日志可以用来审计和统计。但是记录日志的操作会带来IO开销。如果你不需要记录日志，直接关闭这个选项就好。如果需要记录日志，最好将日志记录到内存中，然后定期将日志转储到磁盘上。这样可以避免频繁磁盘IO操作，极大提高性能。

access_log
off;

2.Error
log

对于error
log，其实不应该关闭的。但是为了降低磁盘IO操作，可以调整error
log的级别，将这个参数设置成"warn"级别应该足够了，并且也不会产生很大的IO。

3.Open
File Cache

从文件系统读取数据包含文件打开和关闭操作，这部分也是磁盘块操作。为了减少这部分操作，可以缓存打开的文件描述符。这个操作使用open
file cache 实现，具体可以参考链接中的wiki。

4.Buffers

调整buffer的大小对于nginx很重要，如果buffer设置得太小，nginx将不得不把upstream服务器返回来的响应存储在临时文件中。这会导致同时增加磁盘读写操作，流量越大影响越明显。

client_body_buffer_size 指令指定了处理客户端请求body部分的buffer的大小。这个一般用于处理POST数据，表单提交，文件上传等操作。如果你要处理很多大的POST提交，那么这个值要设置足够大。

client_header_buffer_size 指令指定了处理客户端请求header部分的buffer的大小。设置成1K能满足绝大部分需求。

client_max_body_size 指令指定了可以接受的最大的用户请求body大小。通过HTTP头中的Content-Length确认，如果大小超过这个值，则客户端会得到“Request
Entity Too Large” (413)错误。

large_client_header_buffers 指令分配用于处理从用户那里来的大文件头请求的buffer的最大数量和buffer大小。请求的header不能比其中的一个buffer大，否则nginx会返回“Request
URI too large” (414)错误。最长的header行也必须小于一个buffer的大小，否则客户端会得到“Bad
request” (400)错误。

fastcgi_buffers和proxy_buffers 指令指定了处理upstream回应的buffer大小，也就是PHP,Apache或其他。上边也说到了，如果这个buffer太小，在响应用户之前，nginx将不得不把upstream服务器返回来的响应存储在临时文件中。注意，nginx的buffer是有上限的，这个上限由fastcgi_max_temp_file_size和proxy_max_temp_file_size控制。当然也可以通过将proxy_buffering设置成off来关闭proxy
connections的buffer(通常不是个好主意！)。

示例如下:

client_body_buffer_size
8K;
client_header_buffer_size
1k;
client_max_body_size
2m;
large_client_header_buffers
2 1k;

5.彻底避免磁盘IO

最彻底的避免磁盘IO的方法是不使用磁盘，如果费用不是问题且数据量不大，那么可以使用ramdisk，将所有数据放到内存中。

6.网络IO

为了降低网络IO，我们使用gzip
module来压缩传输的数据量。设置gzip_comp_level的值为4-5应该比较合适，如果设置更大没什么用处，白白浪费CPU。

gzip on;

gzip_comp_level 5;

gzip_min_length 1000;

gzip_proxied expired
no-cache no-store private auth;
gzip_types text/plain
application/xml;
gzip_disable "MSIE
[1-6]\.";

四、什么？上边还不够？！

如果经过上述的优化仍然不能满足的要求，那么建议你考虑增加更多的服务器吧，稍微花费一点钱买服务器，比你在这里浪费时间微调nginx要来得更有效果。

--------

# 与系统CPU的core总数对应

worker_processes 24;

# nginx可以打开的文件描述符的数量

# 通常在OS中用'ulimit -n 200000'

# 或者在/etc/security/limits.conf设置

worker_rlimit_nofile 200000;

# 错误日志仅记录crit以上级别

error_log /var/log/nginx/error.log crit

# 每个worker process可以最多服务多少客户端

# (Max clients = worker_connections * worker_processes)

# "Max clients" 也受限于系统中可用的socket数量(~64k)

worker_connections 4000;

# 使用epoll模型

use epoll;

# 当nginx接到新连接的请求时,会尽可能的接受更多的连接

# 如果worker_connections参数设置较低,则此参数会对nginx产生冲击,谨慎!

multi_accept on;

# 缓存打开的文件描述符,参数值应该根据具体应用场景调整(不要照搬下边的数值!)

open_file_cache max=200000 inactive=20s;

open_file_cache_valid 30s;

open_file_cache_min_uses 2;

open_file_cache_errors on;

# 缓冲log写操作,以提高磁盘IO效率,或者直接关闭access_log

#access_log /var/log/nginx/access.log main buffer=16k;

access_log off;

# 调用Sendfile实现内核"zero copy"

# 一般应该打开,如果用来进行下载等应用磁盘IO重负载应用,可设置为off,以平衡磁盘与网络I/O处理速度

sendfile on;

# Tcp_nopush选项会让nginx尝试在一个packet内发送其HTTP响应,而不是分帧传送

# 这对优化吞吐率很有用处,对于在调用sendfile函数前prepending headers也有作用

tcp_nopush on;

# 不缓冲data-sends(禁用Nagle算法). Good for sending frequent small bursts
of data in real time.

tcp_nodelay on;

# keep-alive连接的超时时间,server会在此时间之后关闭连接

keepalive_timeout 15;

# client的请求可以转换成keep-alive连接的数量,如果为了性能测试,可以设置的高一些,默认100

#keepalive_requests 100000;

# 允许server在client停止响应以后关闭连接,释放分配给该连接的内存

reset_timedout_connection on;

# 如果client对于body的请求超过这个时间,则发送"request timed out"响应,默认60秒

# 防范慢查询攻击

client_body_timeout 10;

# 如果client停止读取数据, 在此时间以后释放该连接,默认是60秒

send_timeout 2;

# 打开gzip压缩,减少数据传输量

gzip on;

gzip_static on;

gzip_comp_level 9;

gzip_min_length 1400;

gzip_vary on;

gzip_http_version 1.1;

gzip_proxied expired no-cache no-store private auth;

gzip_types text/plain text/css text/xml text/javascript image/gif
image/jpeg application/x-javascript application/xml;

gzip_disable "MSIE [1-6]\.(?!.*SV1)";

---------------

--------基本的nginx.conf----

user nginx;

worker_processes 24;

error_log /var/log/nginx/error.log
crit;

pid /var/run/nginx.pid;

events {

worker_connections 2048;

use
epoll;

multi_accept
on;

}

worker_rlimit_nofile 200000;

http {

include /etc/nginx/mime.types;

default_type application/octet-stream;

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
/var/log/nginx/access.log main buffer=16k;

sendfile on;

tcp_nopush on;

tcp_nodelay on;

open_file_cache
max=200000 inactive=20s;

open_file_cache_valid
30s;

open_file_cache_min_uses
2;

open_file_cache_errors
on;

client_body_buffer_size
8K;

client_header_buffer_size
1k;

client_max_body_size
2m;

large_client_header_buffers
2 1k;

keepalive_timeout 15;

reset_timedout_connection
on;

client_body_timeout
10;

send_timeout
2;

gzip
on;

gzip_static
on;

gzip_comp_level
9;

gzip_min_length
1400;

gzip_vary on;

gzip_http_version
1.1;

gzip_proxied
expired no-cache no-store private auth;

gzip_types
text/plain text/css text/xml text/javascript image/gif image/jpeg
application/x-javascript application/xml;

gzip_disable
"MSIE [1-6]\.(?!.*SV1)";

include
/etc/nginx/conf.d/*.conf;

}

防止php文件解析漏洞

# Pass all .php files onto
a php-fpm/php-fcgi server.

location ~ \.php$ {

#
Zero-day exploit defense.

# http://forum.nginx.org/read.php?2,88845,page=3
#
Won't work properly (404 error) if the file is not stored on this
server, which is entirely possible with php-fpm/php-fcgi.

#
Comment the 'try_files' line out if you set up php-fpm/php-fcgi on
another machine. And then
cross your fingers that you won't get hacked.

try_files
$uri =404;

fastcgi_split_path_info
^(.+\.php)(/.+)$;

#NOTE: You should
have "cgi.fix_pathinfo = 0;" in php.ini

include
fastcgi_params;

fastcgi_index
index.php;

fastcgi_param
SCRIPT_FILENAME $document_root$fastcgi_script_name;

#
fastcgi_intercept_errors on;

#
With php5-cgi alone:

#
fastcgi_pass 127.0.0.1:9000;

#
With php5-fpm:

fastcgi_pass
unix:/var/run/php5-fpm.sock;

}

php-fpm中的配置,与nginx
的fastcgi_pass的路径一致即可，目录要有相应读写权限

; Note: This value is mandatory.

listen = /var/run/php5-fpm.sock