Nginx－优化

原创

wangguo139 2013-10-29 10:04:33 博主文章分类：待处理 ©著作权

文章标签 配置文件 processor nginx优化内核优化 文章分类 服务器

©著作权归作者所有：来自51CTO博客作者wangguo139的原创作品，请联系作者获取转载授权，否则将追究法律责任

一、Nginx配置文件优化

1、优化CPU

cat /proc/cpuinfo

查看processor 有几个便是几核了。假如有4核。

nginx.conf配置中：

1.worker_processes 4

2.worker_cpu_affinity 0001001001001000

这两行的意思是说，开启个工作进程，并同时启用个核心，这样能加快的响应速度。之后可以用命令来验证，是不是开启了在工作。

2、优化工作方式

nginx.conf

events{

use epoll;

}

开启epoll.详情见http://bfe99.blog.51cto.com/blog/1072496/1313475

3、设定Nginx文件句柄数

使用ulimit -n得到文件查看数限制，设置到worker_rlimit_nofile中，我的系统中是1024。

worker_rlimit_nofile 1024

这个指令是指当一个nginx 进程打开的最多文件描述符数目。可以调大这个值。

详情见http://bfe99.blog.51cto.com/blog/1072496/1313475

4、设定连接数worker_connections

1.events{

2.worker_connections 1024;

3.}

根据Nginx的理论计算公式：最大连接数=worker_processes*worker_connections/4

所以，如果要设置max_clients的话，可将其设置为1024。我这是小内存Server，内存充足的话，设置成8000-10000也没问题的。

multi_accept on;
#在Nginx获得有新连接的通知之后,接受尽可能多的连接
# 需要注意的是:如果worker_connections设置太低的话,这样可能会造成拥堵

keepalive_requests 100000;
# 可通过keep-alive连接的客户端请求数.下面的值仅是测试环境使用,具体设置请根据实际机器来调.
reset_timedout_connection on;
# 在客户端停止响应之后,允许服务器关闭连接,释放socket关联的内存

1.events{

2.max_clients 1024;

}

详情见http://bfe99.blog.51cto.com/blog/1072496/1313475

5、Nginx 内部重定向规则

在某些情况下（具体可参考 wiki.nginx.org），Nginx 内部重定向规则会被启动。
如：当 URL 指向一个目录并且在最后没有包含“/”时，Nginx 内部会自动的做一个 301的重定向，这时会有两种情况：
§server_name_in_redirect on（默认），URL 重定向为： server_name 中的第一个域名 + 目录名 + /；
§server_name_in_redirect off，URL 重定向为：原 URL 中的域名 + 目录名 + /。
这里建议设置成off
1.server_name_in_redirect off
6、设置server_names_hash_bucket_size
设置server_names_hash_bucket_size：保存服务器名字的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;

7、隐藏Nginx版本号
server_tokens off;
8、设置client_header_buffer_size和large_client_header_buffers
Nginx中经常出现难以查找原因的400错误，主要是这两个配置造成的，配置这两项：
1.client_header_bufffer_size 32k;
2.large_client_header_buffers 4 32k;
客户端请求头部的缓冲区大小，这个可以根据你的系统分页大小来设置，一般一个请求的头部大小不会超过1k，不过由于一般系统分页都要大于1k，所以这里设置为分页大小。分页大小可以用命令getconf PAGESIZE取得.
9、设置客户端通过Nginx提交文件的最大尺寸
client_max_body_size 8m;

10、打开sendfile
sendfile on;
对于普通应用必须设置为on，如果用来进行下载等应用磁盘ＩＯ负载较重，可设置为off，以平衡磁盘与网络ＩＯ处理速度，降低系统的uptime.
11、禁止TCP Push
tcp_nopush on;
该指令用于在FreeBSD或Linux系统上允许/禁止使用TCP PUSH标志位，仅当sendfile on开启时有效。
12、设置keepalive超时时间
keepalive_timeout 60;
该指令用于设置keepalive会话超时时间，默认为75秒。
13、设置tcp_nodelay
tcp_nodelay on;
该指令用于允许或禁止Socket中的TCP延时。最好使用他们的默认值。
14、设置client_body_timeout
client_body_timeout 10;
该指令用于客户端的读取操作超时时间。
15、其他设置：

1.output_buffers 1 32k;

2.postpone_output 1460;

3.open_file_cache max=1000 inactive=20s;
这个将为打开文件指定缓存，默认是没有启用的，max指定缓存数量，建议和打开文件数一致，inactive是指经过多长时间文件没被请求后删除缓存

4.open_file_cache_valid 30s;
这个是指多长时间检查一次缓存的有效信息

5.open_file_cache_min_uses 2;

open_file_cache指令中的inactive参数时间内文件的最少使用次数，如果超过这个数字，文件描述符一直是在缓存中打开的，如上例，如果有一个文件在inactive时间内2次没被使用，它将被移除。

6.open_file_cache_errors on;

7.fastcgi_connect_timeout 300;
指定连接到后端FastCGI的超时时间

8.fastcgi_send_timeout 300;
向FastCGI传送请求的超时时间，这个值是指已经完成两次握手后向FastCGI传送请求的超时时间

9.fastcgi_read_timeout 300;
接收FastCGI应答的超时时间，这个值是指已经完成两次握手后接收FastCGI应答的超时时间

10.fastcgi_buffer_size 16k;
指定读取FastCGI应答第一部分需要用多大的缓冲区，这里可以设置为fastcgi_buffers指令指定的缓冲区大小，上面的指令指定它将使用1个16k的缓冲区去读取应答的第一部分，即应答头，其实这个应答头一般情况下都很小（不会超过1k），但是你如果在fastcgi_buffers指令中指定了缓冲区的大小，那么它也会分配一个fastcgi_buffers指定的缓冲区大小去缓存

11.fastcgi_buffers 16 16k;
指定本地需要用多少和多大的缓冲区来缓冲FastCGI的应答，如上所示，如果一个php脚本所产生的页面大小为256k，则会为其分配16个16k的缓冲区来缓存，如果大于256k，增大于256k的部分会缓存到fastcgi_temp指定的路径中，当然这对服务器负载来说是不明智的方案，因为内存中处理数据速度要快于硬盘，通常这个值的设置应该选择一个你的站点中的php脚本所产生的页面大小的中间值，比如你的站点大部分脚本所产生的页面大小为256k就可以把这个值设置为16 16k，或者4 64k 或者64 4k，但很显然，后两种并不是好的设置方法，因为如果产生的页面只有32k，如果用4 64k它会分配1个64k的缓冲区去缓存，而如果使用64 4k它会分配8个4k的缓冲区去缓存，而如果使用16 16k则它会分配2个16k去缓存页面，这样看起来似乎更加合理。

12.fastcgi_busy_buffers_size 32k;
这个指令我也不知道是做什么用，只知道默认值是fastcgi_buffers的两倍

13.fastcgi_temp_file_write_size 32k;
在写入fastcgi_temp_path时将用多大的数据块，默认值是fastcgi_buffers的两倍
fastcgi_cache_path/usr/local/nginx/fastcgi_cache levels=1:2 keys_zone=TEST:10m inactive=5m;

这个指令为FastCGI缓存指定一个路径，目录结构等级，关键字区域存储时间和非活动删除时间。
fastcgi_cache TEST
开启FastCGI缓存并且为其制定一个名称。个人感觉开启缓存非常有用，可以有效降低CPU负载，并且防止502错误。但是这个缓存会引起很多问题，因为它缓存的是动态页面。具体使用还需根据自己的需求。

fastcgi_cache_valid200 302 1h;
fastcgi_cache_valid301 1d；
fastcgi_cache_validany 1m;
为指定的应答代码指定缓存时间，如上例中将200，302应答缓存一小时，301应答缓存1天，其他为1分钟
fastcgi_cache_min_uses 1;
缓存在fastcgi_cache_path指令inactive参数值时间内的最少使用次数，如上例，如果在5分钟内某文件1次也没有被使用，那么这个文件将被移除
fastcgi_cache_use_stale error timeoutinvalid_header http_500;
不知道这个参数的作用，猜想应该是让nginx知道哪些类型的缓存是没用的。

14.gzip on;

15.gzip_buffers 4 16k;

16.gzip_http_version 1.0;

17.gzip_comp_level 2;

18.gzip_types text/plain application/x-javascript text/css application/xml;

19.gzip_proxied expired no-cache no-store private auth;

20.proxy_cache_path /var/lib/nginx/cache levels=1:2 keys_zone=staticfilecache:80m inactive=1d max_size=2500m;

21.proxy_temp_path /var/lib/nginx/proxy;

22.proxy_connect_timeout 300;

23.proxy_read_timeout 120;

24.proxy_send_timeout 120;

25.proxy_buffer_size 16k;

26.proxy_buffers 4 16k;

详情见http://bfe99.blog.51cto.com/blog/1072496/1313475

二、php优化

vi /etc/php-fpm.d/www.conf
这个文件和PHP的语法很相似，凡是需要激活的配置，直接删掉前面的分号（;）即可

;listen = 127.0.0.1:9000

listen=/tmp/php-cgi.sock

换成unix方式。性能好些。
pm.max_children=20（这个配置决定了php-fpm的总进程数，内存小的少设点）
pm.max_requests=10000（每个进程在重置之前能够执行的最多请求数,并发数越大，此请求数应越大）
pm.start_servers =10（初始php-fpm进程数）
rlimit_files = 1024最多打开文件数。
emergency_restart_threshold = 60
emergency_restart_interval = 60s
上边这两个，表示在emergency_restart_interval所设值内出现SIGSEGV或者SIGBUS错误的php-cgi进程数如果超过 emergency_restart_threshold个，php-fpm就会优雅重启。这两个选项一般保持默认值。
配置完后重启php-fpm。　

三、内核参数优化

net.ipv4.tcp_max_tw_buckets = 6000
(timewait的数量，默认是180000)
net.ipv4.ip_local_port_range= 1024 65000
允许系统打开的端口范围。
net.ipv4.tcp_tw_recycle = 1
启用timewait快速回收
net.ipv4.tcp_tw_reuse = 1
开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接
net.ipv4.tcp_syncookies= 1
开启SYN Cookies，当出现SYN等待队列溢出时，启用cookies来处理
net.core.somaxconn = 262144
web应用中listen函数的backlog默认会给我们内核参数的net.core.somaxconn限制到128，而nginx定义的NGX_LISTEN_BACKLOG默认为511，所以有必要调整这个值
net.core.netdev_max_backlog = 262144
每个网络接口接收数据包的速率比内核处理这些包的速率快时，允许送到队列的数据包的最大数目
net.ipv4.tcp_max_orphans= 262144
系统中最多有多少个TCP套接字不被关联到任何一个用户文件句柄上。如果超过这个数字，孤儿连接将即刻被复位并打印出警告信息。这个限制仅仅是为了防止简单的DoS攻击，不能过分依靠它或者人为地减小这个值，更应该增加这个值(如果增加了内存之后)
net.ipv4.tcp_max_syn_backlog= 262144
记录的那些尚未收到客户端确认信息的连接请求的最大值。对于有128M内存的系统而言，缺省值是1024，小内存的系统则是128
net.ipv4.tcp_timestamps = 0
时间戳可以避免序列号的卷绕。一个1Gbps的链路肯定会遇到以前用过的序列号。时间戳能够让内核接受这种“异常”的数据包。这里需要将其关掉。
net.ipv4.tcp_synack_retries = 1
为了打开对端的连接，内核需要发送一个SYN并附带一个回应前面一个SYN的ACK。也就是所谓三次握手中的第二次握手。这个设置决定了内核放弃连接之前发送SYN+ACK包的数量
net.ipv4.tcp_syn_retries= 1
在内核放弃建立连接之前发送SYN包的数量
net.ipv4.tcp_fin_timeout = 1
如果套接字由本端要求关闭，这个参数决定了它保持在FIN-WAIT-2状态的时间。对端可以出错并永远不关闭连接，甚至意外当机。缺省值是60秒。2.2 内核的通常值是180秒，你可以按这个设置，但要记住的是，即使你的机器是一个轻载的WEB服务器，也有因为大量的死套接字而内存溢出的风险，FIN- WAIT-2的危险性比FIN-WAIT-1要小，因为它最多只能吃掉1.5K内存，但是它们的生存期长些.
net.ipv4.tcp_keepalive_time = 30
当keepalive起用的时候，TCP发送keepalive消息的频度。缺省是2小时.