Re: nginx location乱码导致内存飙升

qq663550185 · 2016-04-14T17:43:14+00:00

124613000（技术交流 ③群）2016-04-14 15:43 GMT+08:00 yan lambiel <yanbi...@gmail.com>:比如&...

Re: nginx location乱码导致内存飙升

qq663550185

在 2016年4月14日星期四 UTC+8下午5:37:03，酱油打酱油君写道：

场景：系统把几个请求量高，但是业务简单的接口放到lua中实现，所以location匹配到的就走lua。其余没匹配上的就代理到后端jetty处理，上线后偶现nginx内存使用过高的情况，nginx的error日志出现大量错误如下图：

日志里面看到，这里请求了8080端口，8080是jetty的服务，正常来说这个访问应该是直接走到lua中去的，不应该代理到jetty，然后看了下uri就傻眼了，怎么都是乱码，或许本来请求就是乱码的呢？但是在access日志里面没有找到这个请求(这里我怀疑因为access log日志的写入是最后才会写的，前面nginx报错了，日志写到error来了，就没写access log) 而jetty的日志也有报错，如下图：

所以我初步怀疑：
正常访问应该能匹配到location=/device/system/webjsp/imsiPhone/checkPhoneImsi 这个location，然后走lua的逻辑，但是因为乱码，所以匹配到 /这个location导致反向代理至后端jetty，但是jetty自己也解析不了这个，所以容器本身就报错了，所以nginx 的日志就会有上面那个错
upstream prematurely closed connection while reading response header from upstream, client: 36.99.138.227, ，但是这时候请求没完，openresty又重新发起了请求，变成了一个死循环，导致内存飙升

但是我目前不知道出现乱码的原因，以及为什么会导致死循环的出现，麻烦各位大侠帮帮忙看下，系统的环境及配置如下：

nginx version: openresty/1.7.10.2
built by gcc 4.4.7 20120313 (Red Hat 4.4.7-3) (GCC)
TLS SNI support enabled
configure arguments: --prefix=/data/nginx --with-cc-opt=-O2 --add-module=../ngx_devel_kit-0.2.19 --add-module=../echo-nginx-module-0.58 --add-module=../xss-nginx-module-0.05 --add-module=../ngx_coolkit-0.2rc3 --add-module=../set-misc-nginx-module-0.29 --add-module=../form-input-nginx-module-0.11 --add-module=../encrypted-session-nginx-module-0.04 --add-module=../srcache-nginx-module-0.30 --add-module=../ngx_lua-0.9.16 --add-module=../ngx_lua_upstream-0.03 --add-module=../headers-more-nginx-module-0.26 --add-module=../array-var-nginx-module-0.04 --add-module=../memc-nginx-module-0.16 --add-module=../redis2-nginx-module-0.12 --add-module=../redis-nginx-module-0.3.7 --add-module=../rds-json-nginx-module-0.14 --add-module=../rds-csv-nginx-module-0.06 --with-ld-opt=-Wl,-rpath,/data/luajit/lib --error-log-path=/data/log/nginx/error.log --http-log-path=/data/log/nginx/access.log --pid-path=/data/nginx/tmp/nginx.pid --lock-path=/data/nginx/tmp/nginx.lock --user=nginx --group=nginx --with-http_ssl_module --with-http_flv_module --with-http_stub_status_module --with-http_gzip_static_module --http-client-body-temp-path=/data/nginx/tmp/client/ --http-proxy-temp-path=/data/nginx/tmp/proxy/ --http-fastcgi-temp-path=/data/nginx/tmp/fcgi/ --http-uwsgi-temp-path=/data/nginx/tmp/uwsgi --http-scgi-temp-path=/data/nginx/tmp/scgi --with-file-aio --with-http_image_filter_module --with-http_realip_module --with-pcre=/tmp/pcre-8.33 --add-module=/root/build/ngx_openresty-1.7.10.2/bundle/ngx_cache_purge-2.3 --add-module=/root/build/ngx_openresty-1.7.10.2/bundle/nginx_upstream_check_module-0.3.0 --add-module=/root/build/ngx_openresty-1.7.10.2/bundle/nginx-upstream-jvm-route-master --with-http_flv_module

配置：

doujiang24

Hello,

在 2016年4月14日，下午5:43，酱油打酱油君 <qq663...@gmail.com> 写道：
日志里面看到，这里请求了8080端口，8080是jetty的服务，正常来说这个访问应该是直接走到lua中去的，不应该代理到jetty，然后看了下uri就傻眼了，怎么都是乱码，或许本来请求就是乱码的呢？

应该是请求本身乱码，你可以 tcpdump 抓个包看看

但是在access日志里面没有找到这个请求(这里我怀疑因为access log日志的写入是最后才会写的，前面nginx报错了，日志写到error来了，就没写access log)

access_log 总是会写的，即使是 upstream 出错，建议你仔细检查下 access_log

而jetty的日志也有报错，如下图：

正常访问应该能匹配到location=/device/system/webjsp/imsiPhone/checkPhoneImsi 这个location，然后走lua的逻辑，但是因为乱码，所以匹配到 /这个location导致反向代理至后端jetty，但是jetty自己也解析不了这个，所以容器本身就报错了，所以nginx 的日志就会有上面那个错
upstream prematurely closed connection while reading response header from upstream, client: 36.99.138.227, ，但是这时候请求没完，openresty又重新发起了请求，变成了一个死循环，导致内存飙升

OpenResty 针对这种情况并不会有特殊处理，Nginx 本身会有 retry 的逻辑，建议你检查下配置，是否有这方面的配置

http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_next_upstream_tries

但是我目前不知道出现乱码的原因，以及为什么会导致死循环的出现，麻烦各位大侠帮帮忙看下，系统的环境及配置如下：

nginx version: openresty/1.7.10.2
built by gcc 4.4.7 20120313 (Red Hat 4.4.7-3) (GCC)
TLS SNI support enabled
configure arguments: --prefix=/data/nginx --with-cc-opt=-O2 --add-module=../ngx_devel_kit-0.2.19 --add-module=../echo-nginx-module-0.58 --add-module=../xss-nginx-module-0.05 --add-module=../ngx_coolkit-0.2rc3 --add-module=../set-misc-nginx-module-0.29 --add-module=../form-input-nginx-module-0.11 --add-module=../encrypted-session-nginx-module-0.04 --add-module=../srcache-nginx-module-0.30 --add-module=../ngx_lua-0.9.16 --add-module=../ngx_lua_upstream-0.03 --add-module=../headers-more-nginx-module-0.26 --add-module=../array-var-nginx-module-0.04 --add-module=../memc-nginx-module-0.16 --add-module=../redis2-nginx-module-0.12 --add-module=../redis-nginx-module-0.3.7 --add-module=../rds-json-nginx-module-0.14 --add-module=../rds-csv-nginx-module-0.06 --with-ld-opt=-Wl,-rpath,/data/luajit/lib --error-log-path=/data/log/nginx/error.log --http-log-path=/data/log/nginx/access.log --pid-path=/data/nginx/tmp/nginx.pid --lock-path=/data/nginx/tmp/nginx.lock --user=nginx --group=nginx --with-http_ssl_module --with-http_flv_module --with-http_stub_status_module --with-http_gzip_static_module --http-client-body-temp-path=/data/nginx/tmp/client/ --http-proxy-temp-path=/data/nginx/tmp/proxy/ --http-fastcgi-temp-path=/data/nginx/tmp/fcgi/ --http-uwsgi-temp-path=/data/nginx/tmp/uwsgi --http-scgi-temp-path=/data/nginx/tmp/scgi --with-file-aio --with-http_image_filter_module --with-http_realip_module --with-pcre=/tmp/pcre-8.33 --add-module=/root/build/ngx_openresty-1.7.10.2/bundle/ngx_cache_purge-2.3 --add-module=/root/build/ngx_openresty-1.7.10.2/bundle/nginx_upstream_check_module-0.3.0 --add-module=/root/build/ngx_openresty-1.7.10.2/bundle/nginx-upstream-jvm-route-master --with-http_flv_module

配置：

--
--

qq663550185

因为是偶现的，所以比较难抓，而且把链接通过curl或者浏览器访问都会对乱码重新编码，不太好重新，另外通过url的参数，我grep了access的参数，没有找到相关的请求记录，配置里面也没有重试的配置，之前看到的现场就是有问题的url一直在访问，重启nginx后就正常了

在 2016年4月14日星期四 UTC+8下午6:38:15，doujiang写道：

Hello,

在 2016年4月14日，下午5:43，酱油打酱油君 <qq663...@gmail.com> 写道：
日志里面看到，这里请求了8080端口，8080是jetty的服务，正常来说这个访问应该是直接走到lua中去的，不应该代理到jetty，然后看了下uri就傻眼了，怎么都是乱码，或许本来请求就是乱码的呢？
应该是请求本身乱码，你可以 tcpdump 抓个包看看

但是在access日志里面没有找到这个请求(这里我怀疑因为access log日志的写入是最后才会写的，前面nginx报错了，日志写到error来了，就没写access log)

access_log 总是会写的，即使是 upstream 出错，建议你仔细检查下 access_log

而jetty的日志也有报错，如下图：
正常访问应该能匹配到location=/device/system/webjsp/imsiPhone/checkPhoneImsi 这个location，然后走lua的逻辑，但是因为乱码，所以匹配到 /这个location导致反向代理至后端jetty，但是jetty自己也解析不了这个，所以容器本身就报错了，所以nginx 的日志就会有上面那个错
upstream prematurely closed connection while reading response header from upstream, client: 36.99.138.227, ，但是这时候请求没完，openresty又重新发起了请求，变成了一个死循环，导致内存飙升

OpenResty 针对这种情况并不会有特殊处理，Nginx 本身会有 retry 的逻辑，建议你检查下配置，是否有这方面的配置
http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_next_upstream_tries

但是我目前不知道出现乱码的原因，以及为什么会导致死循环的出现，麻烦各位大侠帮帮忙看下，系统的环境及配置如下：

nginx version: openresty/1.7.10.2
built by gcc 4.4.7 20120313 (Red Hat 4.4.7-3) (GCC)
TLS SNI support enabled
configure arguments: --prefix=/data/nginx --with-cc-opt=-O2 --add-module=../ngx_devel_kit-0.2.19 --add-module=../echo-nginx-module-0.58 --add-module=../xss-nginx-module-0.05 --add-module=../ngx_coolkit-0.2rc3 --add-module=../set-misc-nginx-module-0.29 --add-module=../form-input-nginx-module-0.11 --add-module=../encrypted-session-nginx-module-0.04 --add-module=../srcache-nginx-module-0.30 --add-module=../ngx_lua-0.9.16 --add-module=../ngx_lua_upstream-0.03 --add-module=../headers-more-nginx-module-0.26 --add-module=../array-var-nginx-module-0.04 --add-module=../memc-nginx-module-0.16 --add-module=../redis2-nginx-module-0.12 --add-module=../redis-nginx-module-0.3.7 --add-module=../rds-json-nginx-module-0.14 --add-module=../rds-csv-nginx-module-0.06 --with-ld-opt=-Wl,-rpath,/data/luajit/lib --error-log-path=/data/log/nginx/error.log --http-log-path=/data/log/nginx/access.log --pid-path=/data/nginx/tmp/nginx.pid --lock-path=/data/nginx/tmp/nginx.lock --user=nginx --group=nginx --with-http_ssl_module --with-http_flv_module --with-http_stub_status_module --with-http_gzip_static_module --http-client-body-temp-path=/data/nginx/tmp/client/ --http-proxy-temp-path=/data/nginx/tmp/proxy/ --http-fastcgi-temp-path=/data/nginx/tmp/fcgi/ --http-uwsgi-temp-path=/data/nginx/tmp/uwsgi --http-scgi-temp-path=/data/nginx/tmp/scgi --with-file-aio --with-http_image_filter_module --with-http_realip_module --with-pcre=/tmp/pcre-8.33 --add-module=/root/build/ngx_openresty-1.7.10.2/bundle/ngx_cache_purge-2.3 --add-module=/root/build/ngx_openresty-1.7.10.2/bundle/nginx_upstream_check_module-0.3.0 --add-module=/root/build/ngx_openresty-1.7.10.2/bundle/nginx-upstream-jvm-route-master --with-http_flv_module

配置：

--