nginx问题分享.docx

nginx问题分享.docx

《nginx问题分享.docx》由会员分享，可在线阅读，更多相关《nginx问题分享.docx（11页珍藏版）》请在冰豆网上搜索。

nginx问题分享

【Nginx优点】

1，ip黑白名单。

2，频率限制（主要针对url）。

3，代理后端负载均衡+权值控制，定制向端集群转发规则更加灵活。

4，nginx配置文件更简洁，特别是在“超时控制“和“虚拟主机：

xxx域名，appwk域名，wk域名”配置上比lighttpd简洁。

5，支持配置文件reload，减少重启等带来的用户体验。

6，对后端进行健康检查并会将状态码打在日志中，可以清晰得到后端宕机nginx的retry是否成功，日志中打印：

“retryN_status:

后端返回状态码”。

7，支持rewrite_logon可以清晰的得到rewrite匹配哪一个正则。

这个在线下迁移rewrite规则时发挥了很大作用。

由于日志打的太丰富会影响线上机器性能，线上已经关闭。

【Nginx在xxx的作用】

1，前端统一分流

2，防攻击

3，代理后端切流量更灵活。

二，nginx配置中各个作用域

nginx.conf主要且常用的四个作用域http，server，location，if。

……

http{

…..

include       mime.types;  

client_max_body_size25600k;

client_body_buffer_size25600k;

fastcgi_buffer_size25600k;

fastcgi_buffers425600k;

fastcgi_busy_buffers_size51200k;

fastcgi_temp_file_write_size51200k;

#后端负载均衡配置

#includeupstream.conf

upstreamserver_xxx_backends{

server 10.26.101.142:

8080max_fails=2fail_timeout=1s;

server 10.26.101.143:

8080max_fails=2fail_timeout=10s;

…...

}

#pc虚拟机配置

#includeconf/vhost/

server{

listen8080;

server_name;

if（$request_uri~"xxx"）{

rewrite"xxx""yyy"break;

}

location~"^/taskui/"{

proxy_passhttp:

//server_xxx_backends;

}

location~"^/static/"{

root'/root/nginx/webroot';

indexindex.php

}

location~/{

access_loglogs/access_log;

fastcgi_pass127.0.0.1:

6666

if（$request_uri~"xxx"）{

rewrite"xxx""yyy"break;

}

}

…..

}

#wap虚拟机配置

#includeconf/vhost/

server{

listen8080;

server_;

…..

}

…...

}

三，问题定位与解决方案

1，nginx超时、缓冲配置

Nginx

lighttpd

∙proxy_connect_timeout1s;

∙proxy_send_timeout720s;->12min

∙proxy_read_timeout3600s;->60min

∙server.read-timeout=720

∙server.write-timeout=3600

∙#

∙server.max-keep-alive-idle=30

∙server.max-read-idle=360

∙server.max-write-idle=360

∙server.max-connection-idle=6

∙fastcgi_buffer_size64k;#这里可以设置为fastcgi_buffers指令指定的缓冲区大小

∙fastcgi_buffers464k;#指定本地需要用多少和多大的缓冲区来缓冲FastCGI的应答

∙fastcgi_busy_buffers_size128k;#建议为fastcgi_buffers的两倍

∙fastcgi_temp_file_write_size128k;#在写入fastcgi_temp_path时将用多大的数据块，默认值是fastcgi_buffers的两倍，设置上述数值设置太小时若负载上来时可能报502BadGateway

【问题】文库上传大附件，buffer不够用导致频繁的IO。

如果buffer设置过小会出现如下日志，即将cgi返回内容写入临时文件：

2013/04/0720:

41:

38[warn]606#0:

*22511873anupstreamresponseisbufferedtoatemporaryfile/root/nginx/nginx_trans/cache/proxy/7/01/0000000017whilereadingupstream,client:

61.158.237.77,logid:

2496893729,tracecode:

24968937291966362890040720,server:

*,request:

"GET/play/bd286aef0975f46527d3e1c5?

pn=151&rn=10HTTP/1.0",-,upstream:

"http:

//10.36.84.22:

8099/browse/play/bd286aef0975f46527d3e1c5?

pv=play&pn=151&rn=10",host:

"",referrer:

"",-,-,-,-,

【解决】调整fastcgibuffer大小，线上配置：

∙client_max_body_size25600k;

∙指定可接受客户端的最大bodysize，如果超出这个长度nginx返回413（"RequestEntityTooLarge"）

∙client_body_buffer_size25600k;

∙这个指令指定客户端请求的中的bodysize使用多大的buffer，如果实际的bodysize超出buffer的大小，这时候将会实现“临时文件”。

∙fastcgi_buffer_size25600k;

∙用于指定读取FastCGI应答第一部分需要多大的缓冲区，这个值表示将使用1个64KB的缓冲区读取应答的第一部分（应答头），可以设置为fastcgi_buffers选项指定的缓冲区大小。

∙fastcgi_buffers425600k;

∙指定本地需要用多少和多大的缓冲区来缓冲FastCGI的应答请求。

如果一个PHP脚本所产生的页面大小为256KB，那么会为其分配4个64KB的缓冲区来缓存；如果页面大小大于256KB，那么大于256KB的部分会缓存到fastcgi_temp指定的路径中，但是这并不是好方法，因为内存中的数据处理速度要快于硬盘。

一般这个值应该为站点中PHP脚本所产生的页面大小的中间值，如果站点大部分脚本所产生的页面大小为256KB，那么可以把这个值设置为“1616k”、“464k”等。

∙fastcgi_busy_buffers_size51200k;

Limitsthetotalsizeofbuffersthatcanbebusysendingaresponsetotheclientwhiletheresponseisnotyetfullyread

当一个cgi的返回还没有完全读完并且能快速向客户端返回请求时，所使用的最大busybuffer大小，如果有必要的话还会使用temp_file（下面的参数配置），默认值是fastcgi_buffers的两倍。

∙fastcgi_temp_file_write_size51200k;

∙表示在写入缓存文件时使用多大的数据块，默认值是fastcgi_buffers的两倍。

2，虚拟主机

2.1与lighttpd相比语法更简单。

nginx

lighttpd

server{

server_;

}

server{

server_;

}

server{

server_;

}

$HTTP["host"]=~"||…."{

#

}else$HTTP["host"]=~"|..."{

#

}else{

#

}

【注意】nginx会将没有匹配到的虚拟主机使用第一个server的配置。

如，等上面的配置会导致走域名，但这不是服务想要的

【解决方案1】线上的第一个server{}是vhost/：

【解决方法2】使用default指令

listen 80 default; 

此种方式在配置项中体现的更清晰直接。

推荐使用方法2。

3，nginx日志

3.1access_log信息更详细

$upstream_status:

代理后端时，后端返回的http状态码，包括重试是否成功：

一次成功retryN_status:

200或两次成功retryN_status:

504,200等.

${request_time}s：

处理请求的耗时，其单位是s，但可以精确到毫秒。

日志如下：

27.213.175.92--[17/Apr/2013:

16:

10:

37+0800]"GET/view/ec8d2427aaea998fcc220e53.htmlHTTP/1.1"20028914"…""Mozilla/4.0（...）"27.213.175.92nginx_trans_logid:

0635698549retryN_status:

504,2001.364s

3.2rewrite_logon可以跟踪每一个请求进行了多少rewrite的条件判断

此配置项会在线下测试时启很大的作用，特别是在rewrite迁移过程中。

由于打rewrite日志会产生性能问题，所以线上将此配置项关闭。

rewrite规则：

rewrite".*""/index.php?

pv=tagsearch&$query_string?

"break;

日志如下：

2013/04/0115:

44:

04[notice]5948#0:

*1313rewrittendata:

"/index.php",args:

"pv=tagsearch&",client:

172.22.170.32,-,-,server:

*,request:

"GET/tagsearch?

n=1&m=1HTTP/1.1",-,-,host:

"",-,-,-,-,

4，upstream.conf参数

4.1fail_timeout为封禁后端的时间，当后端一台upstream中的机器宕机，nginx接下来的fail_timeout时间内不会将请求转发给这台机器。

4.2weight权重，可以通过此参数将后端性能高的机器转发更多的流量。

upstreamserver_xxx_backends{

server 10.26.101.142:

8080max_fails=2fail_timeout=1sweight=3;

server 10.26.101.143:

8080max_fails=2fail_timeout=10sweight=1;

…...

}

nginx在何时进行nextupstream，由proxy_next_upstream参数控制。

∙error—anerrorhasoccurredwhileconnectingtotheserver,sendingarequesttoit,orreadingitsresponse;

在连接后端机器或在读写过程中出现异常错误。

∙timeout—occurredtimeoutduringtheconnectionwiththeserver,transfertherequestorwhilereadingresponsefromtheserver;

当出现连接超时或读写超时。

∙invalid_header—serverreturnedaemptyorincorrectanswer;

∙http_500—serverreturnedanswerwithcode500

∙http_502—serverreturnedanswerwithcode502

∙http_503—serverreturnedanswerwithcode503

∙http_504—serverreturnedanswerwithcode504

∙http_404—serverreturnedanswerwithcode404

∙off—itforbidstherequesttransfertothenextserver

5，nginx的rewrite规则

【问题】

5.1rewrite和location的顺序问题

sever区块中如果有包含rewrite规则,则会最先执行,而且只会执行一次,然后再判断命中哪个location的配置,再去执行该location中的rewrite,当该location中的rewrite执行完毕时,rewrite并不会停止,而是根据rewrite过的URL再次判断location并执行其中的配置.那么,这里就存在一个问题,如果rewrite写的不正确的话,是会在location区块间造成无限循环的.所以nginx才会加一个最多重试10次的上限，如：

location/download/{

rewrite^（/download/.*）/media/（.*）\..*$$1/mp3/$2.mp3last;

}

如：

/download/xxx/media/name.wmv->/download/mp3/name.wmv

5.2rewrite中last和break最大的不同在于

-break是终止当前location的rewrite检测,而且不再进行location匹配

-last是终止当前location的rewrite检测,但会继续重试location匹配并处理区块中的rewrite规则

5.4rewrite匹配部分不能匹配query_string部分的内容。

5.3nginxrewrite会自动增加$query_string

if（$request_uri~"^/view/（\w+）（\.html）?

（\?

（.*））?

"）{

rewrite"^/view/（\w+）（\.html）?

（\?

（.*））?

""/browse/view/$1?

pv=view&doc_id=$1&$query_string&url=$request_uri?

"last;

等于：

rewrite"^/view/（\w+）（\.html）?

（\?

（.*））?

""/browse/view/$1?

pv=view&doc_id=$1&url=$request_uri"last;

}

5.4解决不支持嵌套if的问题

【问题】

nginx仅支持简单的if语法，如：

if（只能是一个条件）{这里不能再写if语句}。

nginx不支持像if（…&&...）{}或if（）{if（）{}}的语法。

【解决】通过set变量变向解决

set$ua"";#初始化变量，不然日志会打warning

if（$http_user_agent~"iPad"）{

set$ua"iPad";

}

if（$request_uri~"^/static/manifest/app（.*）\.manifest"）{

set$ua"${ua}404";

}

if（$ua="iPad404"）{

rewrite".*""/error-404.php"break;

}

6，请求一个目录时nginx不会自动访问此目录下的index.html

【问题】访问非root定义的目录，不会像lighttpd自动访问index.html

如访问专题页：

需要给redirect成：

再rewrite到$1/index.html，因为只有先追加“/”，index.html中的“../xxxx.css”才会找到正确的文件。

【线上实例】

localtion/{

root/root/nginx/docui/webroot;

indexindex.phpindex.htmindex.html;

….

set$is_static"";

if（-d$request_filename）{

set$is_static"o";

}

if（$uri!

~"/$"）{

set$is_static"${is_static}n";

}

if（$is_static="on"）{

rewrite"（.*）""$uri/"redirect;

}

if（-f$request_filename/index.html）{

set$is_static"${is_static}k";

}

if（$is_static="ok"）{

rewrite"（.*）$""$1/index.html"break;

}

}

7，静态文件单独location

【问题1】Content-Type原本应为image/jpeg，但浏览器得到的是text/html

【原因】在location中配置fastcgi_pass后，nginx会将请求转给cgi解释执行，cgi返回内容的Content-Type为text/html。

【解决】删除fastcgi_pass

删除fastcgi_pass后nginx直接返回静态文件的内容和类型。

即，nginx需要将静态文件单独一个location并且location中不能配置fastcgi_pass项。

如下:

location~"^/static/"{

fastcgi_pass127.0.0.1:

6666;#删除此配置项

}

总结：

在nginx替换过程中，消耗精力最大的是rewrite规则，rewrite与业务逻辑最密切，所以在替换过程中需要严谨的调研和测试rewrite各个参数的作用的，其它参数的调整和配置项可以发挥服务器的更好的性能和解决一些迁移过程中配置项的逻辑问题。

nginx最强大的功能是在代理后端时对http头部进行特殊的设置，这是lighttpd不及的。